The Translation Problem
An auditor arrives with a control framework written for a general computing environment. You have a platform with special authorities, adopted authority, library lists, exit points, and a journal receiver model that has no direct equivalent anywhere else. Nothing in the framework tells either of you how those map.
The shops that do well here are not the most secure ones. They are the ones that wrote the mapping down before the auditor showed up. That document, boring as it is, converts a week of discovery into an afternoon of evidence.
What the Main Frameworks Actually Want
Framework Requirements Translated to IBM i
This is a working translation, not legal advice. Your auditor's interpretation of a control is the one that counts, which is exactly why agreeing the mapping with them early is worth the meeting.
| Framework | What It Asks For | Where It Lands on IBM i |
|---|
| SOX | Controls over financial reporting systems, separation of duties, change management, and evidence that access is restricted and reviewed. | Special authority review, adopted authority on financial applications, QAUDJRN change auditing, and a documented profile review cycle. |
| PCI DSS | Cardholder data protected at rest and in transit, unique IDs, MFA for access, logging retained, and regular testing. | Column-level or field encryption in Db2 for i, TLS on all network access, MFA on sign-on and exit points, QAUDJRN forwarded and retained. |
| HIPAA | Access controls, audit controls, integrity, and transmission security for protected health information. | Object and field-level authority on PHI libraries, audit journaling of read access, and encryption of data leaving the system. |
| GDPR | Lawful access to personal data, demonstrable security of processing, and the ability to find and erase records. | Knowing which libraries and files hold personal data, authority restrictions on those objects, and a real answer to who read this record. |
| NIS2 | Risk management, incident handling, and supply chain security for essential and important entities. | Documented assessment cycle, monitored exit-point and audit journal activity, and vendor access controls that are actually enforced. |
What Auditors Ask For, Almost Every Time
A List of Profiles With Special Authorities
Specifically *ALLOBJ, *SECADM, *SPLCTL, and *SERVICE, with a business justification for each. The list is easy. The justifications are where it falls apart.
Evidence That Access Is Reviewed
Not that it is correct. That somebody looked, on a schedule, and signed something. A monthly automated report with a reviewer name beats an annual perfect one.
Proof the Audit Journal Is On and Retained
QAUDCTL and QAUDLVL settings, plus retention. If receivers are being deleted at the end of the week, say so before they find it.
Separation of Duties
That the person administering security is not the only person reviewing it. On small IBM i teams this is the hardest control to satisfy honestly.
Change Management on Production Objects
Who can move a program into production, and where that is recorded. Adopted authority and library list handling both come up here.
Password Policy in Force
QPWDLVL, expiry, minimum length, and reuse rules as actually set, not as documented in a policy nobody applied.
Where Compliance Monitoring Software Fits
Compliance monitoring products for IBM i mostly do three things: collect audit journal and exit-point data continuously, run it against a rule set mapped to a framework, and produce reports formatted for someone who does not know what a journal receiver is. That third one sounds trivial and is frequently the reason the software gets bought.
The honest limitation is that these tools report against controls, not against risk. A system can produce a clean compliance dashboard while carrying twenty profiles with *ALLOBJ, because the rule set checked that special authorities were reviewed, not that there were few of them. Compliant and secure overlap. They are not the same set.
Buy it when the reporting burden is real and recurring, when you have multiple frameworks to satisfy at once, or when the audit evidence is currently being assembled by hand each cycle. Do not buy it expecting the findings to shrink. It tells you where you stand more clearly, more often, and in a format somebody else will read.
The Gap Worth Naming
Every recurring industry assessment tells the same story: the average IBM i system passes its audits and still carries default passwords, excessive special authorities, and unguarded exit points. Those two facts sit together comfortably, because the audit checked whether a process existed and the assessment checked what the settings were.
That is not an argument for ignoring compliance. Compliance work is often the only reason IBM i security gets funded at all, and using an audit cycle to finance a genuine cleanup is a reasonable trade. It is an argument for not mistaking the certificate for the outcome.
If you want one thing from this page: write the control mapping down and keep it current. It is the cheapest artefact in the whole compliance process and it does more work than any single product you can buy.