Who should own the workflow from phishing detection to simulation?

Ownership should be shared across SOC, security awareness, and governance teams, with clear approval boundaries for reuse and sanitisation. SOC should identify and document the threat, awareness should shape the simulation, and governance should ensure privacy, logging, and policy adherence. No single team should act as the informal bridge.

Why This Matters for Security Teams

Phishing detections are not just alerts to close out in the SOC queue. They often become training material, threat intelligence, evidence for governance, and sometimes material that touches employee privacy or legal review. When ownership is vague, the same sample can be reused without sanitisation, approval, or context, which creates risk around internal exposure, credibility, and policy breaches. The control question is therefore not simply who can see the phish, but who can safely turn it into a simulation.

That handoff should be governed by operating model, not ad hoc urgency. The NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations to define clear roles across identify, protect, detect, respond, and recover rather than treating detection as the end state. In practice, the SOC owns threat validation and evidence handling, awareness owns instructional design, and governance owns policy, privacy, and approval boundaries. In practice, many security teams encounter failures only after a live lure is reused in a campaign without consent, rather than through intentional cross-functional design.

How It Works in Practice

A workable process starts when the SOC confirms the phishing event, captures the artefacts, and records enough context for reuse decisions. Awareness teams then decide whether the message is suitable for simulation, how much to alter it, and which audience should receive it. Governance or security risk functions review whether the content includes personal data, sensitive business context, or wording that could expose the organisation to unnecessary legal or employee-relations issues.

The practical boundary is that each team needs a distinct decision right:

• SOC validates the report, preserves evidence, and flags indicators of compromise or attack pattern details.
• Awareness translates the threat into a learning objective and determines simulation design.
• Governance approves or rejects reuse, sets retention rules, and checks privacy and policy alignment.
• Legal, HR, or compliance may need input when the lure references personnel, payroll, benefits, or disciplinary themes.

This model is easier to operate when the organisation maintains a lightweight intake form and a sanitisation checklist. The checklist should cover sender spoofing details, embedded links, attachments, logos, personal names, and any accidental inclusion of customer or employee data. Where simulation tooling is used, the logging and access controls should map to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around auditability, information disclosure, and access restriction. These controls tend to break down when phishing artefacts are stored in shared mailboxes or chat channels because downstream teams then reuse incomplete context and lose the approval trail.

Common Variations and Edge Cases

Tighter approval gates often increase turnaround time, requiring organisations to balance simulation speed against privacy, legal, and reputational risk. That tradeoff becomes more visible in high-volume environments, where the impulse is to automate the handoff from detection to training. Current guidance suggests automation is acceptable for triage, but not for final reuse decisions when the original email contains employee data, client references, or active fraud indicators.

There is also no universal standard for exactly who “owns” the content once it moves from incident handling into education. Some organisations place awareness in the lead role, with SOC as a contributor; others keep SOC in the lead for evidentiary reasons. The better test is whether the team can prove that the lure was sanitised, the audience was appropriate, and the simulation did not expose the organisation to avoidable risk. Where phishing content is tied to regulated data, privileged accounts, or internal executive themes, additional review may be needed before reuse. That is especially important when the sample could be mistaken for a real incident or trigger unnecessary escalation.

Related resources from NHI Mgmt Group

• Who should own phishing simulation reporting in an identity programme?
• Who should own policy when application email crosses cloud and security teams?
• What breaks when policy, detection, and remediation are split across different tools?
• Who should own enforcement when policies cover both human and non-human identities?