Executive assistant operations planning

Executive Impersonation and Deepfakes: A Verification Playbook for Assistants

Research-backed controls for handling urgent voice, video, email, and messaging requests that appear to come from a CEO or trusted executive.

Executive assistant reviewing a controlled executive-office workflow

What should an executive assistant do when an urgent request looks or sounds like the CEO but asks for money, credentials, sensitive data, or a changed process?

During a video call, a familiar face and voice direct an assistant to send confidential documents and arrange a payment to a new account. The request invokes a secret acquisition and insists that ordinary approvers must not be contacted.

This research guide converts current primary guidance into a narrow CEO-office workflow. It distinguishes sourced facts from our operational analysis, identifies uncertainty, and leaves legal, employment, security, records, and business judgments with qualified owners. The sources were checked on 2026-10-05; their requirements and advice can change, and organizations must account for their own geography, contracts, systems, policies, and risk.

Method and limitations

We reviewed the cited authorities for controls that can be observed in executive-assistant work: purpose limitation, named ownership, trustworthy source evidence, access restriction, independent verification, version history, exception handling, and documented closure. We then applied those controls to the scenario above. This is practical operational analysis, not legal, employment, cybersecurity, privacy, records-management, or compliance advice. The cited publishers do not endorse this site or this synthesis.

The method has important limits. Public guidance cannot establish the facts of a particular candidate, device, message, account, incident, or organization. A checklist cannot replace product-specific testing or professional judgment. Local law, collective agreements, employment rules, contractual duties, and sector obligations may change the correct process. Where the source and the operational recommendation differ, the source describes the authority’s guidance; the workflow is our inference for CEO-office coordination.

Define high-consequence triggers in advance

List the actions that always require independent verification: new payment details, unusual transfers, credential or code requests, sensitive exports, secrecy demands, disabled controls, or changes to an established contact. The rule should apply even when the requester appears to be the CEO and even when the request arrives in a familiar meeting.

Verify through an independently established route

Use a known number, approved authentication workflow, or another trusted person selected before the incident. Do not use the phone number, link, contact card, or callback instruction supplied in the suspicious request. A private question can help only if its answer is controlled, current, and not discoverable; it should not replace stronger organizational controls.

Separate identity, authority, and transaction checks

Proving who asked does not prove the request is authorized, accurate, or safe. Confirm the requester, the business authority, the beneficiary or recipient, and the transaction details through their respective owners. Keep dual approval and reconciliation intact. A confidential project can narrow the audience without eliminating controls.

Escalate and preserve without amplifying exposure

Stop the action, contact security and the affected functional owner, and preserve the original message, headers, call details, account changes, and actions already taken. Do not forward sensitive content broadly or confront the suspected actor through the compromised channel. Follow the incident plan for containment, external reporting, and notifications.

A twelve-field control record

The control record should be short enough to use during real work and precise enough for a different authorized person to reconstruct the decision. These fields are a starting model, not a universal retention requirement.

1. Request channel

Record request channel in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

2. Claimed requester

Record claimed requester in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

3. Requested action

Record requested action in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

4. High-consequence trigger

Record high-consequence trigger in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

5. Independent contact route

Record independent contact route in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

6. Identity verifier

Record identity verifier in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

7. Authority owner

Record authority owner in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

8. Recipient or beneficiary check

Record recipient or beneficiary check in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

9. Second approver

Record second approver in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

10. Stop decision

Record stop decision in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

11. Incident reference

Record incident reference in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

12. Reconciliation result

Record reconciliation result in the approved system and name the person accountable for its accuracy. Link to source evidence rather than copying restricted information into a general tracker. Show whether the item is verified, assumed, disputed, expired, or awaiting a decision. If it changes after approval, preserve the version that informed the earlier decision and route the change to the appropriate owner.

Decision gates for the CEO office

Proceed only when the purpose, accountable owner, authority, source evidence, audience, and completion proof are clear. Pause when an essential fact is unverified, a required reviewer is unavailable, the request conflicts with policy, or the requested action would be difficult to reverse. Escalate when the request crosses legal, employment, security, financial, privacy, or governance boundaries. An escalation should identify the decision needed and the last useful decision time without pressuring the owner to approve an unsupported choice.

Urgency changes the cadence, not the evidence standard. A fast path can shorten the record to verified facts, material uncertainty, decision owner, safe options, and next checkpoint. It should not remove independent verification, combine incompatible roles, or turn an assistant’s access into authority. If no approved path exists, preserve the request and stop condition while the accountable owner decides.

Quality review before closure

  • Sample request channel against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.
  • Sample claimed requester against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.
  • Sample requested action against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.
  • Sample high-consequence trigger against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.
  • Sample independent contact route against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.
  • Sample identity verifier against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.
  • Sample authority owner against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.
  • Sample recipient or beneficiary check against its authoritative source. Log a mismatch, missing owner, or expired check as an exception with a due date; do not silently rewrite the history.

Review exceptions by consequence. A cosmetic formatting defect is not equivalent to an unverified identity, unclear authority, uncontrolled copy, or missing preservation instruction. Closure requires evidence that the action reached the right system, person, or state—not merely that someone sent an email.

A 30-day implementation pattern

During days 1–5, inventory the current request paths, systems, owners, copies, approvals, and recurring exceptions. Follow at least one normal case and one difficult case from intake to closure. During days 6–10, agree on the minimum record, decision rights, stop conditions, authoritative source, backup owner, and proof of completion.

During days 11–20, pilot the workflow with realistic uncertainty. Test a missing owner, conflicting source, urgent request, unavailable approver, and backup handoff. Verify that the process works without shared credentials, private archives, or unwritten exceptions. During days 21–30, review rework, preventable escalation, access, stale evidence, cycle time, and user confusion. Remove fields that do not support decisions, but retain the controls that make authority and closure visible.

Niche-specific conclusion

Familiar appearance, voice, thread history, and urgency are context—not independent authentication. High-consequence requests need a pre-agreed verification channel, separation of duties, and a stop rule that seniority cannot override in the moment.

An executive assistant creates leverage by making the right decision easier and the wrong action harder: establish the purpose, bring forward current evidence, protect restricted information, preserve the authority boundary, and close the loop in the system of record. That discipline protects executive attention without asking the assistant to become the organization’s lawyer, security officer, HR leader, records manager, or final risk owner.

To connect this control model with hands-on delegation, review our project and task coordination service or contact us about the executive work you want to structure.

#executive-assistant#executive-operations#governance#research

Need Help With Delegation?

Discuss your role scope, systems, and recurring delegation priorities.

Get My Free Consultation