Which accountability model should organisations use for phishing response?

Why This Matters for Security Teams

Phishing response fails when organisations treat it as a single-team incident. The practical risk is not just message removal, but compromised credentials, session theft, mailbox rule abuse, and lateral movement that continue after the email is deleted. A workable accountability model has to reflect that phishing is a cross-functional event with security, identity, and messaging implications. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for coordinated incident handling and access control rather than isolated remediation.

Security teams often miss the handoff problem. SOC may detect and triage the lure, but without IAM action the attacker can keep using stolen sessions or reset paths, and without mailbox administration the malicious content or forwarding rules can remain active. The accountability model matters because it determines who can act, who validates success, and who closes the incident. In practice, many security teams encounter the real blast radius only after the mailbox has been weaponised or the account has already been reused elsewhere, rather than through intentional detection.

How It Works in Practice

The strongest model is shared accountability with clear operational owners. SOC should own detection, triage, and evidence preservation. IAM should own account containment, password resets, token revocation, MFA step-up or re-enrolment, and review of downstream access risk. Mailbox or messaging administration should own quarantine, purge, sender blocking, transport rule review, and mailbox forwarding control. This division keeps the response aligned to the specific failure modes phishing creates.

A practical workflow usually looks like this:

• SOC confirms whether the email is malicious, user-reported, or part of a broader campaign.
• IAM checks whether any credentials, recovery methods, or active sessions were exposed.
• Messaging teams remove the lure, block related indicators, and inspect for mailbox rule tampering.
• Incident management records the owner for each action so containment does not stall at the handoff.

That operating model maps well to the control intent in CISA incident response planning guidance, because phishing response is as much coordination as it is technology. It also helps to align playbooks with MITRE ATT&CK Phishing so the response team understands the attack path, not just the inbox event. Where identity compromise is suspected, the response should extend beyond the email channel into authentication logs, risky sign-in review, and privilege checks. These controls tend to break down when organisations outsource mailbox operations but keep IAM and SOC separate, because no single team owns the full containment sequence.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance speed against clarity. That is especially true in smaller teams, where one analyst may temporarily cover SOC and IAM tasks, or in regulated environments where approvals are required before account disablement. Current guidance suggests this is a governance decision, not a fixed org chart: the right model is the one that preserves fast containment while making ownership explicit.

There is no universal standard for this yet, but the main variants are well understood. Some organisations use a SOC-led model with IAM and messaging as delegated responders. Others assign incident commander status to the SOC while preserving technical ownership in the system domain teams. For high-risk users, such as executives, finance staff, or administrators, additional steps may be needed, including elevated verification before reset and a review of recovery channels. That is where the identity bridge becomes important: phishing is often the entry point for account takeover, so response must include identity assurance, not only malware-style cleanup. NIST CSF-style coordination principles and identity controls should remain aligned with the actual account recovery workflow, especially when mailbox forwarding or token theft is involved.

Best practice is evolving for cloud-first mail platforms and passwordless environments. Organisations should define in advance who can revoke sessions, who can invalidate trusted devices, and who can restore access after validation. If those decisions are left until the incident, the response slows and the attacker’s window stays open.

Related resources from NHI Mgmt Group

• Which accountability model should organisations use when identity compromise drives fraud losses?
• What should organisations control when automating response workflows across security tools?
• How do organisations operationalise NHI ownership at scale?
• How should security teams use IAST and RASP in NHI governance?