Who should be accountable for human cyber risk in an organisation?

Why This Matters for Security Teams

Human cyber risk is not a training-only problem. It is a governance problem that shows up wherever people approve access, handle sensitive data, or make exceptions under pressure. If accountability sits only with awareness teams, the organisation often gets better content but not better outcomes. The control owners who define access, process, and response are the ones positioned to reduce exposure, which is why frameworks like the NIST Cybersecurity Framework 2.0 place governance, protection, detection, and response inside a broader risk-management model.

The practical issue is that human error is usually exploited through weak design, not just weak judgement. Phishing-resistant access, privilege boundaries, payment approval steps, and secure escalation paths all shape whether a mistake becomes an incident. That means accountability should follow the business process owner, IAM and PAM owners, and security leaders who can actually change the workflow. When AI-assisted phishing, impersonation, and deepfake-enabled fraud enter the picture, the responsibility becomes even more cross-functional, because human exposure now includes both ordinary social engineering and AI-amplified deception. In practice, many security teams encounter human cyber risk only after a payment diversion, account takeover, or policy exception has already occurred, rather than through intentional governance.

How It Works in Practice

Operational accountability works best when human cyber risk is mapped to specific decisions, not broad awareness slogans. Start by identifying which roles control the points where social engineering can succeed: account recovery, password resets, privileged approvals, vendor payments, data sharing, and exception handling. Those owners should be measured on the controls that reduce exposure, while security sets standards, monitors outcomes, and escalates systemic weakness. NIST control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties accountability to concrete control families rather than abstract responsibility.

• Assign a named risk owner for each high-exposure workflow, not just a department.
• Link access decisions to IAM and PAM controls so approval authority is visible and reviewable.
• Measure whether business controls reduce failure rates, such as risky approvals, reuse of exceptions, or delayed escalation.
• Feed incident lessons into process redesign, not only awareness content.
• Include AI-enabled deception scenarios in exercises, especially where impersonation or tool abuse could change decisions.

This is where security operations, identity teams, and business leadership have to share evidence. SOC and IAM telemetry can show where accounts, approvals, or workflows are being abused, but the business owner must own the change. As adversaries increasingly combine credential theft with AI-driven persuasion, guidance from the CISA cyber threat advisories helps teams translate threat activity into process controls and escalation triggers. These controls tend to break down in decentralised organisations where approval chains are informal because no single owner can change the workflow.

Common Variations and Edge Cases

Tighter accountability often increases reporting overhead and slows decision-making, so organisations have to balance precision against operational friction. The right model depends on whether the risk sits in a stable workflow, a regulated process, or an emerging AI-enabled threat path. Current guidance suggests there is no universal standard for this yet, especially where responsibility spans HR, finance, IT, and product teams.

Some edge cases need special handling. In regulated environments, executives may retain ultimate accountability while delegated owners manage day-to-day controls. In highly automated environments, the accountable party may need to include platform owners because the workflow itself creates the exposure. Where agentic AI or AI-assisted content is part of the attack surface, the accountability model should also consider model governance and tool access, and the MITRE ATLAS adversarial AI threat matrix is a useful reference for mapping those attack paths. If the organisation is using autonomous agents to make or influence decisions, accountability must include who approved the agent’s scope, data access, and escalation logic. The Anthropic first AI-orchestrated cyber espionage campaign report is a reminder that human risk now includes adversaries using AI to improve social engineering at scale.

The rule of thumb is simple: awareness teams can educate, but they should not be left holding accountability for controls they do not own. When ownership is vague, risk shifts into the gaps between departments, and those gaps are where human cyber incidents usually grow.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• How should security teams govern non-human identities at scale?