Who should own social engineering defence across the organisation?

Why This Matters for Security Teams

social engineering is not a single-control problem, and it is not solved by awareness training alone. Attackers exploit the seams between IAM, help desk, finance, fraud, and security operations, then push for the one action that matters most: a reset, an approval, a payment, or a privilege change. That is why ownership has to be shared and operationalised, not merely assigned. The identity layer is especially important, because verification failures often begin where people assume a request is legitimate and stop checking context. Guidance in NIST SP 800-63 Digital Identity Guidelines supports stronger identity proofing and authentication, but organisational ownership still has to span the full workflow. NHIMG’s Ultimate Guide to NHIs also shows why boundary failures are costly: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams encounter social engineering failure only after a help desk reset, fraudulent payment, or privilege escalation has already occurred, rather than through intentional verification design.

How It Works in Practice

Shared ownership works best when each function owns its own decision point and escalation path. IAM defines authentication and recovery standards, security awareness teaches staff what suspicious requests look like, fraud prevention monitors payment and transfer anomalies, finance enforces approval controls, and help desk teams apply identity verification before any reset or exception. The key is that no single group “owns” social engineering end to end; instead, each team owns the control that can stop abuse at its stage. A practical operating model usually includes:

• Verified call-back or out-of-band approval for resets, bank changes, and privileged requests.
• Step-up verification for high-risk actions, especially when a request is urgent, unusual, or comes from an outside channel.
• Clear denial criteria, so staff know when not to proceed even if the requester sounds authoritative.
• Escalation playbooks that route suspicious requests to fraud, IAM, or security operations without delay.
• Audit logging for identity proofing, approvals, and exception handling to support review and dispute resolution.

This matters because social engineering often piggybacks on weak identity workflows. NIST’s guidance on digital identity supports stronger proofing and authentication, while NHIMG’s Ultimate Guide to NHIs highlights how poor control hygiene can leave 91.6% of secrets valid five days after notification, showing how slow remediation amplifies attack impact. These controls tend to break down when help desk teams are optimised for speed over verification, because exceptions become the easiest path for the attacker.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations have to balance fraud resistance against user experience and business urgency. That tradeoff becomes most visible in executive support, payroll changes, customer refunds, and incident response, where staff may be pressured to “just make this one exception.” Current guidance suggests tiering controls by risk rather than applying the same verification step everywhere. Low-risk requests may only need standard checks, while high-risk requests should trigger stronger proofing, dual approval, or out-of-band confirmation. There is no universal standard for this yet, but best practice is evolving toward shared playbooks and named control owners. That means awareness teams should not be expected to investigate payment fraud, and finance should not be expected to redesign identity recovery flows. Each function needs a clear RACI-style responsibility, with security owning policy, operations owning execution, and business leaders owning enforcement within their domain. Edge cases also matter in outsourced environments and shared service centres, where third parties may handle resets or payment approvals. In those settings, ownership should be contractually explicit and backed by logging, sampling, and periodic testing. Without that clarity, social engineering controls can fail at the exact handoff where attackers are most likely to intervene.

Related resources from NHI Mgmt Group

• Who should own BEC controls in an organisation?
• Who should own BEC risk across IAM and finance?
• How can organisations measure whether their social engineering controls are working?
• Who should own business email compromise defence in the enterprise?