The Compliance Gap Between IBM i Administrators and Security Teams

In the world of enterprise IT, the IBM i (formerly AS/400) is a powerhouse of reliability. However, it often exists as an island. On one side, you have the IBM i Administrators, the guardians of uptime and performance. On the other, the Security and Compliance Officers, the guardians of data integrity and regulatory standards.

IBM i environments rarely fail audits due to missing controls. Instead, they fail because administrators and security teams misunderstand each other. This gap isn’t a technical glitch; it’s a compliance gap that leaves businesses vulnerable to audits and bad actors. Organizations overlook this gap because it’s hidden—admins focus on uptime and performance, while security pros chase regulatory checkboxes. This misalignment leaves systems vulnerable.

The result:

• Security tools sit installed but unused
• Audit findings repeat year after year
• No one owns “compliance” end-to-end

I’m working with clients in various regions, including South Asia, Southeast Asia, and the Middle East, for years. As a service provider/vendor, I’ve also observed a gap between IBM i administrators and Security/IS audit teams in many clients. Sometimes, aligning these teams together for implementations is challenging.

This gap does more damage than any single misconfigured system value. In this post, I explore the roots of this issue, why it persists, real-world audit horror stories, and practical ways to close it. I include examples and IBM i commands to make actionable steps clear.

Two Worlds, One System – The Language Mismatch

Organizations compound the problem by siloing teams. Admins report to IT operations, security to compliance officers. This structure fosters “us vs. them” dynamics, where admins resist security mandates as bureaucratic hurdles. Administrators and security teams often talk past each other because they use different vocabularies.

Admins prioritize system reliability and efficiency, discussing concepts like object authorities, user profiles, and system values in operational terms. Security teams, however, frame everything through risk, compliance standards like PCI DSS or GDPR, and threat vectors. This mismatch creates confusion during discussions or audits.

• Consider a scenario where an admin grants *ALLOBJ special authority to a user profile for quick troubleshooting. The admin sees this as a temporary fix to maintain uptime. The security team views it as a massive risk, equivalent to handing over the keys to the kingdom, potentially violating SOX compliance. The admin might say, “I need this for daily ops,” while security responds, “This exposes us to insider threats.” Without a common language, teams fail to align.

• Another exapmle, IBM i’s built-in tools exacerbate this. Admins use commands like DSPUSRPRF USRPRF(QSECOFR) to display user profiles, focusing on functionality. Security teams want reports on audit journal entries, like authority failures (AF) via DSPJRN JRN(QAUDJRN), to track risks. The disconnect leads to admins underusing security features because they seem irrelevant to core duties. To illustrate, in many shops, admins ignore exit programs because they sound like “security jargon,” not realizing these monitor network access points like FTP or ODBC.

The Conflict

• The Security Team asks: “Can we get a real-time feed of all privileged access attempts?”
• The IBM i Admin hears: “Do you want me to dump the QAUDJRN and kill our system performance?”

Because the IBM i uses a proprietary database (DB2 for i) and unique logging structures, security teams often treat it as a “black box,” assuming it’s inherently secure because it’s “obscure.” This is a dangerous myth.

How Admin Team Think	How Security Team Think
Administrators describe IBM i in operational terms:	Security teams describe IBM i in control and risk terms:
Jobs Subsystems Libraries Profiles Authorities Performance impact “This has worked for 20 years”	Least privilege Segregation of duties Logging completeness Audit evidence Regulatory mappings Incident traceability
Their success metric: “The system runs. Users are happy. Nothing breaks.”	Their success metric: “We can prove control effectiveness to an auditor.”

The Core Problem

Both teams talk about security, but they mean different things.

What Actually Happens

• Admin keeps *ALLOBJ
• Security writes an exception
• Next audit flags the same issue
• No remediation plan exists

The problem isn’t ALLOBJ.
The problem is no shared remediation model.

Why Security Tools Go Unused on IBM i

IBM i boasts robust built-in security, but teams leave tools gathering dust due to overconfidence, complexity, and competing priorities. Many admins believe the system’s “out-of-the-box” security suffices, a myth rooted in its legacy as a closed platform. In reality, default settings like passwords matching user profiles invite breaches.

Many organizations purchase expensive Security I tools, only to realize they aren’t capturing IBM i data correctly.

• Noise vs. Signal: A raw IBM i audit journal can generate millions of entries. Without proper filtering, the SOC gets “alert fatigue” and ignores the IBM i feed entirely.
• Lack of Context: An alert showing a “Profile Swap” might look like a hack to a security analyst, but to an admin, it’s a standard procedure for a batch job.

Example 1: The “Disabled Profile” Trap

When a user fails a login three times, the IBM i disables the profile.

• Admin view: Just a helpdesk ticket to reset a password.
• Security view: A potential brute-force attack. Without a shared tool to categorize this, the response remains reactive instead of proactive.

Example: 2 Take exit programs

