Governing Business Actions, Not Entitlements
By Tuhin Banerjee, Senior Director Saviynt Inc.
1. Abstract
Mainframe and IBM i platforms continue to run the enterprise’s most critical financial and operational workloads, yet access governance for these systems is frequently undermined by cloud-style entitlement models that do not reflect how they authorize work. In practice, this mismatch strips access of business meaning, for example, when approvers are asked to certify HLQs or transaction IDs without knowing what business action they enable. It obscures segregation-of-duties risk and turns certification into approximation rather than control. The most significant access risks on z/OS and IBM i rarely arise from a single permission. They emerge from sequences of legitimate actions executed over time behaviour that entitlement-centric governance is structurally unable to detect or constrain. This article introduces a capability-centric access governance model that defines access in terms of concrete business actions, expressed directly in native authorization semantics. By preserving platform enforcement and adding a thin policy and evidence overlay, without modifying application code, the model enables sequence-aware segregation of duties, just-in-time elevation, and human-readable audit evidence. Practical examples demonstrate how governing behaviour rather than permissions reduces standing privilege and restores decision-quality access certification.
2. The Governance Failure Is Not the Platform
In most environments I have worked with, this shows up very quickly during access reviews. If an organisation’s balance sheet still closes on z/OS or IBM i, the platform itself is rarely a security problem. The failure lies in how access to these systems is governed. In many enterprises, identity programs flatten native mainframe and IBM i controls into generic “entitlements” to align with cloud identity platforms. While this abstraction simplifies integration, it strips away operational meaning. Approvers are asked to certify resource identifiers HLQs, transaction IDs, object authorities, without understanding what work those permissions enable. Faced with ambiguity, they approve defensively. Over time, defensive approval becomes standing privilege, and standing privilege becomes normalized risk.
Static conflict – SoD Violation ≠ Permission A ∩ Permission B —- (1)
Mainframes do not authorize in abstractions. They authorize in precise operational language: CICS transactions, DB2 plans, JES classes, libraries, menus, and objects. When that language collapses into a spreadsheet, governance breaks at the point where human judgment is required.
SoD Violation = Action A – Action B within Time Window T —- (2)
That single arrow (→) is the difference between checkbox governance to actual risk control
3. Why Entitlement-Centric Models Break Down
Entitlement-centric identity models implicitly assume that permissions can be meaningfully grouped, that segregation of duties can be evaluated statically, and that access reviews can be completed without deep platform context. In legacy-critical systems, these assumptions break down quickly, especially once you look at how work is performed over time
On z/OS and IBM i, risk is rarely associated with a single permission. It emerges from sequences of actions executed over time: the same individual entering and releasing payroll exceptions or submitting and posting invoices within the same accounting period. Static role analysis does not capture this behaviour.
To compensate for operational fragility, organizations frequently rely on standing special authorities, broad HLQ access or ALLOBJ as safety nets. These privileges persist long after their original justification, creating latent risk that auditors repeatedly flag but rarely see resolved.
4. Defining Access as Capability
A more effective approach is to govern capabilities, not entitlements. Put simply, a capability answers a practical question, “what work does this access actually allow someone to do?,” A capability describes a concrete business action that the system can perform, expressed in the platform’s native authorization terms. It answers a simple question: What work does this access allow someone to do?
a. Capability Structure
Each capability explicitly lists the native resources required to perform that action:
• z/OS: CICS transactions, DB2 plans, MQ queues, and HLQs
• IBM i: menu paths, programs, libraries, and object authorities
What matters here is not the list itself, but that each element maps directly to something an operator or system executes. Standing special authorities are explicitly excluded from steady-state capabilities
This reframing allows approvers to certify understandable business actions, rather than opaque collections of permissions.
5. Segregation of Duties as Behaviour, Not Static Conflict
Traditional segregation-of-duties models treat violations as static conditions. In practice, most SoD violations are not static conflicts, they emerge over time, often across perfectly legitimate actions. During execution, fraud and error almost always arise from temporal and sequential behaviour.
A capability-centric model expresses SoD as event chains:
• A user who submits payroll cannot release exceptions for the same entity in the same cycle.
• A user who enters an invoice cannot approve and post it within the same period.
These constraints are evaluated at runtime, where risk materializes, rather than inferred during periodic reviews.
6. A Thin Overlay for Context and Control
The capability model does not replace native enforcement. z/OS and IBM i remain the systems of record for authorization. What is introduced is a thin policy overlay placed in front of access paths such as 3270 or 5250 sessions.
In most implementations, this overlay is introduced incrementally to avoid disrupting existing operational flows. The overlay evaluates context (who, what, where, and when), enables just-in-time elevation for rare tasks, and enforces sequence-based controls. Elevation is
timeboxed, logged, and automatically revoked. No COBOL or RPG code is modified; the overlay governs behaviour, not applications.
7. Evidence From Native Telemetry
Both platforms already generate authoritative telemetry:
• SMF Type 110 records CICS transaction activity on z/OS
• QAUDJRN captures security-significant events on IBM i
Rather than exporting raw logs, capability governance converts this data into concise usage summaries attached directly to each certification item, for example:
“Capability exercised twice in the prior week; no conflicting sequences observed.”
This shifts certification from inference to evidence. While these logs are rich, they are rarely used directly in governance due to their volume and lack of immediate business context
8. Practical Illustrations
In many cases, organizations arrive at this model after multiple audit findings tied to the same
pattern.
a. Accounts Payable on z/OS
Conventional approach:
A broad finance role with generic HLQ access to avoid operational disruption.
Capability-centric approach:
Post accounts payable ≤ $5,000 includes defined CICS transactions, DB2 plans, message
queues, and scoped HLQs. If the same user approved the invoice earlier in the cycle, the runtime
gate blocks posting.
b. Payroll Exceptions on IBM i
Conventional approach:
Permanent ALLOBJ authority for operators.
Capability-centric approach:
Release payroll exceptions is defined by menu paths and minimal object authorities. If elevated
access is required, it is granted just-in-time, logged, and revoked automatically.
9. Questions Security Leaders Should Ask
A capability-centric program can be evaluated with three questions:
1. Where is the capability dictionary?
If capabilities do not reference native transactions or objects, governance remains
entitlement-centric.
2. Can you demonstrate blocked behaviour?
Effective SoD is observable at runtime, not asserted on paper.
3. Does evidence accompany certification?
Reviews should include concise usage summaries sourced from platform telemetry.
If you cannot answer this clearly, the model is likely still entitlement-centric in practice
10. Governing Legacy Systems on Their Own Terms
Boards expect proof that standing privilege has been reduced. Auditors expect approvals tied to real work and defensible evidence.
Operations teams expect modernization without destabilizing critical systems.
Capability-centric access governance meets these expectations by governing mainframe and IBM
i environments on their own terms, with clarity that aligns technical control to business intent.
Figure 1. Capability-centric access governance model showing native authorization, runtime policy evaluation, and evidence generation across z/OS and IBM i environments.
11. Conclusion
The challenge facing access governance on z/OS and IBM i is not one of tooling maturity or platform relevance; it is a failure of framing. In my experience, the hardest part is not defining capabilities, it is letting go of entitlement-based thinking that has been normalized for years. For years, organizations have attempted to govern systems that operate in precise, action-oriented languages by translating them into abstract entitlements that neither reflect real work nor support meaningful human judgment. The result has been predictable: defensive approvals, persistent standing privilege, and a governance process that manages artifacts while missing behaviour. Capability-centric governance reasserts a simple but often overlooked principle, access only has meaning when it is tied to what the system allows someone to do. By defining authorisation in terms of concrete business actions, evaluated in context and over time, organizations regain the ability to govern where risk truly materializes. Sequence-aware controls, just-in-time elevation, and evidence derived from native telemetry do not add complexity to the platform; they remove ambiguity from decision-making. Most importantly, this approach restores accountability. Approvers are no longer asked to bless opaque identifiers, auditors are no longer forced to infer intent from raw logs, and operators are no longer granted permanent power “just in case.” Instead, access decisions become explicit, observable, and defensible. As enterprises continue to modernize around cloud, automation, and autonomous systems, the lessons from z/OS and IBM i are not outdated, they are instructive. That shift is uncomfortable, but necessary. Systems that have always enforced work through explicit action and sequence expose the limits of entitlement-centric thinking. Governing these platforms on their own terms does more than reduce risk; it offers a clearer model for how access governance should work everywhere: grounded in behaviour, constrained by context, and accountable to evidence.
