Who should be accountable for preventing social engineering incidents when requests span employees, IT, and finance?

Accountability should be shared, but not blurred. Security teams should own policy, training, and detection, while business process owners should own verification steps for high-risk actions such as payments, access changes, and sensitive disclosures. Finance, IT, and managers must enforce the rules in their workflows so responsibility does not collapse into a single team that lacks operational context.

Why Shared Accountability Matters for Social Engineering

social engineering incidents rarely fail at a single control point. A call, email, chat, or ticket can cross employee judgment, IT access workflows, and finance approval paths before anyone notices the inconsistency. That is why accountability has to be shared across the process, not collapsed into one security team. NHI Management Group’s research on identity compromise shows how quickly attackers exploit weak handoffs, including cases documented in the MGM Resorts Breach 2023 — Scattered Spider and the Storm-2949 Azure Breach. The pattern is consistent: attackers do not need every person to be fooled, only one workflow step to be trusted without verification.

That is why security should set the standard, but business owners must own the controls inside their own processes. Finance should verify payment changes, IT should validate access changes, and managers should confirm unusual requests that affect people, payroll, or sensitive disclosures. Current guidance suggests that responsibility works best when each team owns the checks it can actually perform, rather than treating awareness training as a substitute for operational control. In practice, many organisations discover the gap only after a fraudulent request has already moved through approvals that looked legitimate on paper.

How Accountability Should Work Across Employees, IT, and Finance

The practical model is simple: security defines the policy, but the business process owner executes the verification. That means accountabilities are separated by function, with escalation paths that are clear before an incident occurs. Security cannot be the final approver for every payment or access change because it lacks transaction context. Finance and IT cannot improvise their own exceptions because they need a common rule set to avoid inconsistent decisions.

• Security owns the policy baseline, monitoring, alerting, and incident response.
• Finance owns verification for invoice changes, bank detail updates, and urgent payment requests.
• IT owns verification for privileged access, account recovery, and device or identity resets.
• Managers own confirmation for sensitive HR, payroll, and disclosure requests involving their staff.
• All teams must document what counts as high risk, who approves it, and what evidence is required.

This aligns with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects process owners to implement access and verification controls, not just policy statements. It also matches the identity-first logic in NIST SP 800-63 Digital Identity Guidelines, where proofing and authentication strength should reflect the risk of the transaction. For broader context on attacker behaviour, the The 2024 ESG Report: Managing Non-Human Identities highlights how often identity weaknesses translate into real compromise, especially when controls are fragmented across teams.

In practice, mature organisations use call-backs, dual approval, out-of-band confirmation, and step-up verification for high-risk actions. They also test the workflow itself, not just the employee. These controls tend to break down when remote work, outsourced finance operations, or help desk pressure to “resolve quickly” overrides the documented approval path.

Where the Model Breaks Down and What to Tighten First

Tighter verification often increases friction, so organisations have to balance speed against misuse resistance. That tradeoff is real, especially for high-volume teams that process many legitimate requests each day. Best practice is evolving, and there is no universal standard for exactly which requests must use two-person approval versus step-up confirmation. The right answer depends on transaction value, blast radius, and how easily an attacker could impersonate the requester.

Two common edge cases deserve attention. First, when a request spans multiple teams, each team may assume another one is checking it, which creates diffusion of responsibility. Second, when the request comes from a senior executive or trusted manager, staff may skip verification because they believe the request is too important to challenge. That is exactly where social engineering succeeds. Current guidance suggests using the same verification standard for all high-risk actions, with limited exceptions that are explicitly approved and logged.

For organisations seeing repeated impersonation attempts, it helps to review attacker tradecraft in sources such as the 52 NHI Breaches Analysis alongside external threat reporting like the ENISA Threat Landscape. Those references reinforce the same operational lesson: the control fails when a single “trusted” channel is allowed to bypass the process. In real environments, social engineering incidents are usually uncovered after finance has moved money or IT has reset access, not when the request is first received.

Related resources from NHI Mgmt Group

• Who is accountable for preventing social engineering that leads users to run attacker-supplied scripts during meetings or interviews?
• What breaks when help desk processes rely on MFA alone against social engineering attacks?
• Who should be accountable when access decisions in Django span both application code and an external policy layer?
• What are the signs that social engineering controls are failing?