IBM i Security

Build an IBM i Recovery Security Validation Workflow with SQL

Combine IBM i audit-journal SQL services for JD, RJ, RA, RP, and RU entries into a controlled post-recovery workflow that validates job identities, restored authorities, authorization lists, adopted authority, and recovery evidence.

A successful IBM i restore proves that commands completed and objects returned. It does not prove that the recovered security model is correct. Job descriptions can carry named profiles, authorization lists can be removed, private authorities can be incomplete, and programs that adopt authority can reappear with powerful owners. IBM i audit-journal SQL services make those outcomes measurable.

A defensible recovery process should answer:

Were the expected profiles and authorization lists restored?
Were private authorities fully restored?
Did any restored object lose or change its authorization list?
Did public authority become *EXCLUDE?
Were adopting programs restored?
Did restored job descriptions introduce named profiles?
Were any job-description USER values changed after recovery?
Does the current configuration match the approved target policy?

This guide combines five evidence streams:

JD   Job-description USER changes
RJ   Restored job descriptions containing named profiles
RA   Authority changes caused by restored objects
RP   Restored programs that adopt owner authority
RU   User-profile authority restoration results

It also uses:

AP   Actual adopted-authority activity

when you need to move from identifying potential privilege to confirming its use.

Recovery completion and security validation are separate

IBM documents a typical security recovery sequence:

1. Restore user profiles and authorization lists.
2. Restore objects.
3. Restore private authorities with RSTAUT.

That sequence is necessary, but a command-completion message is not a complete security assessment.

Examples:

• RSTUSRPRF can restore a profile, but later RSTAUT can still report that some authorities were not restored.
• An object can be restored after losing its authorization-list association.
• Public authority can be set to *EXCLUDE to protect an object whose expected authorization list is unavailable.
• A program using USRPRF(*OWNER) can return with an owner that is inappropriate for the target environment.
• A restored job description can reintroduce a production service profile into development or UAT.
• A local post-restore correction can later change the job-description USER value again.

The recovery runbook should therefore have two independent completion states:

Operational restore complete
Security validation complete

Do not close the recovery solely because applications start.

The five-entry recovery-security model

RU — Was authority restored for the profile?

RU entries are created by RSTAUT.

The essential result is:

A   All authorities restored
S   Some authorities were not restored

Use SYSTOOLS.AUDIT_JOURNAL_RU on supported IBM i levels.

An S result should lead to the corresponding RSTAUT job logs, including any prestart jobs used during nonrestricted processing.

RA — Did restoring an object change its authority?

RA entries identify restore-time authority changes such as:

Authorization list removed
Saved and restored authorization lists differ
Public authority set to *EXCLUDE
Private authority removed

Use:

SYSTOOLS.AUDIT_JOURNAL_RA

The result may reflect a protective system action, an intentional target-environment difference, or an incomplete recovery.

RP — Did an adopting program return?

RP entries identify restored programs, service programs, or related objects that adopt their owner’s authority.

Use:

SYSTOOLS.AUDIT_JOURNAL_RP

The restore evidence should be followed by current-state checks for:

Owner
USRPRF
USEADPAUT
Who can execute the object
Whether the owner has excessive authority

RJ — Did a restored job description specify a profile?

RJ entries identify restored job descriptions containing a user profile in the USER parameter.

IBM does not currently provide a dedicated:

SYSTOOLS.AUDIT_JOURNAL_RJ

Use:

QSYS2.DISPLAY_JOURNAL

or:

CPYAUDJRNE ENTTYP(RJ)

The entry contains the restored profile and the profile previously specified in the job description.

JD — Was the USER value created or changed?

JD entries identify CRTJOBD and CHGJOBD activity affecting the job-description USER parameter.

Use:

SYSTOOLS.AUDIT_JOURNAL_JD

This creates a timeline:

RJ   Profile introduced by restore
JD   Profile created or changed before or after restore

Together, they show whether the restored value was accepted, corrected, or later changed again.

Build one recovery-control record

Start by defining the recovery event.

