Who should be accountable when phishing simulation findings reveal repeated risky behaviour?

Why This Matters for Security Teams

Repeated risky behaviour after phishing simulations is not just a training problem. It is a control failure that can affect account takeover risk, identity assurance, and downstream access decisions. If a user repeatedly clicks, submits credentials, or bypasses verification, the organisation must decide whether the issue belongs in awareness, identity governance, privileged access review, or all three. The important question is not who feels responsible, but which control owner can actually change exposure.

That distinction matters because accountability only becomes useful when it triggers action. In mature programmes, phishing results feed into access recertification, step-up authentication, targeted coaching, and exceptions handling. In weaker programmes, the findings are reported, discussed, and forgotten. NIST’s NIST Cybersecurity Framework 2.0 places clear emphasis on governance, risk management, and protective outcomes, which is the right lens here. In practice, many security teams encounter repeated risky behaviour only after an account compromise or fraud investigation has already exposed the gap, rather than through intentional governance.

How It Works in Practice

The right accountability model usually assigns different responsibilities to different functions. The security awareness team may design and run the simulation, but the identity governance or access management owner must decide what happens when behaviour repeats. That can include additional verification, tighter access review cadence, temporary privilege reduction, or a formal manager-led intervention. If the individual holds elevated access, the privilege owner should be involved as well, because repeated susceptibility is more consequential when the account can reach sensitive systems.

Operationally, the process should connect the simulation platform to an action path, not just a metrics dashboard. A useful workflow often includes:

• classifying the behaviour by severity, such as link click, credential submission, or data entry into a fake portal;
• checking whether the person has privileged, administrative, or high-impact business access;
• deciding whether repeated failures trigger refresher training, manager review, or access reassessment;
• documenting the outcome so the next simulation or audit can confirm that action was taken;
• tracking exceptions where business constraints prevent immediate access changes.

This is where control mapping matters. NIST SP 800-53 Rev. 5 supports the idea that organisations should connect awareness, access control, and continuous monitoring rather than treating them as isolated activities. A phishing simulation is only valuable if the result can influence identity decisions. For identity-heavy environments, the question is not simply whether someone failed a test, but whether that failure should change the risk posture attached to their account. These controls tend to break down when results are siloed inside awareness tooling because the organisation then has no reliable path from finding to enforcement.

Common Variations and Edge Cases

Tighter response rules often increase administrative overhead, requiring organisations to balance user friction against actual risk reduction. That tradeoff becomes more visible in large enterprises, regulated sectors, and roles that legitimately need broad access. Current guidance suggests that repeated risky behaviour should not automatically trigger punitive action every time; instead, best practice is to use proportional response based on role sensitivity, frequency of failure, and whether there is evidence of real compromise.

There is no universal standard for this yet, especially around how many failures justify access changes. Some organisations use a fixed threshold, while others rely on a case-by-case review by security, HR, and the business manager. The best approach is usually to avoid making phishing a standalone discipline. It should feed identity governance, privileged access, and incident readiness. Where personal data is used to score user behaviour, privacy and labour relations concerns also matter, particularly in jurisdictions with stronger employee monitoring rules. Where simulation results are linked to account controls, the process should be transparent, documented, and reviewable.

For environments with contractors, shared workstations, or high-turnover operations, repeated risky behaviour may reflect process design rather than individual negligence. In those cases, organisations should look at whether the verification journey, session timeout settings, or role assignment are part of the problem. The goal is to correct the control gap, not simply to assign blame. Many programmes fail when they treat phishing simulations as a training statistic instead of a governance signal that should reshape access decisions.

Related resources from NHI Mgmt Group

• Who should own the response when simulation reveals risky employee behaviour?
• Who is accountable when CTEM findings do not get fixed?
• When does an NHI become too risky to keep as-is?
• Who is accountable when risky email behaviour persists despite detection tools?