Who should own accountability for phishing resilience across the organisation?

Accountability should sit with security leadership, but effective phishing resilience requires shared ownership across HR, compliance, IT, and business leaders. Security teams define the controls, governance, and response workflow, while managers reinforce participation and reporting culture. The aim is to treat human risk as an enterprise control issue, not a one-off awareness exercise.

Why This Matters for Security Teams

Phishing resilience is not just a training problem. It is an enterprise accountability problem because modern phishing aims at credentials, tokens, MFA approvals, and downstream access, not just inbox awareness. Security leadership should own the control design and measurement, but success depends on HR, compliance, IT, and line-of-business leaders reinforcing reporting culture, policy adherence, and rapid response. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats awareness, access control, and incident handling as coordinated control domains, not isolated tasks.

The practical risk is that organisations often measure phishing only by click rates, which misses credential submission, session hijacking, and business process abuse. That gap is visible in incidents such as CoPhish OAuth Token Theft via Copilot Studio, where the real issue was not a naive click but token theft through an interaction path users did not expect. When accountability is vague, teams respond with awareness campaigns while the attack path continues to mature.

In practice, many security teams discover phishing resilience gaps only after a token, inbox, or approval workflow has already been abused rather than through intentional control testing.

How It Works in Practice

Effective accountability starts with a named executive owner, usually the CISO or another security leader, who is responsible for the program’s control framework, metrics, and escalation path. That owner should define who does what when a phish is reported, who approves simulation content, who tunes technical controls, and who communicates outcomes to business leaders. The aim is shared execution with a single accountable owner.

Security should run the detection, reporting, and response mechanics, while IT handles email filtering, authentication hardening, and mailbox protections. HR supports training completion, onboarding, and disciplinary or coaching workflows where needed. Compliance helps align the program with policy, audit evidence, and recordkeeping. Business leaders reinforce participation so phishing resilience is treated as a normal operational control, not an annual awareness event. Guidance from CISA phishing guidance supports this cross-functional model, particularly where reporting and rapid containment matter.

Measurement should extend beyond click rate to include report rate, time to report, time to contain, repeat offender trends, and the proportion of confirmed phishing events that trigger MFA or credential abuse. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which matters because phishing often becomes far more damaging once attackers pivot from human inboxes to non-human access paths.

• Define one accountable owner for the program and separate that from operational contributors.
• Track reporting behaviour and containment speed, not just training completion.
• Align mailbox, identity, and incident response workflows so reports become action.
• Review exceptions where a phish led to token theft, inbox rules abuse, or privilege escalation.

These controls tend to break down in decentralised organisations with shared inboxes, informal approvals, or outsourced IT because no single team can see the full attack path.

Common Variations and Edge Cases

Tighter phishing governance often increases operational overhead, requiring organisations to balance fast user workflows against stronger verification and escalation discipline. In smaller firms, one leader may own both security and awareness, but the accountability model still needs explicit business participation. In highly regulated sectors, compliance may demand more formal evidence of training, testing, and response, which can make the program feel heavier but also more defensible.

Current guidance suggests that “security owns it” is necessary but not sufficient. If the business treats phishing as a security-only metric, managers stop reinforcing desired behaviour and employees learn that reporting is optional. If HR owns it alone, technical signal and incident containment usually lag. The best practice is evolving toward a shared operating model with clear RACI, executive reporting, and periodic exercises that test both people and process.

Incidents like the Poland Military Breach illustrate why phishing resilience must be evaluated in the broader context of access pathways, not just end-user awareness. The real edge case is environments where a phish compromises a privileged workflow or third-party portal, because ownership becomes ambiguous once the attack crosses team boundaries.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Who should own phishing-resistant MFA governance across the identity programme?
• Who should own HIPAA audit readiness across the organisation?
• Who should own credential theft resilience across identity programmes?