CREATE TABLE RECOVERY.RECOVERY_RUN
(
    RECOVERY_ID               VARCHAR(40) NOT NULL,
    RECOVERY_TYPE             VARCHAR(30) NOT NULL,
    SOURCE_SYSTEM             VARCHAR(8),
    TARGET_SYSTEM             VARCHAR(8) NOT NULL,
    TARGET_ENVIRONMENT        VARCHAR(20) NOT NULL,

    START_TIMESTAMP           TIMESTAMP NOT NULL,
    END_TIMESTAMP             TIMESTAMP,

    START_RECEIVER_LIBRARY    VARCHAR(10),
    START_RECEIVER_NAME       VARCHAR(10),
    START_SEQUENCE_NUMBER     DECIMAL(21, 0),

    END_RECEIVER_LIBRARY      VARCHAR(10),
    END_RECEIVER_NAME         VARCHAR(10),
    END_SEQUENCE_NUMBER       DECIMAL(21, 0),

    RSTUSRPRF_JOB             VARCHAR(28),
    OBJECT_RESTORE_JOB        VARCHAR(28),
    RSTAUT_JOB                VARCHAR(28),

    CHANGE_REFERENCE          VARCHAR(128),
    RUNBOOK_VERSION           VARCHAR(40),

    OPERATIONAL_STATUS        VARCHAR(24) NOT NULL,
    SECURITY_STATUS           VARCHAR(24) NOT NULL,

    SECURITY_REVIEWED_BY      VARCHAR(128),
    SECURITY_REVIEWED_TS      TIMESTAMP,
    REVIEW_NOTES              VARCHAR(2048),

    PRIMARY KEY (RECOVERY_ID)
);

Example recovery types:

DR TEST
PRODUCTION RECOVERY
SYSTEM MIGRATION
ENVIRONMENT REFRESH
PROFILE RECOVERY
APPLICATION RESTORE

A defined recovery window prevents unrelated audit events from being mixed into the evidence package.

Capture a durable journal boundary

Timestamp filtering is useful for interactive investigation.

For repeatable evidence extraction, preserve:

Receiver library
Receiver name
Sequence number
Entry timestamp
System name

Do not store sequence number alone.

Journal sequence numbers can be reset.

The receiver and sequence together provide a stronger source position.

Create one evidence ledger

You can maintain separate tables for each entry type, but one normalized ledger makes review and reporting easier.

CREATE TABLE RECOVERY.SECURITY_EVIDENCE
(
    EVIDENCE_ID               BIGINT
                              GENERATED ALWAYS AS IDENTITY,

    RECOVERY_ID               VARCHAR(40) NOT NULL,
    EVIDENCE_TYPE             CHAR(2) NOT NULL,

    SOURCE_SYSTEM             VARCHAR(8) NOT NULL,
    RECEIVER_LIBRARY          VARCHAR(10) NOT NULL,
    RECEIVER_NAME             VARCHAR(10) NOT NULL,
    SEQUENCE_NUMBER           DECIMAL(21, 0) NOT NULL,
    ENTRY_TIMESTAMP           TIMESTAMP NOT NULL,

    EFFECTIVE_USER            VARCHAR(10),
    QUALIFIED_JOB_NAME        VARCHAR(28),
    PROGRAM_LIBRARY           VARCHAR(10),
    PROGRAM_NAME              VARCHAR(10),

    OBJECT_LIBRARY            VARCHAR(10),
    OBJECT_NAME               VARCHAR(128),
    OBJECT_TYPE               VARCHAR(10),
    OBJECT_OWNER              VARCHAR(10),

    PREVIOUS_VALUE            VARCHAR(256),
    CURRENT_VALUE             VARCHAR(256),

    POLICY_STATUS             VARCHAR(24) NOT NULL,
    REVIEW_PRIORITY           INTEGER NOT NULL,
    REVIEW_REASON             VARCHAR(512),

    ISSUE_REFERENCE           VARCHAR(128),
    REVIEWED_BY               VARCHAR(128),
    REVIEWED_TIMESTAMP        TIMESTAMP,
    REVIEW_NOTES              VARCHAR(2048),

    UNIQUE
    (
        SOURCE_SYSTEM,
        RECEIVER_LIBRARY,
        RECEIVER_NAME,
        SEQUENCE_NUMBER,
        EVIDENCE_TYPE
    )
);

The original entry-specific fields can also remain in dedicated detail tables.

The normalized ledger is for:

• triage
• ownership
• dashboards
• recovery sign-off
• issue tracking

Do not discard the source-specific evidence.

Stage 1: Validate RU results

Start with private-authority restoration.

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    USER_PROFILE,
    LIBRARY_NAME,
    OBJECT_TYPE,
    AUTHORITY_RESTORED,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RU(
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :RECOVERY_END_TIMESTAMP
    )
)
ORDER BY
    ENTRY_TIMESTAMP,
    SEQUENCE_NUMBER;

