Who should act on a phishing report first, the SOC or IAM team?

Why This Matters for Security Teams

Phishing reports are often treated as a simple inbox triage problem, but they are usually an identity and detection problem at the same time. The SOC needs to decide quickly whether the message is part of an active campaign, while IAM or PAM needs to assess whether the report implies credential exposure, session theft, or privilege misuse. That split matters because the wrong first responder can delay containment. NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that incident handling, access control, and monitoring are connected controls, not separate silos.

For security teams, the practical question is not who owns phishing in the abstract, but who has the fastest path to validate risk and contain impact. If the report comes from a standard employee mailbox with no sign of account compromise, SOC-led triage is usually enough at first. If the report involves a privileged user, an authentication prompt, or a link that may have been used to capture credentials, IAM or PAM needs to join immediately. The common mistake is assuming that email security alone resolves the incident when the real exposure is account state. In practice, many security teams encounter account misuse only after a user reports a message and the attacker has already moved into the identity layer.

How It Works in Practice

A workable response model starts with SOC intake, because the SOC is usually best placed to validate the message, classify the phishing attempt, and correlate indicators across mail, endpoint, and network telemetry. That first pass should answer whether the report is noise, a broad campaign, or a targeted attempt tied to a known threat pattern. The SOC can then decide whether to escalate into IAM, PAM, or both. This aligns with the incident response and monitoring expectations described in the NIST SP 800-53 Rev 5 Security and Privacy Controls and the broader campaign patterns documented in the ENISA Threat Landscape.

In practical terms, the workflow often looks like this:

• SOC receives the report, preserves the message, and checks for known indicators, sender reputation, and user impact.
• If the report suggests credential capture, the IAM team checks for risky sign-ins, password resets, MFA fatigue signals, and anomalous session activity.
• If a privileged user is involved, PAM verifies whether elevated credentials, vault access, or active sessions need to be revoked or rotated.
• If the phish targeted a sensitive application, the application owner may need to review authorization logs and downstream access paths.
• If the same lure is being used at scale, SOAR can help automate quarantine, ticket routing, and user notification.

Best practice is to treat phishing as a shared incident with a clear first owner and explicit escalation triggers. The SOC owns early triage; IAM owns identity validation and containment; PAM owns privilege exposure and privileged session hygiene. These controls tend to break down when alert routing is based only on the mailbox or only on the account, because the compromise path spans both layers.

Common Variations and Edge Cases

Tighter handoffs often increase coordination overhead, requiring organisations to balance speed against the risk of missing an identity compromise. That tradeoff becomes visible in high-volume phishing environments, where every report cannot trigger a full IAM investigation, but some reports clearly should.

There is no universal standard for this yet, but current guidance suggests using escalation criteria rather than a single fixed owner. A report from a senior executive, finance approver, admin, developer with production access, or any user with access to secrets should move beyond SOC-only triage. The same is true when the phish includes MFA prompts, OAuth consent requests, session hijack signals, or links to credential harvesters. In those cases, the question is not just whether the email is malicious, but whether the identity has already been weakened.

For organisations with mature tooling, the cleanest model is a triage matrix that routes on reporter role, lure type, and evidence of account impact. Where that maturity is missing, the SOC should still remain the first operational touchpoint, but with standing playbooks that bring IAM or PAM in immediately when privilege, authentication, or sensitive data is involved. The exception is a suspected compromise of a non-human identity tied to mail relay, automation, or API access, where identity governance teams may need to treat the phishing report as a broader secrets exposure problem rather than a user-awareness issue.

Related resources from NHI Mgmt Group

• Why do phishing campaigns often become IAM problems after the first click?
• How can SOC teams tell whether a phishing report is low impact or an incident?
• How do teams decide which IAM findings to fix first?
• How do IAM and NHI teams decide where to automate revocation first?