RACF Security Audit Checklist: LISTUSER, RLIST, SETROPTS, and SMF

Check access before changing RACF audit settings.

Last updated: August 31, 2026

A RACF audit normally starts with a simple question: which IDs, groups, datasets, resources, and audit options can explain the access seen in production? The answer is usually spread across user profiles, group connections, dataset profiles, general resource classes, SETROPTS options, and SMF records. This guide gives a practical review path for a security administrator, auditor, or mainframe developer supporting a production issue.

The examples use common RACF TSO commands such as LISTUSER, LISTDSD, RLIST, SEARCH, and SETROPTS LIST. Run commands only with the authority approved at your site, and raise a change record before altering audit settings in production.

What A RACF Security Audit Should Check

A useful RACF security audit checks the path from identity to evidence. Start with the user ID, then confirm group authority, direct dataset or resource access, global RACF settings, and the SMF records that prove what happened. That order keeps the review tied to an actual access path instead of a loose list of profiles.

Audit area	RACF command or source	What to review
User profile	LISTUSER userid ALL	Special attributes, owner, default group, revoke date, password settings, and user audit flags.
Group membership	LISTGRP group-name ALL	Connected users, group authorities, owners, and nested group control.
Dataset profile	LISTDSD DATASET('HLQ.**') ALL	Universal access, access list entries, audit options, and owner.
General resource	RLIST class profile ALL	Access to FACILITY, OPERCMDS, JESJOBS, APPL, STARTED, and other active classes.
Audit controls	SETROPTS LIST	Active classes, logging controls, generic profile options, and global audit settings.
Event proof	SMF type 80 records	Permit, violation, profile change, and other security events recorded by RACF.

Start With The User ID

For an access review, begin with the user profile. A single user ID can inherit authority from a default group, connected groups, OPERATIONS, SPECIAL, group-SPECIAL, AUDITOR, or group-AUDITOR. That is why a clean audit note should show both the user profile and the group path that grants access.

LISTUSER JDOE ALL
LISTGRP PAYROLL ALL

Check for high-risk attributes first. SPECIAL can administer RACF widely, OPERATIONS can affect dataset access, and AUDITOR can list many profiles and set some audit controls. IBM documents separate behavior for AUDITOR and group-AUDITOR attributes, so do not treat group-level auditor authority as the same thing as system-wide auditor authority.

Review Dataset And Resource Access

Most application access checks involve either datasets or general resources. Dataset profiles protect names such as PAYROLL.PROD.MASTER, while general resources protect class/profile pairs such as FACILITY BPX.SUPERUSER or an application profile in APPL.

LISTDSD DATASET('PAYROLL.**') ALL
RLIST FACILITY BPX.SUPERUSER ALL
RLIST OPERCMDS MVS.MCSOPER.* ALL

Look at UACC, access list entries, conditional access, warning mode, and audit options. A profile with UACC(READ) may be acceptable for a public reference library, but it is a red flag for payroll, cardholder, health, or privileged operational data. If a profile uses warning mode, access might be allowed while RACF logs a warning event, so include it in the risk note.

Use SEARCH Carefully

SEARCH is useful when you know part of a profile name but not the exact entry. It can also create command output for a follow-up review. Keep the scope tight; broad searches can return a large amount of output and slow down the audit.

SEARCH CLASS(DATASET) MASK(PAYROLL) CLIST
SEARCH CLASS(FACILITY) MASK(BPX) CLIST

IBM notes in its RACF listing guidance that command output can become very large and that the displayed output is not a supported programming interface. For automated reporting, use the RACF database unload utility IRRDBU00 rather than scraping terminal output.

Check SETROPTS Audit Controls

SETROPTS LIST shows active classes and many RACF-wide options. During a review, use it to confirm whether relevant classes are active, whether generics are enabled, and which audit controls are active for the classes under review.

SETROPTS LIST
SETROPTS AUDIT(USER GROUP DATASET FACILITY)

The second command changes audit controls and should only be used by an authorized security administrator under site procedure. For review-only work, list the current settings and attach the evidence to the ticket. IBM’s RACF documentation covers setting and listing audit controls and listing specific audit controls.

When To Use UAUDIT

UAUDIT records selected RACF activity for a user. It is useful for a short investigation window, for example when an ID is used by a batch process and the team needs to prove which protected resources it touches. Do not leave user-level auditing active forever without a reason, because it can add noise to the security event stream.

ALTUSER JDOE UAUDIT
LISTUSER JDOE ALL

After the review window ends, remove the setting if your approved procedure requires it. Keep the before-and-after listing with the incident or change ticket so another reviewer can see exactly when user auditing was enabled.

Read The Evidence In SMF Records

RACF security decisions and profile changes are recorded in SMF, especially type 80 records. Depending on your site and security products, type 81 and type 83 records can also matter. The audit report should identify which SMF extract was reviewed, the time range, and the event types found.

For RACF, an SMF extract can answer questions that profile listings alone cannot answer: did the access happen, was it allowed or denied, which profile matched, and which user or started task made the request? IBM provides reference material for SMF records and reformatted RACF SMF records.

Sample RACF Audit Checklist

Use this checklist when a production owner asks, “Can this ID access this resource?” It keeps the review small enough to finish, but it still captures the evidence a second reviewer needs.

1. Record the user ID, group, dataset or resource name, system, LPAR, and time window.
2. Run LISTUSER userid ALL and note special attributes, revoke status, owner, and default group.
3. Run LISTGRP group ALL for the default group and any connected group that may grant access.
4. Run LISTDSD or RLIST for the exact profile and any covering generic profile.
5. Run SETROPTS LIST to confirm class activation, generic profile handling, and audit settings.
6. Pull SMF type 80 records for the review window and compare events with the profile listings.
7. Write the finding as allowed, denied, allowed by warning, or unresolved because the matching profile or SMF extract is missing.

Common RACF Audit Findings

Access Comes From A Group, Not The User ID

A user may not appear directly on a profile access list but still gain access through a connected group. Always capture the group connection, group authority, and profile access entry in the finding.

The Generic Profile Is The Real Match

A dataset such as PAYROLL.PROD.MASTER may be protected by PAYROLL.** rather than an exact profile. Review both exact and generic coverage before deciding that access is missing.

Warning Mode Hides A Future Failure

Warning mode can allow access while recording that access would fail if warning mode were removed. Treat that as a migration or cleanup issue, not as proof that the rule is permanently acceptable.

Internal Reading

For related Mainframe Forum topics, review mainframe security trends, the z/OS operating system, Db2 command reference patterns, and Db2 application environment controls. The Db2 articles are not RACF references, but they show the same production habit: list the running environment, prove the access path, and record the exact command output used for review.

FAQ

Which RACF command lists a user profile?

Use LISTUSER userid ALL. Review the default group, connected groups, special attributes, revoke status, owner, and any user audit setting.

Which RACF command lists dataset access?

Use LISTDSD DATASET('dataset-name') ALL for a dataset profile. For broad review work, confirm whether a generic profile such as PAYROLL.** protects the target dataset.

Where does RACF write security audit events?

RACF writes security events to SMF records, especially type 80. Your site may also review other SMF record types depending on the security setup and reporting tools.

Should I parse LISTUSER or RLIST output in a program?

For repeatable reporting, use RACF database unload data such as IRRDBU00. Terminal command listings are useful for human review, but they are not the best source for a production reporting program.

A good RACF audit note is short, repeatable, and evidence-based: user profile, group path, protected profile, SETROPTS context, and SMF event proof.