Assign ownership across IAM, fraud, HR, and service desk functions, because the risk crosses traditional team boundaries. The practical test is whether a workflow can verify identity independently of the conversation itself. If it cannot, the process is still vulnerable to synthetic impersonation.
How people-facing workflows become governable
People-facing workflows fail when organisations treat them as a single team problem instead of an end-to-end control problem. The practical question is not whether a caller, email, or video looks convincing, but whether the workflow can verify who is asking through an independent channel or trusted control. If it cannot, the workflow still depends on the conversation itself, which is exactly what deepfake abuse targets.
That is why governance starts with workflow boundaries, not just awareness training. The same impersonation pattern may touch identity operations, fraud review, HR case handling, payroll changes, and service desk escalations, so the control owner must be able to see where identity evidence is collected, where it is trusted, and where it is overridden. In Deepfakes, Social Engineering and AI Impersonation Guide, the core theme is that out-of-band verification and identity-based checks matter more than confidence in the live interaction itself.
Governance also needs to separate process legitimacy from request legitimacy. A workflow can be operationally valid and still be unsafe if it allows high-impact actions, such as payment changes, account recovery, or employment updates, to proceed without a second channel of verification. The control objective is to make synthetic persuasion insufficient on its own.
What ownership should cover across IAM, fraud, HR, and service desk teams
The right ownership model is shared, but not vague. IAM should own authentication and recovery standards, fraud should own transaction and impersonation detection, HR should own employee-related verification and case handling, and the service desk should own step-up checks and exception handling. One function may coordinate the policy, but every team needs defined decision rights for its part of the workflow.
That ownership split matters because deepfake risk often enters through the seams. A help desk may reset access after a persuasive call, HR may approve a sensitive change after a spoofed email, and a fraud team may be brought in too late if escalation criteria are unclear. The deeper lesson from the Arup deepfake fraud 2024 case is that a convincing live interaction can still drive a real-world loss when process ownership is fragmented and no one is accountable for independent verification.
Ownership should therefore include escalation thresholds, not just approval boxes. If a request involves credentials, money movement, sensitive employee data, or privileged access, the receiving team should know exactly when to pause, verify, and hand off rather than complete the task under pressure.
How to design controls that survive synthetic impersonation
Controls should be designed around what the attacker can imitate, not around how convincing the interaction feels. Good governance uses independent verification methods such as callback procedures, approved channel switching, known-contact validation, and documented recovery steps that do not rely on the same voice, image, or message thread that initiated the request. Where the workflow cannot verify identity outside the conversation, the process should be treated as high risk by default.
It also helps to classify workflows by impact. A low-risk scheduling change does not need the same rigor as a password reset, beneficiary update, or executive payment approval. The more an action can change access, money, or sensitive records, the more the control design should require a separate trust anchor such as prior enrollment, known device trust, or an already-established identity record.
Implementation should make exceptions visible. Temporary bypasses, urgent approvals, and “trusted caller” shortcuts need logging and review, because those are the exact points where synthetic impersonation gains leverage. Where a workflow cannot be hardened quickly, the safer decision is to reduce the blast radius until the process can be reworked.
Risk and Threat Considerations
Deepfake risk is not limited to fraud loss. It can also create access compromise, payroll manipulation, employee data exposure, and false authority in moments when staff are trained to be helpful and responsive. The threat is strongest where a process rewards speed, treats voice or video as proof, or lets one person complete a high-impact action without a second control.
Failure mechanism: Attackers exploit the gap between perceived legitimacy and independently verified identity, then use that gap to trigger credential recovery, financial transfers, or sensitive case actions through trusted internal workflows.
Impact: The result can be unauthorized access, fraudulent payment, data disclosure, or a wider breakdown in confidence that forces organisations to slow down legitimate service operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | People-facing workflows need independent identity verification before sensitive action. |
| IA-5 — Authenticator Management | Deepfake abuse often targets recovery paths that expose credentials or reset access. | |
| Recommendation — Require step-up authentication before approving high-impact workflow actions. Tighten credential recovery and rotate exposed authenticators after suspected impersonation. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question is about governing access decisions across multiple business workflows. |
| Recommendation — Align workflow approvals to verified identity and least-privilege access decisions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Synthetic impersonation commonly exploits account recovery and privileged account handling. |
| Recommendation — Harden account recovery, privilege changes, and exception handling for impersonation-resistant operations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Workflow governance depends on controlling who may approve sensitive actions. |
| Recommendation — Define access and approval rules for sensitive people-facing workflow actions. | ||
Practitioner Guidance
What to prioritise: Start with the workflows that can move money, reset access, or change employee records, because those are the highest-value deepfake targets and the easiest places for a convincing request to become a damaging action.
What to verify: Confirm that every critical workflow has at least one verification step that is independent of the incoming call, email, or chat. If the only proof is the interaction itself, the process is not yet governable against synthetic impersonation.
Practitioner takeaway: The governance test is simple: if a deepfake can persuade the process without another trust anchor, the process still belongs in the highest-priority remediation queue.
Related resources from NHI Mgmt Group
- How should organisations govern LLM use to reduce data leakage risk across engineering, product, and employee workflows?
- How should organisations govern AI brand safety across customer-facing and internal workflows?
- When should organisations treat an NHI as a high-priority risk?
- How should organisations govern identity risk across human, NHI, and automated access?