IBM i allows registration of custom code to control server access, using commands like WRKREGINF to work with exit points.

• Audits show only 10% of systems implement them.
• Admins view setup as time-consuming—registering an exit program requires ADDEXITPGM EXITPNT(QIBM_QPWFS_FILE_SERV) FORMAT(PWFS0100) PGM(MYLIB/MYEXITPGM) TEXT('IFS Access Security Exit') and they prioritize application support over “hypothetical” threats.

Example 3: Performance Fear Without Measurement

Admins hear: “Enable auditing for object access”

• Admins think: “That will kill performance”
• No one measures: QAUDJRN

No baseline. No data. Just fear.

Where the Gap Shows Up

Audit Question

1. “How do you detect unauthorized access to sensitive files?”
   • Admin Response: Authorities are set correctly.
   • Auditor Follow-up: “Show me evidence of detection.”

2. “How do you review special authority usage?”
   • Admin Shows: WRKUSRPRF
   • Auditor Asks: “Who reviews this? How often? Where is it documented?”

3. Logging Without Context
   • Admins enable auditing: CHGSECAUD QAUDLVL(*AUTFAIL *OBJMGT)
   • Security pulls logs: No one correlates:
     • User
     • Program
     • Adopted authority
     • Business function
   • Auditors call this “logging without monitoring”.

Real-World Audit Failures

Audits reveal the gap’s consequences in stark detail. Fortra’s annual State of IBM i Security Study analyzes hundreds of systems and uncovers persistent issues. In 2022, only 10% monitored network exits, leaving data flows unchecked. One audited partition had over 100 users with default passwords, a direct path for attackers.

In many shops, admins use the QSECOFR (Security Officer) profile for daily tasks because it’s “easier.” During an audit, if the security team cannot show who was behind the QSECOFR session, the company fails the “Accountability” requirement of PCI-DSS or SOX.

• A manufacturing firm faced a breach when an attacker exploited an unmonitored FTP server. The admin had enabled it for file transfers without exit programs, thinking it “just worked.” Security audits later showed AF journal entries logging failed attempts, but no one reviewed them using DSPAUDJRNE ENTTYP(AF). The incident cost thousands in downtime and fines.

• In healthcare, a hospital’s IBM i system violated HIPAA during an audit. Admins granted *ALLOBJ to developers for efficiency, but security flagged it as excessive privilege. The audit revealed unchecked object authorities via DSPOBJAUT OBJ(LIB/FILE) OBJTYPE(*FILE), exposing patient data. Remediation involved revoking authorities with RVKOBJAUT, but the gap delayed fixes.

• Financial sectors see similar issues. A bank audit found unused profiles with powerful authorities, lingering from past employees. Commands like ANZDFTPWD could have identified them, but admins skipped it. Ransomware exploited this, encrypting files and demanding payment. These examples show how organizational disconnects turn minor oversights into major crises.

Why “No Incidents” Is Not a Success Metric

Bridging the Gap with Shared Metrics

Teams close the compliance gap by adopting shared metrics that translate admin actions into security outcomes. Start with joint dashboards tracking key indicators like user profile compliance, exit point coverage, and audit journal reviews. Many Compliance Assessment and Reporting Tools provide centralized views without remote access, maintaining separation of duties.

• Translate Security Controls into Operational Metrics
  • Instead of: Least privilege enforced
  • Use: Number of *ALLOBJ profiles reduced per quarter
• Measure Adopted Authority Usage
  • Security cares about risk. Admins care about impact.
  • Shared metric: Number of adopted authority programs actively used
    • Review: Owner, Adoption, Call frequency
• Align Auditing to Business Functions
  • Instead of: Object access logged
  • Define: Payroll data accessed outside payroll window
    • Admins define batch windows.
    • Security defines detection rules.
• Define Joint Ownership Explicitly
  • Document:
    • Admin owns implementation
    • Security owns control validation
    • Audit owns evidence requirements
  • No shared ownership = no accountability.
• Modernize the Log Delivery
  • Instead of manual reports, use Automated Reporting tool or Syslog to push events to the SOC. This transforms “Green Screen” data into something a security analyst can read.

Finally, leadership must champion this. Appoint a liaison role to facilitate communication, ensuring metrics like breach response time or compliance score become KPIs for both teams.

A Practical Operating Model

Monthly (Admin + Security)

• Review special authorities
• Review adopted authority programs
• Review audit journal volume and coverage

Quarterly

• Remove unused profiles
• Reduce *PUBLIC authority
• Validate exit program coverage

Annually

• Re-map IBM i controls to compliance frameworks
• Test incident scenarios
• Validate log retention

Act Now to Secure Tomorrow

The compliance gap in IBM i environments wastes resources and invites risks, but organizations fix it through better communication, tool adoption, and metrics. Admins and security teams unite when they share a common goal: resilient systems. Start small—run a joint audit with the commands I mentioned—and build from there. Your IBM i deserves it, and so does your business.