High-priority result:

SELECT
    USER_PROFILE,
    LIBRARY_NAME,
    OBJECT_TYPE,
    ENTRY_TIMESTAMP,
    QUALIFIED_JOB_NAME
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RU(
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :RECOVERY_END_TIMESTAMP
    )
)
WHERE AUTHORITY_RESTORED = 'S'
ORDER BY
    USER_PROFILE,
    LIBRARY_NAME,
    OBJECT_TYPE;

For every S:

Preserve the main RSTAUT job log
Preserve every identified prestart job log
Find the failed object-level messages
Resolve missing objects or unavailable ASPs
Rerun authority restoration when appropriate
Collect the new RU evidence

Do not change the earlier evidence from PARTIAL to COMPLETE.

Record the rerun as a later event that resolved the issue.

Stage 2: Validate RA object-authority changes

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    AUTHORIZATION_LIST_REMOVED,
    PUBLIC_AUTHORITY_EXCLUDE,
    PRIVATE_AUTHORITY_REMOVED,
    PATH_NAME,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :RECOVERY_END_TIMESTAMP
    )
)
ORDER BY
    ENTRY_TIMESTAMP,
    SEQUENCE_NUMBER;

Flag entries where:

AUTHORIZATION_LIST_REMOVED = 'YES'
PUBLIC_AUTHORITY_EXCLUDE = 'YES'
PRIVATE_AUTHORITY_REMOVED = 'YES'
SAVE_AUTHORIZATION_LIST differs from RESTORE_AUTHORIZATION_LIST

A classification query:

SELECT
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    CASE
        WHEN AUTHORIZATION_LIST_REMOVED = 'YES'
          THEN 'AUTL REMOVED'
        WHEN COALESCE(SAVE_AUTHORIZATION_LIST, '') <>
             COALESCE(RESTORE_AUTHORIZATION_LIST, '')
          THEN 'AUTL CHANGED'
        WHEN PUBLIC_AUTHORITY_EXCLUDE = 'YES'
          THEN 'PUBLIC *EXCLUDE'
        WHEN PRIVATE_AUTHORITY_REMOVED = 'YES'
          THEN 'PRIVATE AUTHORITY REMOVED'
        ELSE 'REVIEW'
    END AS REVIEW_REASON
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :RECOVERY_END_TIMESTAMP
    )
);

Correlate private-authority removal with later RU entries and RSTAUT results.

Stage 3: Validate restored adopting programs

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    OBJECT_OWNER,
    OBJECT_ASP_NAME,
    OBJECT_ASP_NUMBER,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RP(
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :RECOVERY_END_TIMESTAMP
    )
)
ORDER BY
    ENTRY_TIMESTAMP,
    SEQUENCE_NUMBER;

Current-state validation:

WITH RP AS
(
    SELECT
        ENTRY_TIMESTAMP,
        OBJECT_LIBRARY,
        OBJECT_NAME,
        OBJECT_TYPE,
        OBJECT_OWNER
    FROM TABLE(
        SYSTOOLS.AUDIT_JOURNAL_RP(
            STARTING_TIMESTAMP =>
                :RECOVERY_START_TIMESTAMP,
            ENDING_TIMESTAMP =>
                :RECOVERY_END_TIMESTAMP
        )
    )
)
SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.OBJECT_OWNER AS OWNER_AT_RESTORE,
    P.PROGRAM_OWNER AS CURRENT_OWNER,
    P.USER_PROFILE,
    P.USE_ADOPTED_AUTHORITY,
    CASE
        WHEN P.PROGRAM_NAME IS NULL
          THEN 'NOT FOUND'
        WHEN P.PROGRAM_OWNER <> R.OBJECT_OWNER
          THEN 'OWNER CHANGED'
        WHEN P.USER_PROFILE <> '*OWNER'
          THEN 'NO LONGER ADOPTS'
        ELSE 'CURRENTLY ADOPTS'
    END AS CURRENT_STATUS
FROM RP AS R
LEFT JOIN QSYS2.PROGRAM_INFO AS P
  ON P.PROGRAM_LIBRARY = R.OBJECT_LIBRARY
 AND P.PROGRAM_NAME = R.OBJECT_NAME
ORDER BY
    R.ENTRY_TIMESTAMP;

Review:

