Accountability usually sits with the organisation that owns the protected data and the platform operations team that administers the key lifecycle. Security leadership should define policy, operations should execute controls, and compliance should verify evidence. In practice, ownership must be explicit across creation, use, backup, recovery, rotation, and retirement.
Who carries accountability for z/OS cryptographic keys?
When cryptographic keys on z/OS are exposed or mishandled, accountability is usually shared but not diluted. The business owner of the data remains accountable for the protection outcome, while the platform, security, and operations teams are accountable for the key management controls that make that outcome achievable. The key point is that cryptographic protection is only defensible when someone can show who approved access, who maintained the lifecycle, and who verified the control evidence.
This matters because key exposure is not just a technical problem. If ownership is vague, teams can end up assuming someone else handled generation, storage, rotation, backup, or retirement, which creates control gaps that are hard to detect after the fact. Formal governance is the difference between a contained incident and an unanswerable compliance failure. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties accountability to control ownership, evidence, and oversight rather than to a single technology team alone. In practice, many security teams discover ownership gaps only after a key event has already become an audit issue.
How accountability should map to the key lifecycle
On z/OS, accountability should follow the lifecycle rather than stop at the point of creation. The organisation that owns the protected workload or regulated data is accountable for deciding whether the cryptographic control is required, acceptable, and properly governed. Platform operations is then accountable for implementing and maintaining the key infrastructure, including access paths, backup handling, recovery procedures, rotation support, and retirement steps. Security leadership is accountable for the policy model, separation of duties, and exception handling, while audit or compliance functions verify that the process is evidenced rather than assumed.
The practical failure mode is role confusion. If the data owner believes operations owns the risk, operations may believe security owns the policy, and neither may own the evidence needed to prove control integrity. That becomes especially important where keys are used across multiple systems, shared service functions, or long-lived batch jobs. Accountability should therefore be documented in the same place as the operating model, not left in a diagram that no one updates.
- Assign a named business owner for each protected data domain.
- Assign a named technical owner for the z/OS key lifecycle controls.
- Require approval for key creation, access, export, recovery, and retirement.
- Retain evidence for who performed each lifecycle action and when.
- Separate policy approval from routine operational execution.
Where this breaks down most often is in shared environments, where multiple teams can touch the key but none can prove they were responsible for its protection at the moment it failed.
Shared ownership, exceptions, and the cases that blur responsibility
Tighter key governance often increases operational overhead, so organisations must balance agility against the need for traceable control. That tradeoff is most visible when keys are used by several application teams, outsourced operations, or recovery functions that need emergency access.
There is genuine consensus that accountability must be explicit, but less consensus on how much operational delegation is acceptable in large mainframe environments. Some organisations centralise the cryptographic function under security operations, while others keep execution in platform teams with security oversight. Either model can work if the responsibility boundaries are written down and the exception path is controlled.
Edge cases deserve special handling. Break-glass access, disaster recovery, and migration activity can legitimately widen the number of people involved, but they should not widen accountability itself. A temporary exception still needs an owner, a reason, a time limit, and a review point. When key material crosses organisational boundaries, the receiving party should be treated as accountable for its safeguarding until control is formally returned or retired. External assurance is also useful only if it checks the actual lifecycle evidence, not just the existence of a written policy.
Practitioner Guidance: Treat key accountability as a control-design problem, not an after-the-fact incident question. If a team cannot show who approves access, who executes lifecycle changes, and who reviews exceptions, the control is not mature enough to trust.
Practitioner takeaway: The safest operating model is the one where the data owner, technical operator, and security approver each have a distinct duty that can be evidenced, because shared access without shared traceability is where key mishandling becomes ungovernable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Key accountability depends on defined ownership and controlled access paths. |
| Recommendation — Enforce named ownership and approve all access paths to cryptographic key material. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Accountability for key mishandling is a governance and oversight issue. |
| PR.AA-01 — Identity Management, Authentication, and Access Control | Exposure and mishandling often stem from weak authorization around key operations. | |
| RC.RP-01 — Recovery Plan Execution | Key backup and recovery are part of the accountable lifecycle, not ad hoc tasks. | |
| Recommendation — Assign explicit risk ownership for cryptographic keys and review it through governance. Restrict key operations to authorized roles and verify access is least privilege. Document and test who can recover keys and under what approved conditions. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Accountability relies on knowing which people are trusted to perform sensitive actions. |
| Recommendation — Require strong identity assurance for staff who can manage or recover keys. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
