Organisations should make owners and stewards accountable for securing the systems and data they operate, because they are best placed to understand access, misuse, and breach risk. That means assigning clear ownership, giving those teams the right tools, and treating accountability as an operating requirement rather than a compliance slogan. Security failures improve when responsibility is tied to the people who can actually change controls.
Why accountability has to move to system owners and stewards
Accountability works best when it sits with the people who choose the system, configure it, approve access, and can actually change controls. End users can follow rules, but they usually cannot redesign permissions, logging, or recovery. The practical shift is from “users must be careful” to “owners must make the system harder to misuse and easier to govern.”
That change also clarifies who owns secure defaults, exception handling, and remediation. The NHI Ownership and Accountability Guide is useful here because the same ownership logic applies whenever a team operates identities, credentials, or access paths on behalf of the business.
What changes when owners and stewards are responsible
When responsibility is assigned to owners and stewards, security becomes part of operating the service rather than an after-the-fact review of user behaviour. That means defining who approves access, who rotates or revokes credentials, who responds to anomalous use, and who signs off on residual risk. Without that clarity, ownership gaps are often filled by the least-informed team.
This is also where accountability needs to be measurable. A good ownership model leaves an audit trail for decisions, shows who can change controls, and makes it obvious when a system has no accountable steward. The 52 NHI Breaches Report illustrates why weak ownership and delayed action matter: once access paths are left unmanaged, misuse tends to persist until it is discovered through an incident.
Owners do not need to do every security task themselves, but they do need to ensure the work happens. In practice, that usually means backing platform teams, IAM teams, and security teams with authority to enforce standards, rather than treating security as a user-training problem.
How to make the shift stick in operating practice
The strongest model is to tie accountability to the team that can change the control surface. If a system owner can approve entitlements, change authentication settings, and revoke access quickly, then accountability is meaningful. If they cannot, then they are only nominally accountable and the control will drift back to end users or to nobody.
- Assign a named owner for each critical system, dataset, and shared access path.
- Define a steward for day-to-day control health, including reviews, exceptions, and remediation.
- Make access, logging, and credential hygiene part of the service’s operating criteria.
- Escalate orphaned systems, undocumented integrations, and recurring exceptions immediately.
For organisations that want a broader governance model, NIST Cybersecurity Framework 2.0 provides a useful structure for assigning governance, identifying ownership, and tracking whether protective controls are actually operating.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Ownership and stewardship depend on clear organizational roles and operating context. |
| GV.RM-03 — Risk Appetite and Risk Tolerance | Shifting accountability requires owners to manage residual cybersecurity risk. | |
| GV.OV-01 — Policy and Oversight | The question is about who is responsible for enforcing security in operations. | |
| Recommendation — Define accountable owners and stewards for each system and data set. Set ownership responsibilities against the organisation’s risk tolerance. Assign oversight so system owners must evidence control performance. | ||
| NIST SP 800-53 Rev 5 | AC-1 — Access Control Policy and Procedures | Ownership and stewardship need formal access-control accountability and procedures. |
| AC-6 — Least Privilege | Owners, not end users, should control and minimize access permissions. | |
| AU-2 — Event Logging | Stewards must be able to observe misuse and prove control operation. | |
| Recommendation — Document owner responsibilities for approving and reviewing access. Constrain privileges to what system owners can justify and maintain. Require logging that lets stewards detect misuse and investigate change. | ||
| ISO/IEC 27001:2022 | A.5.2 — Information security roles and responsibilities | The subject is specifically about moving security accountability to owners and stewards. |
| A.5.15 — Access control | Owners must govern access decisions rather than rely on user discipline. | |
| A.8.15 — Logging | Accountability needs evidence that owners can see and respond to misuse. | |
| Recommendation — Assign and maintain clear security responsibilities for each system and service. Make owners responsible for approving, reviewing, and removing access. Ensure systems produce logs that support stewardship and review. | ||
| CIS Controls v8 | CIS-5 — Account Management | The question centers on who owns account and access lifecycle responsibility. |
| Recommendation — Make system owners accountable for account creation, review, and removal. | ||
Practitioner Guidance
What to verify: Check whether every production system has one accountable owner and one operational steward, and confirm that both can name the access and recovery controls they are responsible for. If a team cannot change the system, it should not be treated as the control owner.
Common mistake: Shifting responsibility to end users through training or policy language while leaving owners without mandatory control tasks, escalation authority, or deadlines. That creates the appearance of accountability without the ability to reduce risk.
What good looks like: Ownership is visible in inventory, access review, incident response, and remediation workflows, and exceptions are resolved by the team that runs the system rather than pushed onto individual users.
Practitioner takeaway: Accountability becomes real only when it is assigned to the people who can change the system, enforce the control, and absorb the operational consequences of failure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
