Who should own phishing simulation reporting in an identity programme?

Why This Matters for Security Teams

Phishing simulation reporting becomes valuable only when it is treated as identity and risk telemetry, not as a campaign scorecard. Security awareness teams can run tests, but IAM and risk leaders need the results to identify exposed accounts, weak verification paths, and users who are likely to approve fraudulent credential prompts. That is why the reporting model should align with governance outcomes described in the NIST Cybersecurity Framework 2.0, not just training completion metrics. NHI Management Group’s Ultimate Guide to NHIs also shows why this matters: 97% of NHIs carry excessive privileges, so identity exposure is often broader than a single user mailbox or login event. When phishing data stays in a learning silo, it misses the operational question that matters most, which accounts, tokens, or approval paths would turn a click into real access. In practice, many security teams encounter identity abuse only after a campaign has already revealed the weakest link in production workflows, rather than through intentional reporting design.

How It Works in Practice

Effective ownership is usually shared, but not blurred. Awareness teams should own the campaign mechanics, scheduling, user segmentation, and behaviour-change messaging. IAM should own the interpretation layer, which means mapping click rates, credential submission events, MFA fatigue responses, and reporting delays to account protection controls. Risk leadership should own aggregation and escalation, so the data can inform board reporting, policy exceptions, and prioritised remediation. The reporting model works best when it answers operational questions such as:

• Which user actions correlate with higher account takeover risk?
• Which identities need tighter conditional access, step-up authentication, or reset workflow review?
• Which business units need targeted controls rather than more awareness content?

This is also where NHI reporting patterns help. NHI Management Group’s Top 10 NHI Issues highlights how identity telemetry becomes useful only when it supports governance and remediation, not just observation. For human phishing simulations, that same principle applies: report outcomes in a way that triggers IAM review, account hardening, and risk acceptance decisions. Where relevant, teams can also extend the same logic to compromised service accounts and automation identities referenced in the 52 NHI Breaches Analysis. These controls tend to break down in highly decentralised organisations because awareness data, IAM logs, and risk reporting live in separate tools and no one owns the handoff.

Common Variations and Edge Cases

Tighter ownership often improves accountability, but it also increases coordination overhead, requiring organisations to balance speed against governance depth. In smaller teams, security awareness may compile the report, while IAM and risk only review exceptions. In larger enterprises, the better model is a shared operating rhythm with one accountable owner for decisions, not just dashboards. There is no universal standard for this yet, but current guidance suggests that phishing simulation results should not be measured only by click rate or completion rate. They should also reflect whether the organisation can act on the signal. A common edge case is executive or privileged-user testing. Those results should usually bypass generic awareness reporting and go directly into IAM and risk oversight because the exposure is materially different. Another edge case is when simulations target shared mailboxes, delegated inboxes, or accounts tied to automated workflows. In those environments, the question is not only who clicked, but whether the account or process boundary was weak enough to enable lateral movement. NHIMG’s What are Non-Human Identities reference is useful here because it reinforces the broader identity governance lesson: reporting should map to the identity that can actually be abused. A training metric alone is not enough when the real risk sits in account control and privilege design.

Related resources from NHI Mgmt Group

• Who should own human risk management in an identity programme?
• Who should own phishing reporting governance in large organisations?
• Who should own phishing-resistant MFA governance across the identity programme?
• Who should own SaaS reporting outputs in an identity programme?