Owner special authorities
Private authority held by the owner
Who can execute the program
Whether USEADPAUT is *YES
What the program calls
Whether the program accepts uncontrolled input

Stage 4: Extract RJ job-description restore evidence

There is no current dedicated AUDIT_JOURNAL_RJ SQL helper.

Retrieve the entries:

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    PROGRAM_LIBRARY,
    PROGRAM_NAME,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER,
    ENTRY_DATA
FROM TABLE(
    QSYS2.DISPLAY_JOURNAL(
        JOURNAL_LIBRARY =>
            'QSYS',
        JOURNAL_NAME =>
            'QAUDJRN',
        STARTING_RECEIVER_NAME =>
            '*CURAVLCHN',
        JOURNAL_ENTRY_TYPES =>
            'RJ',
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :RECOVERY_END_TIMESTAMP
    )
)
ORDER BY
    ENTRY_TIMESTAMP,
    SEQUENCE_NUMBER;

Decode the RJ entry-specific payload using the documented field positions and the correct CCSID for the environment.

The key values are:

Job description
Job-description library
Current user profile
Previous user profile
ASP name
ASP number

Validate the SQL against:

CPYAUDJRNE ENTTYP(RJ)

before using it as automated evidence.

Stage 5: Correlate later JD changes

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS CHANGED_BY,
    QUALIFIED_JOB_NAME,
    JOB_DESCRIPTION_LIBRARY,
    JOB_DESCRIPTION,
    COMMAND_TYPE,
    PREV_JOB_DESCRIPTION_USER,
    JOB_DESCRIPTION_USER,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_JD(
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :VALIDATION_END_TIMESTAMP
    )
)
ORDER BY
    ENTRY_TIMESTAMP,
    SEQUENCE_NUMBER;

The validation window should extend beyond the restore window because corrections often happen after the object restore completes.

Build the timeline:

RJ   Restored USER value
JD   Later USER value change
Current JOB_DESCRIPTION_INFO value

This reveals whether:

• the restored value was accepted
• the target profile was corrected
• the job description was later changed again
• a correction was reversed
• an unapproved profile remains active

Stage 6: Correlate potential and actual adopted authority

RP identifies adopting objects restored into the environment.

AP identifies adopted-authority activity.

SELECT
    ENTRY_TIMESTAMP,
    ENTRY_TYPE,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    OBJECT_OWNER,
    USER_NAME,
    QUALIFIED_JOB_NAME,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_AP(
        STARTING_TIMESTAMP =>
            :RECOVERY_START_TIMESTAMP,
        ENDING_TIMESTAMP =>
            :VALIDATION_END_TIMESTAMP
    )
)
ORDER BY
    ENTRY_TIMESTAMP,
    SEQUENCE_NUMBER;

AP entry types include:

S   Start
E   End
A   Adopted authority used during program activation

Use the correlation to distinguish:

Restored capability
Observed usage

A restored adopting program may never run during the validation window.

That does not remove the need to review it.

Define target-environment policy

The source system is not automatically the authority for the target.

Create explicit target policy for:

Allowed job-description profiles
Expected authorization lists
Expected object owners
Approved adopting programs
Expected USRPRF and USEADPAUT settings
Required user profiles
Critical libraries and object types

Example job-description policy:

CREATE TABLE SECURITY.JOBD_PROFILE_POLICY
(
    ENVIRONMENT_NAME         VARCHAR(20) NOT NULL,
    JOB_DESCRIPTION_LIBRARY  VARCHAR(10) NOT NULL,
    JOB_DESCRIPTION          VARCHAR(10) NOT NULL,
    EXPECTED_USER            VARCHAR(10) NOT NULL,
    BUSINESS_OWNER           VARCHAR(128),
    REVIEW_PRIORITY          INTEGER NOT NULL,
    PRIMARY KEY
    (
        ENVIRONMENT_NAME,
        JOB_DESCRIPTION_LIBRARY,
        JOB_DESCRIPTION
    )
);

Example authorization-list policy:

CREATE TABLE SECURITY.OBJECT_AUTHORITY_POLICY
(
    ENVIRONMENT_NAME       VARCHAR(20) NOT NULL,
    OBJECT_LIBRARY         VARCHAR(10) NOT NULL,
    OBJECT_NAME            VARCHAR(128) NOT NULL,
    OBJECT_TYPE            VARCHAR(10) NOT NULL,
    EXPECTED_AUTL          VARCHAR(10),
    EXPECTED_PUBLIC_AUTH   VARCHAR(12),
    BUSINESS_OWNER         VARCHAR(128),
    REVIEW_PRIORITY        INTEGER NOT NULL,
    PRIMARY KEY
    (
        ENVIRONMENT_NAME,
        OBJECT_LIBRARY,
        OBJECT_NAME,
        OBJECT_TYPE
    )
);

