Organizations should design verification processes around the business actions that an impersonation attack could compromise. Effective verification requires clearly defined triggers, independent evidence, appropriate authorization, practical escalation paths, and a way to confirm that the control actually happened. The process should work even when the person making the request appears legitimate, the communication comes from a familiar account, or the employee has no particular reason to suspect fraud.
That last requirement is becoming increasingly important. Attackers can now produce remarkably convincing messages, voices, identities, and supporting documentation, while compromised accounts and legitimate business context can make fraudulent requests appear entirely routine. As we explored in What Microsoft’s Billion-Message Cybercrime Takedown Reveals About Human Risk, the economics of impersonation are changing, and organizations need controls that remain reliable when the deception itself is difficult to recognize.
There is a practical complication, of course. Every business already has an impressive collection of processes, policies, approvals, exceptions, and people who know how things really get done. Adding another verification requirement sounds simple until somebody has to complete a supplier payment at 4:45 on a Friday, the usual approver is on vacation, and the vendor is threatening to suspend service. That is where good security intentions encounter the operating reality of the business.
The challenge is to design verification that employees can execute reliably under those conditions.
What is a verification process in cybersecurity?
A verification process is a defined sequence of checks used to establish whether an identity, request, instruction, or transaction is legitimate and authorized before a consequential action takes place. In cybersecurity and fraud prevention, verification processes help protect activities such as payments, supplier changes, account recovery, privileged access, sensitive information disclosure, and exceptions to established procedures.
A well-designed process specifies when verification is required, what evidence is acceptable, which channels can be trusted, who is authorized to approve the action, and what happens when verification cannot be completed. It also establishes responsibility for maintaining the process and reviewing its effectiveness.
Consider an employee receiving a request to change a supplier's bank account. The organization might require the employee to contact the supplier using an independently maintained telephone number, confirm the change with an authorized representative, record the verification, and obtain secondary approval before updating the payment record. The employee is following a control designed to prevent a specific type of fraud, regardless of whether the original email looked suspicious.
This is the operational counterpart to verification behavior in cybersecurity. The behavior describes what the person does; the process establishes the conditions, resources, rules, and evidence that make the behavior reliable.
Which business activities should require independent verification?
Organizations should prioritize verification for activities where a fraudulent request could cause material financial loss, unauthorized access, data exposure, operational disruption, or other significant harm. The threshold should reflect the potential consequence of the action, the organization's risk appetite, and the controls already in place.
Common examples include changes to payment destinations, release of high-value funds, modifications to payroll information, credential resets, privileged access grants, sensitive data transfers, and requests to bypass established controls. Other activities may require verification because of regulatory obligations, contractual requirements, or the sensitivity of the systems and information involved.
The difficulty is that risk does not always align neatly with job titles or transaction values. A relatively small supplier payment may establish fraudulent bank details that will be reused for much larger payments. A routine help-desk request may provide the first step toward privileged access. A seemingly harmless request for information may help an attacker construct a more convincing impersonation later.
That is why Cybermaniacs approaches these questions through the context of the business process. The relevant considerations include who performs the activity, what authority they hold, which systems and information they use, what the action enables, and what could happen if the request were fraudulent.
How do you identify verification points in a business workflow?
Start by mapping the moments where someone accepts a claim and uses it to authorize or perform an action. These are the points where identity, authority, or the legitimacy of a request may need to be established before the process continues.
A useful workflow review examines the request's origin, the person or system receiving it, the evidence used to establish legitimacy, the approvals required, and the action ultimately taken. It should also account for exceptions, alternate routes, after-hours activity, and situations where an employee can override the normal sequence.
For example, a supplier onboarding workflow may include verification when a supplier is first established, when bank details change, when ownership or contact information changes, and when a payment is released following an unusual modification. The same business process can contain several distinct verification points because the risks and consequences differ at each stage.
Security, finance, procurement, IT, HR, and other process owners should participate in identifying these points. The people who operate the workflow usually know where the shortcuts, delays, workarounds, and undocumented exceptions live.
What makes a verification method genuinely independent?
A verification method is independent when the evidence used to establish legitimacy is sufficiently separate from the communication or system that may be compromised. The organization should be able to explain why the method provides additional assurance rather than merely repeating the original claim through another attacker-controlled route.
Suppose an accounts-payable employee receives an email requesting a change in banking details. Replying to the email is weak verification because the mailbox may be compromised. Calling the telephone number included in that same message may be equally weak because the attacker may control the number. A call to a previously established supplier contact, retrieved from a trusted vendor record, provides a more independent source of evidence.
The same logic applies to executive requests and account recovery. A voice that sounds familiar is not sufficient evidence of identity when voice cloning is possible. A video call may provide useful context, but its assurance depends on how the participants were authenticated, whether the communication path can be trusted, and what additional controls apply to the requested action.
Independence is therefore a property of the verification design, not simply the number of communication channels used.
Does a second channel always make verification secure?
No. A second channel can improve assurance, but only when it provides evidence the attacker cannot readily control or reproduce.
An employee who receives a suspicious email and then calls a telephone number supplied in that email has changed channels without establishing meaningful independence. Likewise, an attacker who controls both an employee's mailbox and an associated messaging account may be able to respond through either system.
Organizations should document which sources of contact information, identity evidence, and authentication are trusted for each high-risk workflow. They should also define how those sources are created, maintained, updated, and protected against unauthorized modification.
The design should assume that attackers will look for ways to compromise the verification path itself. If a supplier can change both its bank details and its verification telephone number through the same unverified request, the process has a fairly obvious problem.
How should verification processes establish identity, legitimacy, and authority?
A reliable verification process should distinguish among three questions: whether the requester is who they claim to be, whether the specific request is legitimate, and whether the requester has authority to authorize the action.
These questions are often treated as interchangeable, but they address different failure conditions. An authentic employee may request something outside their authority. A genuine supplier representative may be persuaded by an attacker to submit fraudulent information. A legitimate account may be compromised and used to issue an unauthorized instruction.
For a financial transaction, identity verification might establish that the person is an authorized supplier contact. Request verification might establish that the banking change is genuine and matches the supplier's intentions. Authorization verification might establish that the change has been approved by the appropriate parties and that the employee processing it has the required authority.
For digital identity and account recovery, NIST SP 800-63-4 Digital Identity Guidelines provide a technical foundation for identity proofing, authentication, and related assurance requirements. Organizations still need to translate those principles into their own workforce workflows, including how support staff handle exceptions and how sensitive account changes are approved.
The control should make clear which question each verification step answers. Otherwise, an employee may complete several checks and still fail to establish the thing that matters.
How do you design a verification process that employees will actually follow?
A verification process needs to fit the work it protects. Employees should understand the trigger, have access to an approved method, know what evidence is sufficient, and be able to complete the steps without unnecessary ambiguity.
That sounds elementary until you look at how many security policies rely on phrases such as "confirm the request," "exercise caution," or "verify through an appropriate channel." Those instructions leave important decisions to the employee at the moment of greatest uncertainty. They also make the control difficult to test because the organization has never clearly established what successful execution looks like.
A more useful process identifies the required action in operational terms. For a supplier banking change, it might specify which vendor record contains the approved contact, how the callback is initiated, what information must be confirmed, how evidence is documented, and who can approve the update.
Good design also considers the employee's working environment. A factory supervisor, remote service technician, finance analyst, and executive assistant may have very different access to systems, colleagues, communication channels, and time. A process that works beautifully in a corporate office may become an elaborate obstacle course somewhere else in the organization.
How much friction is appropriate?
The amount of verification should be proportionate to the risk of the action. High-impact transactions and privileged access changes may justify multiple independent controls, while lower-risk activities may require lighter checks or automated assurance.
Excessive friction creates its own problems. Employees begin searching for shortcuts, approvals become ceremonial, and teams invent informal procedures to keep the business moving. Over time, the documented process and the actual process can become two entirely different things.
This is where human factors matter. Organizations should test whether employees can complete verification efficiently, whether the approved channels are available when needed, and whether the control creates predictable bottlenecks. The objective is reliable execution across normal operations and foreseeable exceptions.
A process that nobody can complete during an urgent incident may look impressive in an audit and be considerably less impressive in an actual incident.
What should happen when verification cannot be completed?
Every high-risk verification process needs a defined failure path. Employees should know whether the action must be delayed, rejected, escalated, or handled through an approved exception procedure when the required evidence cannot be obtained.
This matters because attackers frequently manufacture urgency. A supplier threatens to suspend service, an executive claims to be boarding a flight, or a caller insists that a locked account is preventing a critical operation. The employee may understand that verification is required but feel responsible for resolving the business problem immediately.
Without an established escalation path, that pressure becomes an invitation to improvise.
The process should identify who can authorize an exception, what additional safeguards apply, how the decision is documented, and whether certain actions are prohibited until verification succeeds. For particularly sensitive transactions, the appropriate response may simply be to wait.
Exceptions also need oversight. If a particular workflow generates frequent emergency overrides, the organization should investigate whether the process is poorly designed, whether business requirements have changed, or whether teams are developing a routine habit of bypassing the control.
An exception process that becomes the normal process deserves a closer look.
Who should own verification controls across the organization?
Verification controls usually require shared ownership because the risk spans business operations, technology, fraud prevention, security, and workforce behavior.
A finance leader may own the payment process and its authorization rules. Procurement may own supplier records and onboarding procedures. IT may own identity systems and account recovery. Security may define threat scenarios, advise on control design, and test resistance to impersonation. Risk and compliance teams may provide assurance and oversight.
The important governance decision is to establish clear accountability for each control. Someone needs to maintain the procedure, ensure that trusted verification information remains accurate, review exceptions, and respond when testing or incidents reveal weaknesses.
Human Risk Management contributes a different but complementary capability. It helps the organization understand whether people know the procedure, whether they can perform it, whether cultural conditions discourage its use, and whether the surrounding environment supports the expected behavior.
That distinction is useful because a process owner can have a technically sound procedure while the workforce consistently struggles to execute it. The solution may involve redesign, training, leadership intervention, or a combination of all three.
How should organizations test verification processes against impersonation fraud?
Testing should examine the control under realistic conditions, including credible requests, apparent authority, urgency, incomplete information, and operational pressure.
A conventional phishing simulation may tell you whether someone clicked a link or reported a message. It may reveal relatively little about whether the organization can prevent a fraudulent supplier change or unauthorized credential reset. Those outcomes depend on a chain of decisions, systems, approvals, and human behaviors.
A useful test begins with a specific business scenario and follows the workflow to the consequential action. For example, a controlled supplier-change exercise might examine whether the request reaches the correct team, whether independent verification is initiated, whether trusted records are used, whether authorization is confirmed, and whether the change is blocked when required evidence is missing.
Tests should be coordinated with process owners and designed to avoid real financial transfers, unauthorized access changes, or unnecessary disruption. The goal is to evaluate the control safely, identify weaknesses, and improve the workflow.
The resulting evidence should show where the process held, where it failed, and why. That is considerably more actionable than announcing that a particular percentage of employees "fell for" an impersonation attempt.
How do you measure whether verification controls are effective?
Verification control effectiveness should be measured using evidence about both process execution and the conditions that influence it.
Useful operational measures may include the proportion of applicable transactions that received required verification, the quality and independence of the verification evidence, unauthorized exceptions, approval bypasses, time required to complete the process, and failures identified through testing or incident reviews. Those measures should be interpreted alongside transaction volume, risk severity, and the reliability of the underlying data.
Human measures add another layer. Employees may understand the verification requirements but struggle to execute them under pressure. They may use the correct method in a simulation but bypass it when a senior leader demands immediate action. They may know the escalation path but believe using it will create professional consequences.
These differences matter because the same visible failure can have several causes. We examine that problem in What Is Verification Behavior in Cybersecurity, and How Do You Measure It?, including how recognition, execution, escalation, and organizational conditions can be assessed separately.
Cybermaniacs has also written extensively about the risks of treating a convenient metric as a complete explanation. In The Best Human Risk Measurement Tool Is Useless If the Measurement Model Is Wrong, we explore why the interpretation behind a measure matters as much as the data itself.
A verification completion rate can tell you whether a recorded step occurred. It may not tell you whether the step provided meaningful assurance. The measurement model needs to preserve that distinction.
How do organizational culture and leadership affect verification processes?
Verification controls depend on employees being willing to question requests that may come from people with more authority, greater urgency, or stronger commercial influence.
A finance employee may be reluctant to challenge the CFO. A help-desk analyst may feel uncomfortable asking a senior executive to complete additional identity checks. A customer-service representative may face pressure to resolve an angry customer's problem without following the normal procedure.
These are predictable features of organizational life. A control that requires employees to challenge authority must be supported by leadership behavior, escalation norms, and a credible expectation that following the procedure will be respected.
A particularly useful test is to ask whether employees believe the rule still applies when the request appears to come from the CEO. If the practical answer is no, the organization has an authority exception whether or not one appears in the policy.
Our broader work on trust and human cyber risk explores why what people believe about authority, legitimacy, and organizational expectations can shape their security decisions. Verification controls are one place where those beliefs become directly observable.
How does AI change verification process design?
AI-enabled impersonation increases the importance of verification methods that do not depend primarily on the apparent authenticity of a message, voice, image, or video.
Attackers may use AI to generate convincing communications, imitate familiar voices, construct supporting documentation, or personalize requests using contextual information. The same business process may also involve compromised accounts or legitimate identities being misused, so organizations should avoid designing controls around any single deception technique.
This has implications for workflows involving AI systems and agents as well. As organizations delegate more work to automated systems, they need clear rules about which actions can be executed autonomously, which require human authorization, how requests are authenticated, and how approvals are recorded. A human approval step is only useful when the person has enough context, authority, and time to exercise meaningful judgment.
In our article How Do You Measure Human Risk in AI-Driven Work?, we explore the challenges of understanding human decisions, trust, oversight, and accountability as AI becomes part of everyday workflows. <Cite ref="turn856715search4"/>
For verification process design, the underlying requirement remains consistent: important actions need an appropriate basis for trust and authorization, regardless of whether the request comes from a person, an account, an application, or an AI-enabled workflow.
Where should an organization start improving verification controls?
A practical starting point is to select two or three high-risk workflows where impersonation could cause significant harm. Supplier banking changes, help-desk account recovery, and executive payment approvals are often useful candidates because they combine recognizable fraud scenarios with identifiable process owners.
Document how the workflow currently operates, including exceptions and informal practices. Identify the moments where identity, legitimacy, or authority must be established, then assess whether the existing verification methods provide sufficiently independent evidence. Review how employees perform the process, whether the required channels are available, and what happens when verification fails.
From there, establish a clearer procedure, test it under realistic conditions, and measure whether execution improves. Findings should be used to determine whether the next intervention belongs in technology, policy, process design, learning, leadership, or organizational culture.
This is the kind of work where Human Risk Management becomes operationally valuable. Through Human Risk Assessments and Baselines, Cybermaniacs helps organizations understand the competencies, behaviors, cultural conditions, and organizational factors that influence how controls are performed. That evidence can support more targeted interventions and a more credible view of whether human risk is actually changing.
Our approach recognizes that organizations already have substantial investments in security technology, governance, and business processes. The opportunity is to understand how those controls interact with the people expected to use them and where the gaps create avoidable exposure.
Verification should be designed to work when the request looks legitimate
The real test of a verification process is what happens when nobody has spotted anything suspicious.
A convincing request reaches the right person. It fits the business context. The apparent sender has authority. The action is urgent enough to create pressure but ordinary enough to seem plausible.
If the organization has designed the process well, the employee does not have to win a contest against the attacker's ability to manufacture credibility. The workflow already establishes what evidence is required, who can authorize the action, and what happens when that evidence is missing.
That is the standard worth designing for. It gives employees a reliable way to do the right thing and gives security and risk leaders a control they can actually evaluate.
Frequently asked questions
What are the essential elements of a verification process?
A verification process should include a defined risk trigger, an approved source of independent evidence, clear identity and authorization requirements, an accountable process owner, an escalation path, and appropriate records of the decision. These elements allow employees to complete verification consistently and give the organization evidence for testing and assurance.
How can organizations prevent employees from bypassing verification procedures?
Organizations should make verification practical, establish clear rules for exceptions, reinforce leadership support, and monitor whether required steps are completed. Repeated bypasses should be investigated for process friction, unclear authority, inadequate tools, workload pressure, or cultural conditions that discourage employees from following the control.
Is callback verification enough to prevent impersonation fraud?
Callback verification can be valuable when the contact information comes from an independently maintained, trusted source and the person contacted is authorized to confirm the request. It may be insufficient for particularly sensitive actions or where trusted records can be compromised. Organizations should apply additional controls according to the risk and consequences of the transaction.
How should verification controls be tested?
Organizations should test verification through controlled scenarios based on actual business workflows. Testing should examine whether employees recognize the verification requirement, use sufficiently independent evidence, confirm authorization, follow approval procedures, and escalate when the request cannot be validated. Results should also identify process and organizational conditions that affect performance.
How does verification process design relate to Human Risk Management?
Verification process design establishes the controls employees are expected to perform. Human Risk Management helps determine whether employees understand those controls, whether they execute them, what conditions interfere with performance, and which interventions can improve the result. Together, they provide a stronger basis for preventing impersonation fraud and assessing control effectiveness.
