The PAUSE framework can be turned from an awareness slogan into an operational verification-by-design system: employees are given a repeatable process for deciding whether a communication, request, identity or transaction can be trusted.
The PAUSE Framework: From Awareness to Operating Procedure
P — Pause → A — Authenticate → U — Understand → S — Source-check → E — Execute safely
The key principle is:
The higher the potential consequence of a mistake, the stronger the verification required before action.
1. P — PAUSE: Interrupt the pressure to act
The first step is deliberately creating a moment between receiving a request and acting on it.
AI-enabled attacks often exploit urgency, authority and familiarity. A cloned executive voice saying “I need this payment completed in the next ten minutes” is designed to prevent rational verification.
How to implement it
Create organizational rules that automatically trigger a pause when a request involves:
- money transfers;
- changes to bank details;
- privileged-access requests;
- sensitive information;
- password/MFA changes;
- confidential documents;
- unusual downloads;
- executive instructions;
- urgent exceptions to established procedures.
Employees should have a simple rule:
Urgency is a reason to verify—not a reason to bypass verification.
Practical example
A finance employee receives:
“Hi, I’m travelling and need you to urgently transfer ₹48 lakh to this new account. Please don’t delay.”
Instead of immediately processing it, the employee activates the organization’s PAUSE protocol.
The employee does not reply to the message asking, “Is this really you?”
That is important because the attacker may control the communication channel.
The employee moves to the next step: independent authentication.
2. A — AUTHENTICATE: Verify the person, not merely the message
The second step asks:
“How do we know that the person making this request is actually who they claim to be?”
This distinction becomes critical with generative AI.
Email addresses can be spoofed.
Profiles can be fabricated.
Voices can be cloned.
Images can be generated.
Video can be manipulated.
Therefore, authentication should use independent signals.
Build an authentication hierarchy
Organizations can establish different requirements according to risk.
| Risk | Example | Verification |
|---|---|---|
| Low | Routine internal request | Normal identity controls |
| Medium | Access or sensitive information | MFA + identity/context check |
| High | Financial transaction | Independent confirmation + dual authorization |
| Critical | Major payment/access/security change | Multiple independent controls + human approval |
Practical example: CEO voice clone
An employee receives a phone call that sounds exactly like the CEO:
“I’m approving this acquisition payment. Please process it now.”
Instead of trusting the voice, the employee calls the CEO using the pre-existing corporate contact number, not a number supplied during the call.
The CEO confirms that no such request was made.
The attack stops.
Important organizational principle
Don’t teach employees:
“Look for signs that the voice is fake.”
Teach them:
“A convincing voice is not sufficient authentication for a high-risk transaction.”
That remains effective even as synthetic media becomes increasingly convincing.
3. U — UNDERSTAND: Determine what is actually being requested
Authentication alone isn’t enough.
A legitimate employee can make a legitimate request that is still unsafe because the request itself is unusual, excessive or inconsistent with policy.
The third step therefore asks:
What exactly am I being asked to do, and what happens if I do it?
Employees should identify:
- Who is requesting the action?
- What action is being requested?
- Why is it supposedly necessary?
- What information or assets are involved?
- What changes if the request is completed?
- Does it fit the normal business process?
Practical example: vendor bank-account change
A procurement employee receives:
“Our banking details have changed. Please use the attached account for all future payments.”
Even if the email is genuinely from the vendor, the employee should recognize that changing payment instructions has significant financial consequences.
The PAUSE process therefore classifies the request as high risk.
The employee checks:
- Is there an approved vendor-change procedure?
- Was the request submitted through the approved system?
- Is the change supported by the appropriate documentation?
- Does finance require independent confirmation?
The request cannot simply be accepted because the email appears authentic.
4. S — SOURCE-CHECK: Verify through an independent trusted source
This is arguably the most important step in the framework.
The question becomes:
“Can I independently confirm this information without relying on the potentially compromised communication?”
The word independently matters.
If someone sends an email containing a phone number and you call that number to confirm the email, you haven’t necessarily established independence.
Establish trusted verification channels
Organizations should maintain predetermined channels such as:
- corporate directory numbers;
- known executive assistants;
- approved vendor contacts;
- internal ticketing systems;
- authenticated collaboration platforms;
- established procurement portals;
- known banking contacts;
- official customer-service channels.
Practical example
A CFO supposedly sends an urgent WhatsApp message:
“Please send the acquisition documents to this personal email address.”
The employee doesn’t respond through WhatsApp.
Instead, they:
WhatsApp → stop
Corporate directory → locate CFO’s official contact
Corporate phone → independently confirm
The CFO says:
“I didn’t send that request.”
The organization has identified an impersonation attempt.
5. E — EXECUTE SAFELY: Complete the action using controlled processes
Verification shouldn’t end with:
“Yes, it really is the CEO.”
The final question is:
“How do we safely execute the requested action?”
Even legitimate requests need appropriate controls.
This is where cybersecurity, finance, HR and operational controls converge.
Examples
For a payment:
Verified identity → approved workflow → dual authorization → transaction monitoring
For privileged access:
Verified request → documented business justification → time-limited access → logging
For sensitive information:
Verified recipient → approved channel → minimum necessary disclosure → audit trail
For a software deployment:
Verified change request → code review → testing → controlled deployment → monitoring
Putting PAUSE Into a Real Transaction
Consider this scenario:
Scenario
An attacker uses AI-generated audio to impersonate the CEO and requests a ₹2 crore transfer.
Without PAUSE
Voice call → employee believes CEO → payment processed
With PAUSE
P — Pause
Employee recognizes an unusual high-value request.
↓
A — Authenticate
Employee independently contacts the CEO.
↓
U — Understand
Employee confirms exactly what transaction is supposedly being requested.
↓
S — Source-check
Finance verifies the request against the approved transaction documentation and procurement records.
↓
E — Execute safely
Two authorized finance personnel approve the payment through the normal banking workflow.
Result: Even a highly convincing impersonation has to overcome several independent controls.
Make PAUSE Risk-Based, Not Bureaucratic
One danger is turning verification into excessive bureaucracy.
Employees shouldn’t have to perform five verification steps every time someone asks:
“Can you send me yesterday’s meeting agenda?”
The organization should therefore create a risk-based verification matrix.
Example
| Request | Risk | PAUSE requirement |
|---|---|---|
| Meeting agenda | Low | Normal authentication |
| Internal document | Low | Standard access controls |
| Customer data | Medium | Identity + authorization |
| Password reset | High | Strong identity verification |
| Bank-account change | High | Independent verification |
| Large payment | Critical | Independent verification + dual approval |
| Privileged administrator access | Critical | Strong authentication + authorization + logging |
| Emergency executive request | High/Critical | Independent verification |
This makes PAUSE practical rather than disruptive.
Build PAUSE Into Technology
The strongest implementation doesn’t depend entirely on employees remembering a training module.
The technology should make the secure behaviour easier.
Example 1: Email
If an email contains language suggesting:
- urgent payment;
- bank-account change;
- credential request;
- confidential-data transfer;
the system can display:
PAUSE — This request involves a high-risk action. Verify independently before proceeding.
Example 2: Finance platform
Before approving a large payment:
Independent verification required.
The system records:
- who verified the request;
- verification method;
- timestamp;
- transaction amount;
- approving personnel.
Example 3: Privileged-access system
Instead of:
“CEO requested admin access.”
the workflow becomes:
Identity verified → business justification → manager approval → security approval → time-limited access.
This is verification by design.
Create a “Trusted Channel Registry”
One of the most useful practical measures is to establish an organizational list of trusted verification channels.
For example:
Executives
- official corporate number;
- executive assistant;
- corporate directory;
- board portal.
Vendors
- approved vendor-management system;
- previously validated contact;
- procurement portal.
Banks
- established relationship manager;
- independently sourced official bank contact;
- approved banking portal.
Employees
- HR system;
- corporate identity platform;
- official directory.
The principle is:
Never allow the suspicious communication itself to define the verification channel.
Train Employees With Simulations, Not Lectures
Traditional cybersecurity awareness often asks employees to recognize suspicious emails.
PAUSE training should instead simulate decision-making under pressure.
Simulation 1 — Voice clone
Employee receives a simulated CEO call requesting an urgent payment.
Measure:
- Did they pause?
- Did they independently authenticate?
- Did they follow the payment procedure?
- Did they report the incident?
Simulation 2 — Deepfake video
Employees receive a fabricated executive video announcing a confidential restructuring.
Measure:
- Did employees forward it?
- Did they check official corporate communications?
- Did they report the suspicious material?
Simulation 3 — Vendor fraud
Employees receive a realistic request to change bank details.
Measure:
- Did they independently contact the vendor?
- Did they use the approved process?
- Did they escalate appropriately?
The objective should not be to embarrass employees who fail a simulation.
The objective is to identify where the organization’s verification architecture breaks down.
Give Employees a “No-Blame Verification” Culture
This is critical.
An employee may hesitate to challenge a CEO because:
“What if it really is the CEO?”
Organizations should explicitly give employees permission to verify—even when dealing with senior executives.
A useful cultural rule is:
Nobody is above verification.
A CFO should expect a finance employee to independently verify a payment request.
A CEO should expect an assistant to authenticate an unusual instruction.
A senior executive should never punish an employee for following the organization’s verification process.
That changes verification from an act of distrust into an accepted security procedure.
Measure Verification, Not Just Phishing Clicks
Traditional cybersecurity metrics include:
- phishing click rate;
- malware infections;
- incidents;
- patch compliance.
PAUSE introduces additional metrics.
Suggested PAUSE metrics
Pause rate
Percentage of simulated high-risk requests where employees stopped before acting.
Independent verification rate
Percentage of high-risk requests independently verified.
Verification bypass rate
Percentage of requests where established controls were circumvented.
Time-to-verify
Average time required to independently establish authenticity.
False escalation rate
How often employees appropriately escalate ambiguous requests.
High-risk transaction compliance
Percentage of financial/privileged transactions following the required verification process.
These metrics provide management with evidence about whether a verification culture actually exists.
Establish a PAUSE Incident-Response Path
Employees also need to know what happens after they become suspicious.
Create a simple mechanism:
PAUSE → VERIFY → REPORT
For example:
Think something is wrong? Don’t investigate alone. Pause the transaction and notify Security/Fraud Response.
A report might automatically capture:
- sender;
- communication channel;
- time;
- requested action;
- transaction value;
- screenshots;
- relevant attachments.
Security teams can then investigate without requiring the employee to become a forensic analyst.
Extend PAUSE to AI Agents
As organizations deploy AI agents, PAUSE should apply to machine-generated actions too.
For example, an AI procurement agent might receive:
“Supplier banking details have changed. Update the payment record.”
The agent should not automatically execute the instruction.
A machine-oriented PAUSE process could be:
Pause → Authenticate source → Understand action → Check authoritative system → Execute within policy
For high-risk actions:
AI recommendation → human verification → authorized execution
This becomes especially important as AI agents gain the ability to access enterprise systems and perform actions autonomously. NIST’s recent work on agentic AI security identifies the need to adapt conventional cybersecurity principles to these emerging systems.
A 90-Day PAUSE Implementation Roadmap
An organization could implement the framework in three stages.
Days 1–30: Identify
Map high-risk interactions:
- payments;
- credentials;
- privileged access;
- sensitive data;
- vendor changes;
- executive instructions;
- AI-agent actions.
Then classify them by risk.
Days 31–60: Design
Create:
- verification procedures;
- trusted-channel registries;
- approval workflows;
- escalation procedures;
- employee training;
- technical warnings;
- audit requirements.
Days 61–90: Test
Run realistic simulations involving:
- phishing;
- voice impersonation;
- executive fraud;
- vendor fraud;
- deepfake content;
- AI-agent manipulation.
Measure the results and redesign weak points.
The End State: Verification Becomes Infrastructure
The ultimate objective isn’t to create employees who are permanently suspicious.
It is to create an organization where verification is normal, proportionate and easy.
The transformation looks like this:
Old model
“Do I recognize this person?”
↓
PAUSE model
“How do I independently establish that this person, request and transaction are authentic?”
And ultimately:
Trust → Verify → Authorize → Execute
That is the central idea behind verification by design.
AI will continue to make digital interactions more convincing. Organizations therefore cannot rely exclusively on employees becoming better at spotting fake content. They need systems and processes that remain safe even when the deception looks authentic.
The most resilient organizations will not necessarily be those that can detect every deepfake.
They will be those in which a convincing deepfake still cannot authorize a consequential action on its own.