Example adopted-program policy:

CREATE TABLE SECURITY.ADOPTING_PROGRAM_POLICY
(
    ENVIRONMENT_NAME       VARCHAR(20) NOT NULL,
    PROGRAM_LIBRARY        VARCHAR(10) NOT NULL,
    PROGRAM_NAME           VARCHAR(10) NOT NULL,
    PROGRAM_TYPE           VARCHAR(10) NOT NULL,
    EXPECTED_OWNER         VARCHAR(10) NOT NULL,
    EXPECTED_USER_PROFILE  VARCHAR(10) NOT NULL,
    EXPECTED_USE_ADOPTED   VARCHAR(4) NOT NULL,
    BUSINESS_OWNER         VARCHAR(128),
    REVIEW_PRIORITY        INTEGER NOT NULL,
    PRIMARY KEY
    (
        ENVIRONMENT_NAME,
        PROGRAM_LIBRARY,
        PROGRAM_NAME,
        PROGRAM_TYPE
    )
);

Policy must be versioned and approved before a recovery test.

Do not create the expected-state table after seeing the results.

Assign review priorities

Suggested priorities:

100   Critical — immediate containment or correction
80    High — security owner review required
50    Medium — application owner validation
20    Low — expected operational difference
0     Informational

Examples:

RU = S                                     100
Unexpected *ALLOBJ owner on adopting PGM   100
Restored JOBD uses production profile      100
Authorization list removed                  80
Public changed to *EXCLUDE                  80
Private authority removed                   80
Expected adopting program restored          20
Approved environment-specific AUTL          20

The priority should guide review order.

It should not automatically determine remediation.

Build a validation summary

SELECT
    EVIDENCE_TYPE,
    POLICY_STATUS,
    COUNT(*) AS EVIDENCE_COUNT,
    MAX(REVIEW_PRIORITY) AS HIGHEST_PRIORITY,
    MIN(ENTRY_TIMESTAMP) AS FIRST_EVENT,
    MAX(ENTRY_TIMESTAMP) AS LAST_EVENT
FROM RECOVERY.SECURITY_EVIDENCE
WHERE RECOVERY_ID = :RECOVERY_ID
GROUP BY
    EVIDENCE_TYPE,
    POLICY_STATUS
ORDER BY
    HIGHEST_PRIORITY DESC,
    EVIDENCE_TYPE,
    POLICY_STATUS;

A recovery dashboard should show:

Expected profiles
RU complete
RU partial
RA authorization-list removals
RA public *EXCLUDE changes
RA private-authority removals
RP adopting programs
RP owner mismatches
RJ restored named profiles
JD post-restore changes
Open high-priority findings
Oldest unresolved finding
Evidence collection status

Distinguish zero rows from failed collection

A collector can produce no rows because:

No matching events occurred
The requested receiver was unavailable
The caller lacked authority
The function was unavailable at the installed PTF level
The time or sequence range was wrong
Auditing was not active
The query failed

Store collection status separately:

CREATE TABLE RECOVERY.EVIDENCE_COLLECTION_RUN
(
    COLLECTION_ID         BIGINT
                          GENERATED ALWAYS AS IDENTITY,
    RECOVERY_ID           VARCHAR(40) NOT NULL,
    EVIDENCE_TYPE         CHAR(2) NOT NULL,
    START_TIMESTAMP       TIMESTAMP NOT NULL,
    END_TIMESTAMP         TIMESTAMP,
    ROWS_COLLECTED        INTEGER,
    STATUS                VARCHAR(20) NOT NULL,
    SQLCODE               INTEGER,
    SQLSTATE              CHAR(5),
    ERROR_MESSAGE         VARCHAR(2048),
    STARTED_TIMESTAMP     TIMESTAMP NOT NULL,
    COMPLETED_TIMESTAMP   TIMESTAMP
);

Only a successful collection can support:

No matching evidence found

Authority required for collection

Every AUDIT_JOURNAL_xx helper shares common requirements.

The collector needs:

*USE authority to QSYS/QAUDJRN
*OBJEXIST authority to QSYS/QAUDJRN
*USE authority to every requested receiver

It also needs the appropriate library authority.

Current-state queries such as:

PROGRAM_INFO
OBJECT_PRIVILEGES
AUTHORIZATION_LIST_INFO
JOB_DESCRIPTION_INFO
USER_INFO

can require additional authority or function usage.

Use:

• a dedicated noninteractive collection profile
• explicit authority
• controlled function usage
• protected result tables
• separate review and remediation roles
• no unnecessary *ALLOBJ

Receiver retention is part of the control

The workflow depends on audit receiver availability.

Expose:

Oldest required receiver
Current collection receiver
Current attached receiver
Evidence-safe-through receiver
Unresolved investigation receiver
Legal-hold receiver

Do not delete a detached receiver merely because it is old.

A receiver can still be required for:

• DR sign-off
• incident investigation
• audit review
• legal retention
• SIEM forwarding
• replay after collector failure

Receiver cleanup should consume the evidence checkpoints, not guess from age or naming patterns.

Do not run RCLSTG between RSTUSRPRF and RSTAUT

Authority reference tables restored with user-profile security information are required by RSTAUT.

Running:

RCLSTG

between:

RSTUSRPRF

and:

RSTAUT

can remove those tables and prevent authority restoration.

Treat this as a runbook control and an explicit recovery checkpoint.

Do not auto-remediate from audit entries alone

Audit evidence tells you what happened.

It does not always tell you what the target state should be.

Do not automatically:

• relink every saved authorization list
• grant every removed private authority
• restore every source-system owner
• change every restored JOBD to its previous user
• remove adopted authority from every restored program
• reverse every public *EXCLUDE result

The target may intentionally differ from the source.

The safe sequence is:

Collect
Preserve
Classify
Compare with approved target policy
Validate current state
Assess operational impact
Approve remediation
Apply the controlled change
Retest
Close with evidence

Recovery-security sign-off

A recovery should not be security-complete until:

The recovery window and journal boundary are recorded
Every required evidence query completed successfully
All RU partial results are resolved or accepted
All RA authority changes are classified
Every restored adopting program is reviewed
Every RJ named-profile restore is validated
Later JD changes are correlated
Critical adopted-authority use is reviewed
Current state matches approved target policy
Application access is tested
Open findings have owners and deadlines
Audit receivers are retained
Evidence is preserved
Security and application owners approve the result

Compatibility planning

The services in this workflow arrived through different IBM i update streams.

At the time of publication:

AUDIT_JOURNAL_JD and AUDIT_JOURNAL_RU
  IBM i 7.6 — Db2 Group PTF SF99960 Level 3
  IBM i 7.5 — Db2 Group PTF SF99950 Level 12

AUDIT_JOURNAL_RP
  IBM i 7.6 — Db2 Group PTF SF99960 Level 2
  IBM i 7.5 — Db2 Group PTF SF99950 Level 11

AUDIT_JOURNAL_RA
  IBM i 7.5 — Db2 Group PTF SF99950 Level 4
  IBM i 7.4 — Db2 Group PTF SF99704 Level 25

RJ
  Use QSYS2.DISPLAY_JOURNAL or CPYAUDJRNE.

Confirm the installed group PTF before deploying the workflow.

For older releases or lower PTF levels, CPYAUDJRNE remains a general formatted-audit extraction option.

Related Era of i implementation guides

• Audit IBM i Job Description USER Changes with SQL
• Track Restored User-Profile Authorities on IBM i with SQL
• Audit Restored IBM i Job Descriptions That Specify a User Profile
• Audit Authority Changes Caused by Restored IBM i Objects with SQL
• Track Restored IBM i Programs That Adopt Authority with SQL
• Build an IBM i Security and PTF Visibility Workflow with SQL

Final takeaway

IBM i already records the security evidence needed to validate a recovery.

The entries answer different parts of the problem:

RU   Was authority fully restored for the profile?
RA   Did object authority change during restore?
RP   Did an adopting program return?
RJ   Did a restored JOBD contain a named profile?
JD   Was that profile later created or changed?
AP   Was adopted authority actually used?

The value comes from combining them.

A strong recovery process does not stop at:

The save media restored and the applications started.

It reaches:

The restored identities, authorities, owners, authorization lists, and privilege paths were compared with an approved target policy; exceptions were investigated; current behavior was tested; and the evidence was preserved.

That is the difference between restoring an IBM i partition and validating its security.