AI Phishing Tabletop Exercise: How to Test Human Decisions, Technical Controls, and Incident Response Readiness

Key takeaways

• An AI phishing tabletop exercise rehearses decisions, authority, and coordination across email, voice, SMS, video, and cloud channels before a real AI-enabled cyberattack forces them.
• Timed injects should escalate from a suspicious email to a cloned voice, synthetic video, supplier compromise, and cloud-account activity, with a named decision owner at every step.
• Independent verification through a pre-established channel remains the core control, because a familiar face or voice cannot prove identity.
• A no-fault format, written consent for synthetic media, and strict data governance keep the exercise safe and candid.
• Findings create value only when each gap receives an owner, a deadline, acceptance criteria, and a retest through a different channel.

Want more from Adaptive in your Google results?

An AI phishing tabletop exercise is a facilitated rehearsal of an AI-enabled cyberattack. It tests how an organization makes decisions before fraud, credential theft, account takeover, or data loss spreads.

This guide explains how to build a realistic scenario, assign cross-functional roles, and use timed injects across email, voice, video, SMS, supplier, and cloud channels. Those injects expose gaps in verification, escalation, authorization, and evidence handling. The guide also covers how teams should respond when someone clicks, submits credentials, approves an MFA request, or reports a suspicious message, without turning the session into a blame exercise.

The National Cyber Security Centre’s tabletop guidance and CISA’s AI Cyber Tabletop Exercise Series both reinforce the value of rehearsing communication, incident response, and public-private coordination under pressure. A small organization can run a focused one-hour version with a single business email compromise or executive-impersonation scenario. Larger teams can go further and test payment controls, legal decisions, recovery, and board reporting.

Applied well, the practices in this guide produce a safer, measurable exercise that converts observed behavior into targeted improvements across people, processes, and technology. To carry tabletop findings into realistic practice, take a self-guided tour of Adaptive Security’s phishing simulations.

What Is an AI Phishing Tabletop Exercise?

An AI phishing tabletop exercise is a facilitated, discussion-based rehearsal in which an organization works through a simulated AI phishing incident. The scenario can involve spear phishing, business email compromise (BEC), vishing, smishing, deepfakes, or account compromise.

The exercise tests how people make decisions, communicate, authorize actions, escalate concerns, and coordinate a response before a real cyberattack causes financial, operational, or reputational damage. It differs from a live phishing simulation because it does not assess whether an employee clicks a link or enters credentials. It also differs from a penetration test because it makes no attempt to exploit a technical weakness.

What Does an AI Phishing Tabletop Exercise Cover?

An AI phishing tabletop exercise places participants inside a realistic attack narrative and asks how they would respond at each decision point. A facilitator might present an email that appears to come from the chief financial officer. An AI-cloned voice message could then request an urgent wire transfer, followed by a deepfake video call confirming the instruction.

The group examines its own decisions at each stage. Waiting to see whether someone falls for the lure is not the purpose.

The exercise can begin with any AI-enabled social engineering signal. Examples include an AI-generated phishing email, a personalized spear phishing message, a vendor impersonation request, a suspicious password-reset prompt, or a deepfake executive call. The scenario becomes more useful when it crosses channels, because cyberattackers can move from email to SMS, voice, collaboration software, or a video meeting within minutes.

The facilitator introduces information in stages. Participants receive the initial message, followed by facts such as a reported account takeover, an employee who approved a payment, a journalist asking questions, or a second executive receiving the same request.

This structure reveals whether the organization has a repeatable process for validating identity, freezing a transaction, preserving evidence, notifying leadership, and communicating with affected employees.

The exercise should involve the functions that own those decisions. Security and IT may investigate the account, and finance may pause a payment. Legal may assess notification duties, communications may prepare internal messaging, and an executive sponsor may authorize business disruption.

Turning every participant into an incident responder is unnecessary. The aim is to expose the points where responsibility, authority, or information stops moving.

The National Cyber Security Centre’s tabletop exercise guidance describes tabletop exercises as group discussions designed to identify potential responses to an unfolding cyber incident. That framing matters because the exercise rehearses organizational judgment, which a technology demonstration cannot do.

A useful session ends with documented decisions, unresolved questions, assigned owners, and deadlines for closing response gaps.

An organization can use those findings to update verification procedures, payment controls, executive impersonation protocols, reporting channels, escalation matrices, and training content. It can also connect the exercise to multi-channel phishing simulations, using controlled tests to rehearse the behaviors the discussion identified as uncertain.

How Is an AI Phishing Tabletop Exercise Different From Other Security Exercises?

An AI phishing tabletop exercise answers a different question from each related exercise. The distinction matters because the wrong format can produce misleading results.

A live phishing test might show that an employee clicked a link. It will not necessarily reveal whether finance knows who can stop a transfer or whether legal has approved the external notification process.

A live phishing simulation creates a controlled interaction with an individual. It measures whether the employee reports a suspicious message, verifies an unusual request, or follows a designated process.

A simulation should build skills and measure behavior. Humiliating employees has no place in it. People are strongest when they understand what a convincing cyberattack looks like and feel confident reporting it quickly.

A penetration test examines technical exploitability. Testers may assess an application, network boundary, cloud configuration, or identity control under written authorization.

That work can identify vulnerabilities a cyberattacker could exploit. It does not establish whether a finance manager can recognize a fraudulent invoice or whether an executive assistant knows which channel to use for identity verification.

A red-team exercise is broader and more adversarial. The team may attempt to achieve a defined objective while defenders work under realistic conditions. A red team can include phishing or impersonation, but it usually tests operational detection and response against an active opponent.

A tabletop allows leaders to examine assumptions before introducing the pressure and uncertainty of a live adversarial test. Deepfake simulation exercises can then add controlled, realistic practice once those assumptions are settled.

A technical disaster-recovery test focuses on restoring technology after disruption. It can determine whether backups are usable and whether critical systems return within an approved time frame.

An AI phishing tabletop examines what happens before recovery begins. Who validates the request? Who can stop a payment? Who takes control of a compromised account? Who informs customers, regulators, employees, and the board?

The formats can complement one another. A mature program might discuss a deepfake-enabled BEC scenario in a tabletop and test reporting and verification behavior through a live simulation. The same program might assess identity-control weaknesses through a penetration test and validate system restoration through a disaster-recovery exercise.

Each format produces different evidence, so no single format can stand in for the others.

What Are the Rules of Engagement for an AI Phishing Tabletop?

Rules of engagement keep the exercise focused on learning. They also prevent it from becoming an uncontrolled security event.

The sponsor should define the purpose, scope, participants, scenario boundaries, communication channels, and stop conditions before the session begins. Participants also need to know whether the exercise is purely discussion-based or connected to a later simulation.

A practical set of rules includes:

• State that the exercise is no-fault. Evaluate processes and decisions. Individual intelligence, attentiveness, and job performance are outside the scope.
• Define the scenario boundary. Specify whether the incident involves email, voice, SMS, deepfake video, collaboration tools, credential theft, payment fraud, or several channels.
• Use fictionalized assets. Do not send real payment instructions, collect credentials, contact customers, or alter production systems during a discussion exercise.
• Name decision owners. Identify who can approve account suspension, payment holds, public statements, legal review, customer notices, and executive escalation.
• Require evidence-based assumptions. When participants do not know an answer, record the gap. Improvising a policy that does not exist hides the finding.
• Protect sensitive discussion. Handle scenario notes, employee examples, and incident details according to the organization’s confidentiality and retention requirements.
• Set a stop condition. Pause the exercise if participants suspect a real incident, operational disruption, or unauthorized disclosure.
• Document corrective actions. Assign each gap to an owner with a deadline, and retest the process after the change is implemented.

The facilitator should keep the discussion moving without supplying the answer. Questions such as “What would you verify immediately?”, “Who has authority to pause the transfer?”, “Which channel is trusted for confirmation?”, and “What evidence would you preserve?” force the group to translate policy into action.

A strong exercise also separates recognition from response. Participants may correctly identify an AI-generated voice but still lack authority to stop a payment. They may know that an account is compromised but lack a clear path to revoke sessions, notify customers, or preserve forensic evidence. Those gaps are operational findings. They say little about individual employees.

The final deliverable should be an after-action report that records what worked, what stalled, which assumptions proved false, and what the organization will change.

When the discussion identifies a behavior that requires practice, targeted security awareness training or a controlled phishing simulation turns the finding into a measurable cycle. That cycle moves from preparation and rehearsal to correction and improved response readiness.

Why Should an Organization Run an AI Phishing Tabletop Exercise?

An organization should run an AI phishing tabletop exercise because generative AI makes social engineering more convincing, personalized, multilingual, scalable, and difficult to attribute. Deepfake audio and video add authority to urgent requests, so a familiar face or voice cannot serve as proof of identity.

AI increases the speed and realism of cyberattacks. A tabletop exercise gives employees and leaders a controlled way to rehearse verification, escalation, and recovery before a real request creates financial, operational, or regulatory damage.

Why Does AI Create a New Phishing Defense Gap?

Generative AI changes phishing risk by improving a cyberattacker’s ability to imitate context. Traditional phishing often exposed itself through awkward wording, inconsistent formatting, or a generic request.

Generative AI can produce fluent messages in the target’s language, mirror an executive’s writing style, and adapt a request to a current project, supplier, transaction, or internal event. Cyberattackers can use open-source intelligence (OSINT), meaning publicly available information about people and organizations, to make a spear phishing message appear to come from a known contact.

That personalization matters because trust builds from several aligned signals. A single suspicious email is rarely the whole story. A finance employee might receive an invoice request that references a real vendor, a recent meeting, and a plausible payment deadline.

A second message can confirm the request through SMS. A voice call can then use a cloned executive voice to remove the last moment of hesitation.

The exercise should rehearse the exact verification step employees must follow when multiple channels reinforce the same request. A policy that requires independent confirmation through a known phone number is useful only when people practice applying it under pressure.

AI also makes it possible to produce attacks at scale. One criminal group can generate different messages for executives, accounts-payable staff, recruiters, and administrators without manually writing each lure.

The same campaign can run across email, vishing, smishing, and collaboration tools. Defenders must then recognize the underlying behavior, since memorized visual warning signs no longer suffice. An exercise using multi-channel phishing simulations should test whether teams identify the request’s risk pattern across channels. Spotting a misspelled word is a far weaker test.

Deepfake audio and video raise the stakes by exploiting authority and urgency simultaneously. In 2024, a caller posing as former Ukrainian Foreign Minister Dmytro Kuleba appeared and sounded consistent with prior encounters during a video call with U.S. Sen. Ben Cardin. The impersonator then pressed him with politically charged questions, according to NBC News.

Cardin ended the call and alerted authorities after recognizing behavior that did not fit the relationship. His response demonstrates the action organizations should rehearse. Unusual pressure or out-of-character conduct is a reason to stop, verify, and report, even when the face and voice appear authentic.

The Senate security warning that followed noted that cyberattackers were using known relationships and publicly available information to appear legitimate.

Detection technology alone cannot close this gap. Employees remain the decision point when a cyberattacker asks for a payment, password, access approval, or confidential file.

Training that covers only email phishing leaves a practical gap when the same manipulation arrives through a video meeting or phone call. An AI phishing tabletop closes that gap by making the organization define which signals override apparent familiarity and which team owns the next decision.

What Business Consequences Should the Exercise Expose?

An AI-generated request can become business email compromise when a cyberattacker impersonates an executive, supplier, or partner to redirect funds or obtain sensitive information.

The immediate consequence is payment fraud, but the attack path often continues through stolen credentials, cloud-account takeover, and unauthorized access to shared files. The exercise should make participants trace that chain. Treating a suspicious message as an isolated help-desk event misses the larger risk.

A realistic scenario can begin with an AI-generated invoice request and progress through several decision points. The accounts-payable team must decide whether to pause payment. The manager must determine whether the request is legitimate. The identity team must respond if credentials were entered.

The security team must preserve the message, call details, headers, screenshots, and authentication records. Legal, privacy, and communications leaders must assess whether data was exposed and whether notification duties apply. Each handoff reveals whether the organization can contain the incident before it becomes a wider compromise.

Credential theft creates a second route to damage. An adversary-in-the-middle phishing page can relay a login in real time and capture both a password and a session token. That access allows a cyberattacker to enter cloud services as a legitimate user.

From there, the cyberattacker can search mailboxes, create forwarding rules, access customer records, or use the compromised account to target colleagues, following a familiar email account takeover lifecycle.

Teams should rehearse rapid reporting, account containment, session revocation, evidence preservation, and targeted notification. Employees should know that reporting a suspected mistake quickly is a protective behavior. Treating it as an admission of failure only discourages early reports.

Ransomware and data exfiltration can follow when compromised credentials provide access to privileged systems or sensitive repositories. A phishing tabletop should force leaders to decide what happens if an employee reports a suspicious attachment after opening it. It should also cover a deepfake executive call that persuades an administrator to approve an access change.

The discussion should identify which systems are isolated, which backups are trusted, and who authorizes recovery. It should also settle how the organization communicates without destroying evidence or increasing public confusion, drawing on an established ransomware incident response plan.

Regulatory exposure follows the facts of the incident. The cyberattacker’s sophistication does not change the obligations. An organization must determine whether personal data, protected health information, payment data, or confidential business records were accessed.

The exercise should bring compliance and legal teams into the scenario early enough to review preservation requirements, notification thresholds, contractual duties, and regulator communications. Training content mapped to applicable frameworks gives teams a common reference. The tabletop tests whether those requirements become timely decisions during an incident.

Reputational harm compounds every other consequence. Customers, partners, and employees judge an organization by how quickly it recognizes the problem, contains access, and explains what happened. A delayed or contradictory response can turn a single fraudulent request into a broader loss of trust.

To limit that harm, the organization should assign a communications lead, prepare internal escalation language, and define who can approve external statements before an incident occurs.

A documented case shows why this planning cannot remain theoretical. In 2024, criminals used a deepfake video conference to convince an employee at engineering firm Arup in Hong Kong to transfer roughly $25 million, according to CNN’s report on the Arup deepfake scam. The employee joined a call populated by impersonated colleagues, including the company’s chief financial officer, as Adaptive Security’s breakdown of the Arup attack describes.

Any scenario assumption in a tabletop should be labeled clearly, but the business logic here is real. When several synthetic identities reinforce an urgent financial request, ordinary approval habits can fail. Participants should test whether dual approval, independent callback procedures, and transaction holds still work when the apparent executive is present on video.

What Should an AI Phishing Tabletop Exercise Measure?

The exercise should measure decisions and coordination. Attendance reveals little. CISA’s Tabletop Exercise Packages provide customizable scenarios, objectives, and discussion questions covering phishing, ransomware, incident response, information sharing, and recovery.

That structure supports a practical exercise in which leaders identify gaps, assign owners, and record corrective actions. A discussion limited to whether employees know phishing definitions would add little value.

The exercise should measure six outcomes:

• Decision speed: How long does it take to pause a payment, disable a compromised account, or convene the response team?
• Reporting quality: Does the employee provide the original message, phone number, meeting link, timestamp, requested action, and other evidence analysts need?
• Verification behavior: Does the recipient use a trusted, independent channel? Replying to the suspected sender or accepting the same video call as proof fails this test.
• Escalation accuracy: Does the report reach the right security, finance, legal, privacy, and executive contacts without unnecessary delay?
• Evidence preservation: Do participants retain email headers, chat logs, call recordings where permitted, screenshots, transaction details, and identity telemetry?
• Recovery coordination: Can technical, finance, legal, communications, and business teams agree on containment, restoration, customer notification, and post-incident review?

The scenario should distinguish documented facts from assumptions. The deepfake incidents cited in this article are documented events. A fictional company name, payment amount, compromised account, and internal escalation time are scenario assumptions. They let participants test their own controls without implying that the event occurred at their organization.

The strongest outcome is a prioritized improvement plan. If finance cannot verify an urgent transfer without contacting the apparent requester, the organization should assign an owner and deadline for a callback protocol.

If employees report suspicious messages without original evidence, the reporting workflow needs an update and another rehearsal. If executives bypass escalation because the request appears to come from another executive, the organization should establish a verification rule that applies to every role.

A tabletop cannot guarantee that every employee will reject every AI-generated lure. It gives the organization measurable evidence about where human judgment, policy, and recovery coordination break down.

That evidence turns AI phishing from an abstract cyberthreat into a testable business process. Security leaders can then improve behavior before a cyberattacker creates the pressure for them.

How Should Organizations Design a Realistic AI Phishing or BEC Tabletop Scenario?

Build each AI phishing tabletop exercise scenario, including BEC variants, around a real business process, a credible attack path, the people and systems involved, and the behavior participants must practice. Tailor the scenario to the organization’s industry, workflows, exposed information, and authority structure, using fictionalized OSINT and synthetic identities.

Keep the exercise challenging but safe. Separate discussion from production systems, protect sensitive data, and measure decisions while avoiding individual blame.

1. Select the Business Process and Threat Path

Choose the business process where one deceptive request could create material operational, financial, privacy, or safety consequences. Finance teams might approve a vendor payment, healthcare teams might release patient information, and IT teams might reset an executive account. The process gives the exercise a concrete decision point and keeps it from drifting into a general conversation about phishing.

Choose a threat path that reaches that process, using AI phishing threat modeling to map the likely route. An AI-generated phishing email can begin the attack. A realistic exercise should also show how the cyberattacker builds trust across channels.

A message from a compromised legitimate account might request an urgent payment, followed by a vishing call from someone claiming to be the CFO. A supplier impersonation scenario might use a fake invoice, a lookalike domain, and a second message asking the recipient to update bank details.

Treat BEC as a sequence of decisions. A single suspicious email captures only its first step. The scenario should reveal what participants see, what they know, what they assume, and what they can verify at each stage.

This design makes it possible to test whether employees follow payment controls and whether managers challenge unusual requests. It also shows whether security teams can contain a compromised identity before the cyberattacker reaches another workflow.

The National Cyber Security Centre’s tabletop exercise catalogue includes scenarios for phishing-delivered ransomware, supplier compromise, bring-your-own-device exposure, insider threat, and sensitive-data leaks. Use those scenario families as planning references. Then replace the generic trigger with the organization’s own approval chain, suppliers, systems, and escalation contacts.

2. Map Industry-Specific Assets and Workflows

A credible AI phishing tabletop exercise reflects how work actually moves through the organization. Document the assets involved in the selected process, including email accounts, identity providers, customer records, payment platforms, cloud storage, collaboration tools, mobile devices, manufacturing systems, and third-party portals.

Map the normal workflow from request to approval, execution, recording, and reconciliation.

For financial services, build around a wire transfer, loan-funding instruction, payroll change, privileged trading request, or customer identity-verification exception. Identify dual-approval rules, callback procedures, treasury systems, relationship managers, and the people who can change payment instructions. The learning objective should focus on slowing high-value transactions when urgency and apparent authority combine to pressure staff.

For healthcare, use a patient-record request, prescription workflow, insurance payment, medical-device account, or hospital scheduling process. Map protected health information, clinical leadership, health information management, shared workstations, and external partners.

The healthcare exercise should test whether staff verify identity without exposing patient data. It should also reveal whether clinical urgency is being used to bypass normal safeguards.

For technology and SaaS organizations, select a production-access request, source-code repository invitation, cloud administrator reset, customer-support escalation, or API-key rotation. Include engineering, support, identity, and cloud operations. Participants should practice verifying privileged changes through trusted channels and recognizing when a realistic request still conflicts with the normal deployment process.

For government and education, focus on grants, procurement, benefits, student records, public communications, or emergency directives. These environments often involve distributed offices, public-facing information, seasonal staff, and formal records requirements.

The scenario should test whether participants can distinguish a legitimate urgent directive from an impersonated authority without delaying a genuine public-service response.

For manufacturing, operational technology, and critical infrastructure, plant-floor systems deserve different treatment from ordinary email targets. Map enterprise IT, maintenance contractors, engineering workstations, remote access, safety systems, scheduling, and supplier dependencies.

The compromise might begin with an IT credential reset and end with unauthorized access to a maintenance portal. The objective is to verify identity, isolate affected accounts, preserve safe operations, and escalate without making unsafe changes to industrial systems.

3. Identify Likely Targets and Decision Owners

Include the roles that control the selected process, along with the people who receive the initial message. Finance staff, executive assistants, procurement managers, help desk analysts, clinicians, researchers, plant engineers, administrators, and contractors each see different signals and hold different authority. Including their handoffs exposes gaps that a single-recipient phishing test cannot reveal.

Use role data to define the cyberattack’s credibility. An executive assistant may receive a request to schedule a confidential meeting, while a help desk analyst receives an account-recovery call. A procurement manager may see a supplier’s revised banking details, while a cloud engineer receives an invitation to a new project.

The simulated cyberattacker should know enough about the target’s responsibilities to make the request plausible, without exposing real confidential information.

A real cyberattacker can draw open-source intelligence from public biographies, conference presentations, job postings, procurement notices, press releases, social media, and organizational charts. For the exercise, replace real names, phone numbers, account identifiers, customer references, and payment details with synthetic equivalents.

Preserve the relationship and context, because those are what participants must learn to verify.

4. Choose the Scenario Variant and Injects

Select one primary variant and add only the injects needed to test the learning objectives. A compromised legitimate account tests whether employees trust familiar senders too quickly and whether defenders detect abnormal behavior. A supplier impersonation tests invoice verification, contract-owner confirmation, and changes to payment instructions.

Executive impersonation tests authority pressure through email, vishing, SMS, or a deepfake video call. Account recovery tests whether a help desk verifies identity when a senior employee claims to be locked out.

A malicious forwarding-rule scenario tests whether a cyberattacker who gains access can silently redirect invoices, credentials, or sensitive correspondence. A third-party compromise tests whether the organization can respond when a trusted software provider, contractor, or service account becomes the initial route into a business process.

Build the exercise in timed stages. Begin with the initial message, then introduce a reply from a trusted-looking account, a phone call, a failed login alert, a supplier complaint, or a news report about the compromised third party.

Each inject should force a decision about whether to approve, verify, report, isolate, preserve evidence, notify leadership, or continue operating through a manual process.

5. Define the Intended Learning Objectives

Write the learning objectives before writing the scenario text. Each objective must describe observable behavior. Examples include verifying a payment change using a known contact, reporting a suspicious message through the approved channel, refusing to disclose a recovery code, disabling a malicious forwarding rule, or escalating a suspected supplier compromise.

Keep the objectives narrow enough to evaluate. One exercise can test whether finance employees follow callback procedures, whether help desk staff resist authority pressure, and whether security analysts identify identity abuse. Attempting to test every control at once dilutes the results.

Connect each objective to a decision checkpoint. If the exercise tests payment verification, record whether participants challenge the request before approval. If it tests account recovery, record which identity signals they require.

If it tests third-party compromise, record how quickly the organization identifies affected accounts, contacts the supplier, and shifts to a safe operating procedure.

Modern phishing simulations for email, voice, SMS, and deepfake scenarios can extend tabletop decisions into controlled behavioral practice. The exercise remains useful when the simulation reinforces the same verification and reporting behaviors discussed in the room.

6. Set Safety Boundaries Before the Exercise Begins

Safety boundaries protect employees, operations, and the integrity of the test. Announce the exercise to the executive sponsor, security lead, legal team, privacy owner, communications team, and relevant operational managers. Keep the participant list confidential when appropriate, but ensure that every production owner knows how to stop the exercise.

Never use real payment instructions, patient records, credentials, recovery codes, personal phone numbers, sensitive customer data, or live industrial commands. Use synthetic identities, fictional domains that cannot be confused with active partners, and screenshots that cannot trigger real transactions. Do not send simulated messages from real executive accounts or alter production forwarding rules.

Define stop conditions for operational disruption, employee distress, suspected real compromise, safety risk, or accidental exposure of sensitive data. Give facilitators a clear pause phrase and a direct escalation route.

For operational technology and critical infrastructure, keep injects in a discussion environment unless the relevant safety and engineering authorities approve a separate controlled test.

Close with a structured debrief. Ask what signals participants noticed, which assumptions slowed verification, where ownership became unclear, and what process change would prevent a repeat.

Measure reporting quality, verification behavior, escalation speed, and decision consistency alongside the mistakes participants describe. Proving that employees failed is the wrong goal. The strongest outcome is a documented workflow that helps them recognize pressure, verify trusted identities, and stop an AI-enabled request before it becomes a business loss.

Who Participates in an AI Phishing Tabletop Exercise?

An AI phishing tabletop exercise succeeds when the right people rehearse decisions before a cyberattacker forces those decisions under pressure. Build the roster, assign each participant a defined role, and establish confidentiality, consent, accessibility, and stop rules before the first scenario inject.

Keep the exercise no-fault and operationally realistic so employees surface process gaps without fear of blame.

1. Build the Participant Roster

Start with a core response team that can evaluate an AI-generated phishing attack from detection through recovery. Include representatives from security operations, IT, identity and access management, cloud infrastructure, legal, privacy, HR, communications, finance, procurement, cyber insurance, and business continuity.

Add executive leadership when the scenario involves a wire transfer, public disclosure, customer notification, regulatory reporting, or disruption to critical services.

Assign active players to the functions that must make decisions during the incident. Security operations examines alerts and threat signals. IT and identity teams isolate accounts, reset credentials, and manage authentication controls. Cloud owners assess exposed services and tokens.

Legal and privacy leaders determine notification, privilege, evidence preservation, and data-handling requirements. Finance and procurement verify payment controls and vendor relationships. Communications prepares internal and external messaging, while HR supports employee communications and welfare.

Include relevant vendors or government partners when their response affects the outcome. An email, identity, cloud, managed security, insurance, or incident-response provider, or a law enforcement contact, can participate as a player or receive a controlled inject.

Inviting every stakeholder by default slows the session. Choose people with decision-making authority, access to the systems under discussion, or responsibility for the consequences.

CISA’s Tabletop Exercise Packages distinguish planners, facilitators, evaluators, and participants. That structure clarifies ownership before the exercise begins. Once the roster is set, connect each person to a role card so the exercise does not depend on job titles alone.

2. Issue Role Cards Before the Exercise

Role cards prevent confusion when the scenario accelerates. Give each card the participant’s function, decision authority, permitted information, prohibited actions, escalation path, and success criteria.

A finance player, for example, should know who can freeze a payment, which independent channel verifies an executive request, and when legal or insurance counsel must be notified.

Separate exercise roles from operational roles:

• Facilitator: Introduces the scenario, asks focused questions, controls pacing, and prevents one department from dominating.
• Controller: Manages injects, timing, simulated messages, and information release.
• Observer: Watches behavior against the objectives without steering decisions.
• Note-taker: Records decisions, timestamps, unresolved questions, assumptions, and owners without editorializing.
• Technical adviser: Explains identity logs, cloud dependencies, deepfake indicators, email telemetry, or vendor capabilities without making decisions for the assigned player.
• Executive sponsor: Protects the exercise’s authority, approves participation, removes organizational barriers, and receives the final action plan without revealing the expected answer during play.

For a realistic multi-channel phishing simulation, define whether the scenario uses email, vishing, smishing, a deepfake video call, or multiple channels. State which data is fictional, which systems are simulated, and whether test messages will reach real inboxes or phones.

Those boundaries prevent a training exercise from becoming an accidental security event.

3. Establish Exercise Governance

Publish the rules in writing during the pre-brief. State that the exercise is no-fault, so participants are evaluated on decisions, coordination, and learning. Personal mistakes are outside the evaluation.

Do not use the session to discipline employees or grade departments. The objective is to expose process gaps while employees practice becoming a stronger line of defense.

Set confidentiality rules that protect candid discussion. Specify who can receive recordings, notes, screenshots, and the after-action report. Mark scenario data as fictional or restricted, prohibit redistribution, and define how long artifacts will be retained.

Require explicit consent before recording voices, faces, or video, particularly when testing deepfake or executive-impersonation scenarios.

Make participation accessible. Provide materials in advance, accommodate captioning and language needs, support screen readers, and offer breaks. Avoid requiring cameras or voice participation when an equivalent channel works. Confirm that remote participants can join through approved platforms without exposing sensitive information.

Define a stop condition before play begins. Any participant can pause the exercise if a real incident emerges, a real person appears at risk, or a live account or system could be affected. The same applies when confidential information is exposed or the scenario causes unacceptable distress.

In that case, the controller freezes injects, the facilitator confirms whether the event is real, and the executive sponsor authorizes resumption or termination. A clear stop rule preserves trust and keeps realism from overriding operational safety.

How Should Timed Injects Test Deepfake, Voice, and Multi-Channel Phishing in an AI Phishing Tabletop Exercise?

Build an AI phishing tabletop exercise as a timed decision sequence that begins with a suspicious email. The sequence then escalates through voice, video, SMS, supplier compromise, payment pressure, authenticator recovery, cloud activity, and public scrutiny.

Prepare every inject with a delivery time, expected decision, facilitator prompt, escalation branch, and stop condition, so participants rehearse actions and avoid debating abstract policy. Keep every synthetic artifact controlled, consented, and reversible. The exercise should strengthen employee judgment without creating a real privacy, financial, or operational incident.

1. Build the Inject Architecture Before the Exercise

The inject architecture should force participants to revisit an earlier decision as the cyberattack changes channels. In a tabletop, personnel receive prompts and explain their response, and CISA’s tabletop exercise packages support that type of structured, practical preparation.

Checking whether one participant recognizes a fake email is a narrow goal. The better test is whether the group can preserve independent verification when every new signal appears to confirm the request.

Write the scenario around one business process, such as a supplier payment, acquisition document, payroll change, privileged-access reset, or executive travel emergency. Assign a named target role, a realistic decision owner, and a business consequence.

Keep the attack path coherent. A finance leader should not receive a random credential lure after approving an invoice unless the scenario explains how the cyberattacker obtained the account or learned about the transaction.

Use a 90-minute exercise with injects arriving every seven to 10 minutes. Give participants time to state what they would do, identify the owner, record the evidence they need, and name the control that permits or blocks the action.

Release new information only after the group commits to a decision. If participants ask for a missing fact, treat that request as a tested behavior. It counts in their favor.

A practical timeline can follow this sequence:

• 00:00, suspicious email: A message from a supplier account requests confirmation of updated banking details. Expected decision: pause the change, preserve the message, and report it through the designated channel. Prompt: “What independently verified fact would allow this request to proceed?”
• 00:08, cloned voice: A caller using the apparent finance executive’s voice says the supplier is waiting and asks the employee not to delay payment. Expected decision: move the request to a known channel and refuse approval based on voice recognition alone. Prompt: “Which trusted number will you use, and where did you obtain it?”
• 00:16, synthetic video: A short video call appears to show the executive and a supplier representative confirming the transfer. Expected decision: stop making decisions inside the call and require a second approver outside it. Prompt: “What changes because the video appears live?”
• 00:25, SMS follow-up: A text message says the executive is entering another meeting and asks the employee to reply “approved.” Expected decision: do not reply, forward the message through the reporting process, and warn the relevant team. Prompt: “Does a new channel add evidence or only repeat the original claim?”
• 00:35, compromised supplier account: The real supplier contact confirms that the email came from its mailbox but says the payment instructions in that email were unauthorized. Expected decision: treat the supplier account as compromised, freeze the transaction, and involve procurement and incident response. Prompt: “Which trust assumptions are no longer valid?”
• 00:45, urgent payment request: The cyberattacker threatens a missed closing or contractual penalty unless the transfer occurs within 20 minutes. Expected decision: apply existing payment approval controls without an exception. Prompt: “Who can approve an emergency exception, and can that person verify the request independently?”
• 00:55, authenticator reset: A help desk ticket requests removal of multifactor authentication for the executive because the executive’s phone is allegedly unavailable. Expected decision: reject the reset until identity and authorization are verified through approved procedures. Prompt: “What evidence is required before changing an authentication factor?”
• 01:05, cloud-account activity: An unfamiliar sign-in is followed by a new inbox rule, file download, or OAuth consent. Expected decision: contain the account, revoke all active sessions and refresh tokens, and preserve logs while the identity team investigates. Prompt: “Which action limits harm without destroying evidence?”
• 01:15, public or regulatory pressure: A journalist, customer, or regulator asks why the organization has not completed the payment or disclosed the incident. Expected decision: route communications through legal, privacy, and executive-response owners. Prompt: “Who may speak, what is verified, and what must remain confidential?”

Use the final 15 minutes to reconstruct the decision chain. Ask when the group first had enough evidence to pause the transaction, which control failed to activate, and whether anyone treated urgency or confidentiality as authorization.

Record decisions, owners, elapsed time, and unresolved dependencies. Those records turn an AI phishing tabletop exercise into a remediation plan. Without them, the session is only a memorable story with no follow-through.

2. Stage Deepfake and Executive Impersonation Safely

Deepfake injects must test trust in identity without exposing a real executive’s likeness, voice, or personal information beyond the written scope. Obtain written consent from every person whose voice, image, title, or public material will appear.

Define the approved channels, audience, exercise window, storage period, vendor access, deletion date, and incident owner before producing any media. Use a synthetic executive identity whenever realism does not require a real person, and use controlled media that cannot be mistaken for an external business instruction. Deepfake awareness training for executives can prepare leaders for the scenarios that do use their personas.

Include a reliable exercise control that facilitators can activate without revealing the answer to participants. Options include a hidden watermark, a prearranged kill phrase, a dedicated exercise phone number, or a facilitator message that stops all simulated activity.

Do not place a synthetic link on a production login page, request a real transfer, alter a real mailbox rule, remove a real authenticator, or contact an actual supplier without separate authorization. Route every message through test accounts and sandboxed workflows.

The Arup case described earlier shows why video presence cannot serve as payment authorization. Reproduce the decision pressure of that incident while keeping financial exposure at zero. Give participants a plausible request, a convincing but controlled video, and a payment workflow that ends at a blocked test approval.

The Cardin call tested a different weakness: whether a credible title and familiar voice could suppress skepticism. Use that pattern to test whether participants challenge an unexpected request for sensitive information, even when the caller appears authoritative.

Facilitators should separate realism from permission. A cloned audio clip can show that a voice is easy to imitate, as cases of deepfake voice fraud demonstrate, but it cannot authorize a payment. A synthetic video can demonstrate visual plausibility, but it cannot validate a beneficiary account.

Supporting emails, follow-up calls, and SMS messages should repeat the same false instruction. Participants then learn to recognize coordinated manipulation, which isolated message-by-message evaluation tends to miss.

At every media handoff, ask three questions. What is the request? What independent evidence supports it? Which control authorizes the next action?

If participants answer the third question with “the executive said so,” branch the scenario into a failed-verification path. If they pause the transaction, use a known contact method, and involve a second approver, provide a new inject that tests whether the same discipline survives public pressure.

3. Test Verification Under Pressure

Verification under pressure should be operationally clear before the tabletop begins. Publish the approved payment callback number, supplier directory, help desk escalation route, executive-assistant contact, and incident-reporting channel in the exercise rules.

Do not let participants search for a number in the suspicious email, reply to the follow-up SMS, or use a contact detail supplied during the video call. The correct number must come from an independently maintained record.

Require participants to move high-risk decisions outside the video call. A transfer, authenticator reset, privileged-access change, confidential disclosure, or cloud-consent approval should never be completed because multiple people appear to agree in one session.

Ask, “What will you do in the next five minutes?” A strong answer names a person, a system, a verification source, and a deadline. It also declines to treat the cyberattacker’s deadline as binding.

Confidentiality claims deserve their own branch. If the caller says the transaction is subject to a merger, legal privilege, or executive secrecy, ask whether confidentiality prevents verification. It should not.

Participants should preserve confidentiality by using approved internal contacts. Bypassing payment controls or isolating the decision maker defeats the purpose. If they cite a policy exception, require them to identify the policy owner and the compensating approval.

Test approval controls with conflicting signals. The apparent executive approves the request, procurement flags the supplier change, identity telemetry shows a new session, and the supplier denies the instruction.

The expected response is to stop the transaction, contain affected accounts, preserve evidence, notify the incident team, and communicate through authorized channels. The exercise succeeds when employees use these signals to slow a dangerous action. Identifying every artifact as synthetic is a secondary goal.

End with branches for correct and incorrect behavior. If the team verifies independently, release a contained cloud alert and test incident coordination. If the team approves the request or resets the authenticator, reveal the downstream account activity and require containment, notification, and recovery decisions.

Treat the participant who made the wrong call with respect. Ask which signal was persuasive, which control was unavailable, and what training, policy, or system change would make the safer action easier next time.

A multi-channel simulation program can carry these rehearsals into controlled practice through phishing simulations across email, voice, SMS, and deepfake channels.

Close by assigning owners and dates for each gap, including callback-directory maintenance, payment approvals, help desk identity checks, cloud-session response, and executive communication. That discipline turns a convincing synthetic attack into measurable behavioral change before a real cyberattacker applies the same pressure.

How Should Teams Respond in an AI Phishing Tabletop Exercise When an Employee Clicks or Submits Credentials?

Treat every employee action in an AI phishing tabletop exercise as a signal. A click is information for the response team to act on. Move through detection, reporting, triage, containment, investigation, eradication, recovery, and lessons learned in a documented sequence.

Preserve evidence before deleting messages, isolate affected identities and endpoints, and verify that no cyberattacker-created access or forwarding rule remains. A tested phishing incident response playbook gives the team a shared sequence to follow.

1. Stabilize the Opening 15 Minutes

The opening 15 minutes determine whether a suspicious message remains an isolated event or becomes an account takeover. The employee should stop interacting with the message and avoid deleting it. The employee should also disconnect a suspected endpoint if instructed by the response lead and report exactly what happened.

That report should identify whether the employee clicked a link, submitted credentials, opened an attachment, approved an MFA request, or only viewed the message. A shame-free response gives analysts better evidence and gives the employee a clear protective role.

The service desk or security operations team should open an incident record, assign an owner, and capture the message, sender, recipient, timestamps, subject, URLs, attachment names, screenshots, and the employee’s actions.

An unexpected MFA approval warrants treating the identity as compromised, even when the employee entered no password, because a push prompt usually means someone else already holds the valid password, and MFA bypass attacks often rely on exactly that approval. If the employee only reported the message, analysts should preserve it, classify the report, and search for matching messages across the organization.

The response lead should identify scope immediately. Search mailboxes for the sender, subject, URLs, attachment hashes, and message identifiers. Determine whether the lure reached finance, executives, administrators, or other high-impact roles.

Use an approved phishing response and phish triage process to coordinate classification and reversible remediation, so every analyst handles evidence the same way.

2. Preserve Evidence and Contain Identity Exposure

Containment must protect the account and the evidence needed to understand the cyberattack. Preserve complete email headers, message source, URLs, redirect chains, attachments, authentication logs, cloud audit records, mailbox forwarding rules, OAuth grants, endpoint telemetry, browser history, and relevant screenshots before remediation changes the environment.

Export records in the approved format, record collection times, and maintain access logs so the exercise can test chain of custody.

If credentials were submitted, reset the password from a known-clean device, revoke active sessions and refresh tokens, and invalidate suspicious application passwords. Review recent sign-ins and require MFA re-registration when the identity provider shows tampering.

Remove unauthorized inbox rules, delegates, forwarding addresses, and OAuth applications. If an attachment executed or a browser session downloaded content, isolate the endpoint according to the incident plan and preserve volatile evidence before reimaging it.

When an employee approved an MFA request, review push history, device registrations, conditional-access changes, and unfamiliar sessions. Changing the password does not end the investigation. Cyberattackers can retain access through tokens, consented applications, mailbox rules, or newly registered authentication methods.

CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, published in November 2021, direct organizations to preserve evidence during containment and to adjust detection controls based on what the investigation reveals.

The exercise should test AI-specific safeguards without creating a secondary data exposure. Do not upload confidential phishing emails, customer data, internal prompts, credentials, or proprietary attachments to an unapproved AI tool.

Route samples through approved sandboxing, malware-analysis, and data-loss-prevention controls. Redact sensitive content before using an authorized model, and record the prompt, model, output, and generated artifacts. These records document the analysis, but they cannot prove who produced the lure.

3. Investigate Activity, Eradicate Access, and Validate Recovery

Investigation should distinguish content generation from cyberattacker behavior. Grammar, spelling, pixel quality, and unnatural phrasing are weak indicators, because human operators, automated kits, and generative AI can all produce polished or deliberately flawed messages.

Give greater weight to sender authentication, domain registration patterns, URL infrastructure, login geography, impossible-travel signals, device identity, token use, mailbox changes, attachment behavior, and coordinated activity across email, voice, or SMS.

The deepfake incidents covered earlier point to the same control. Finance and executive teams should confirm unusual requests through a pre-established channel. A phone number or meeting link supplied by the suspicious message never qualifies. A convincing face or voice is no authentication factor, and the same rule applies to email, vishing, smishing, and video meetings.

Eradication means removing malicious messages, blocking domains and hashes, revoking unauthorized access, deleting persistence mechanisms, rebuilding compromised endpoints when necessary, and notifying affected third parties.

Recovery begins only after the team confirms clean sign-in activity, expected MFA devices, legitimate mailbox rules, normal forwarding settings, and approved application access. Run fresh endpoint scans, review cloud audit records, and monitor the identity and related accounts for delayed misuse.

NIST’s 2025 incident response guidance, SP 800-61 Revision 3, places incident response inside broader cybersecurity risk management. That approach makes recovery validation an evidence-based decision. A simple declaration that the incident is over falls short of that standard.

Record who approved restoration, which telemetry was reviewed, and which residual risks remain.

4. Convert the Exercise Into Lessons Learned

The review should turn the simulated incident into measurable behavioral change. Bring together the employee, service desk, identity team, security operations team, and business owner to reconstruct the timeline and identify reporting delays. The group should also document which controls detected the activity and separate process gaps from individual decisions.

Do not punish an employee for a scenario click or a click in a related simulation. Use the result to improve recognition, reporting speed, and verification habits.

Track time to report, time to triage, time to revoke sessions, time to remove organization-wide messages, the percentage of affected accounts identified, and recovery-validation failures. Update playbooks, escalation paths, verification contacts, and role-based training.

If the scenario involved a deepfake, vishing, or AI-generated spear phishing message, repeat the exercise through another channel. Employees then practice verifying identity when email filters provide no warning.

A successful AI phishing tabletop exercise produces a stronger response sequence, cleaner evidence, and employees who report early. The organization is ready when responders can contain the account, explain the cyberattacker’s path, and prove that normal operations resumed.

How Should Security, Legal, Finance, HR, and Executives Coordinate an AI Phishing Tabletop Exercise?

An AI phishing tabletop exercise tests departmental ownership and executive authority before a synthetic message forces a rushed decision. Operational teams establish facts and contain harm. Executives approve actions that change legal, financial, customer, or reputational exposure.

Security owns technical validation and containment, Finance owns payment controls, and Legal owns notification and privilege decisions. Executives resolve conflicts involving speed, materiality, public disclosure, and delegated authority when facts remain incomplete. Operational teams and executives both depend on preapproved escalation paths, out-of-band communication, and a shared decision record.

How Should Operational Teams Coordinate During an AI Phishing Incident?

Operational coordination must test handoffs along with individual response skills. The facilitator should inject an AI-generated email, convincing vishing call, or deepfake video that appears to come from an executive, then reveal new facts in stages.

Each function must state what it knows, what it assumes, what it needs, and who can authorize the next action.

A practical responsibility matrix should define the default owner, required inputs, mandatory approvals, and fallback action:

The matrix becomes useful only when the exercise tests disagreement. Finance should challenge a request to release funds without a verified callback, following the controls that prevent business email compromise. Security should challenge an urgent account reset based only on a familiar voice.

HR should challenge a broad employee message that identifies a suspected victim before facts are confirmed. A designated incident commander records the dispute, assigns the next fact-finding action, and sets a time for reassessment.

Use an AI phishing simulation and human-risk program to rehearse handoffs across email, voice, SMS, and deepfake video, so the exercise reaches beyond an inbox scenario.

Specify an out-of-band communication channel, such as a preregistered phone tree or emergency collaboration room, because the suspected email, executive account, or identity provider could be compromised.

How Should Executive Governance Handle Incomplete Facts?

Executive governance must distinguish a reversible precaution from an irreversible commitment. Security can quarantine messages or suspend a session, and Finance can freeze a payment, while investigators validate the incident. Executives decide when those controls create material business disruption.

The tabletop should force leaders to answer four questions:

• What reporting threshold has been crossed?
• Who can declare a major incident?
• Which decisions are delegated after hours?
• What evidence is required to lift a control?

The CISA AI Cyber Tabletop Exercise Series emphasizes information sharing, public-private engagement, and operational collaboration for incidents involving AI-enabled systems.

That governance model supports a clear rule. Teams should share verified indicators and defined uncertainties early, while executives retain authority over material disclosures, customer impact, ransom decisions, and strategic risk acceptance.

Give the CEO, CISO, General Counsel, CFO, CHRO, and board liaison different information packets. The CISO receives technical indicators and containment status. The CFO receives payment exposure and business interruption estimates. General Counsel receives jurisdictional and contractual questions. The CHRO receives employee-impact details.

The CEO and board liaison receive a decision brief that separates confirmed facts from working hypotheses. This structure prevents the loudest voice or most urgent message from becoming the organization’s de facto authority.

Board reporting should begin before the investigation is complete when the incident crosses a predefined threshold. Examples include suspected executive impersonation, material payment exposure, significant personal-data risk, prolonged business interruption, or a regulator inquiry.

The first report should state what happened, what remains unknown, what controls are active, what decision the board must support, and when the next update will arrive. A later report can correct the record without treating early uncertainty as a response failure.

How Should Teams Manage External Communication and Information Sharing?

External communication requires one accountable voice and several disciplined contributors. Legal determines disclosure obligations, Communications prepares language, and Security validates technical statements.

Finance quantifies loss, HR coordinates employee guidance, and the executive sponsor approves material public positioning. No function should publish independently while the incident remains active.

The tabletop should inject a customer inquiry, a regulator deadline, a journalist asking whether a deepfake impersonated the CEO, and a partner requesting indicators. Participants must decide what can be shared with government agencies, industry groups, international partners, affected customers, cyber insurers, and the AI provider whose service or model may be involved.

The decision should identify the purpose of sharing, the minimum necessary data, privacy restrictions, confidentiality terms, and the person authorized to send it.

When facts are incomplete, Communications should use a holding statement that confirms the investigation without speculating about cause, scope, cyberattacker identity, or financial loss. Employees should receive practical instructions through a trusted channel, including how to report follow-on vishing, smishing, or account-reset attempts.

Customers should receive verified actions and contact routes. Technical detail that could help a cyberattacker refine the campaign should stay out of those messages.

The exercise succeeds when every participant can identify the decision owner without searching for a phone number or debating authority during the incident. Document unresolved questions, test the escalation clock again after 30 minutes, and update the matrix after the exercise.

Effective coordination goes beyond holding a meeting. It is a practiced chain of decisions that keeps an AI-generated deception from becoming a financial, legal, and reputational crisis.

Which Technical and Business Controls Should an AI Phishing Tabletop Exercise Test?

An AI phishing tabletop exercise should test technical controls that block or expose a cyberattack alongside business controls that prevent a trusted employee from completing a dangerous request. Technical safeguards inspect identity, messages, sessions, and data. Business safeguards govern decisions, approvals, and recovery.

Passkeys, conditional access, DMARC, and audit logs create signals and friction before a cyberattack spreads. Vendor verification, payment approval, incident reporting, and continuity procedures determine whether the organization contains the loss after someone receives a convincing lure.

Both control families must be tested together. A technically detected phish can still cause harm when employees lack a trusted reporting route, cannot verify the request, or do not know how to keep operations running.

How Should Identity and Email Controls Be Tested?

Identity and email controls are the first place to test both prevention and detection. Begin with an attempted credential relay, a stolen session token, a compromised legitimate mailbox, and a convincing spear phishing message that follows normal email workflows.

Test whether phishing-resistant MFA and passkeys defeat the relay attempt, and whether conditional access, token binding, or continuous access evaluation blocks the replayed token. The exercise should also check whether identity proofing prevents a cyberattacker from enrolling a new authenticator after a help desk interaction.

The NIST Digital Identity Guidelines, SP 800-63-4, published in 2025, provide current requirements for identity proofing, authentication, and federation. Use those requirements to assess whether the organization’s identity controls address account recovery, authenticator enrollment, and access from unfamiliar contexts.

Email testing should cover DMARC enforcement, SPF and DKIM alignment, lookalike domains, reply-chain impersonation, QR codes, and malicious attachments.

Include obvious and high-quality messages so the team can identify false negatives, such as an AI-generated invoice request that reaches the inbox. The same set should surface false positives, such as a legitimate supplier message quarantined after its sending infrastructure changes.

The exercise succeeds only when analysts can explain why a message received its verdict and employees know how to report it through a trusted channel. Send the simulated lure to finance, an executive assistant, a remote worker, and a multilingual team member.

Measure whether each person can use a one-click phishing report button or established reporting route without forwarding sensitive content to an unsafe address.

A phishing simulations and response program should connect reports to analyst triage, user feedback, and follow-up training. A click should never be the only outcome it records.

What Should the Exercise Test Across Cloud and Third-Party Compromise?

Cloud and third-party scenarios test whether the organization can see and contain a cyberattack after prevention fails. Start with a legitimate account compromised without a stolen password, such as through a hijacked session or a malicious OAuth application a user consented to.

Ask the team to identify the event through cloud audit logs, revoke sessions, disable suspicious tokens, review mailbox forwarding rules, and determine whether the account accessed SaaS applications outside its normal role.

Introduce a vendor impersonation request as the business branch. A supplier’s mailbox appears compromised and requests a bank-account change while an apparent executive sends an urgent payment instruction.

Test dual approval, out-of-band vendor verification, callback procedures using trusted contact records, and segregation of duties. Also test the authority to pause a transaction without penalizing the employee who raises the concern.

Privileged access needs its own branch. Test just-in-time elevation, administrator MFA, break-glass account monitoring, and rapid removal of excessive permissions. The goal is to identify whether a convincing request can turn a limited compromise into persistent administrative access.

Detection tools also require disciplined evaluation. Give any AI phishing detection classifier genuine cyberattacks, benign newsletters, unusual but legitimate vendor messages, multilingual lures, and accessibility-oriented formats such as voice notes or screen-reader-friendly HTML.

Record false positives and false negatives, but keep the classifier from becoming the final authority. A human analyst must review confidence scores, message context, identity signals, business impact, and user reports before releasing, quarantining, or remediating a message.

Which Controls Matter in Specialized Environments?

Specialized environments need branches that reflect operational consequences. Generic inbox behavior tells only part of the story. In healthcare, test whether a compromised account can reach electronic health records, whether data-loss controls block unauthorized exports, and whether clinicians can report a suspicious message without losing access to urgent care systems.

In manufacturing and operational technology, test whether phishing can reach engineering workstations, remote maintenance accounts, programmable logic controller networks, or safety-related processes. Production and worker safety should remain the recovery priorities throughout.

The exercise should also test these conditions:

• Shadow AI use: An employee pastes a confidential contract into an unauthorized generative AI tool after receiving an AI-generated lure. Test browser visibility, data-loss controls, approval workflows, and the response to personal-account uploads, drawing on established shadow AI management practices.
• Data exfiltration: A compromised SaaS account downloads sensitive files and creates a new external sharing link. Test alerting, token revocation, link disabling, legal escalation, and evidence preservation.
• Ransomware: The phish leads to credential theft and encryption of shared files. Test immutable backups, restoration priorities, privileged-access isolation, communications, and the decision to invoke cyber insurance or contact law enforcement.
• Simultaneous physical emergency: A fire alarm, severe storm, plant incident, or public event distracts responders while the phishing attack unfolds. Test alternate communications, emergency approval authority, offline procedures, and staffing continuity.

Recovery must end with evidence. Reassurance alone is insufficient. The team should identify which controls stopped the cyberattack, which produced a false signal, which failed silently, and which business decision allowed exposure to continue.

CISA’s #StopRansomware guidance recommends phishing-resistant MFA for email, VPNs, and accounts that access critical systems. That recommendation makes phishing-resistant MFA a practical benchmark for the exercise.

How Can a Small Organization Run a One-Hour AI Phishing Tabletop Exercise?

An AI phishing tabletop exercise can test a small organization’s judgment without synthetic media, specialist tools, or a full-day workshop. Choose one business email compromise or executive-impersonation scenario, prepare a compact evidence pack, and run timed injects.

Record decisions and assign owners before participants leave. Keep the exercise private and focused on process quality, with individual performance left out of the scoring. The approach pairs well with phishing awareness training for small businesses.

1. Prepare the Exercise Pack

Choose a facilitator, a note-taker, and four to eight participants from finance and IT. Include the person who approves payments, the person who manages identity or email systems, and a leader who can make an escalation decision.

One scenario is enough. The CFO emails finance requesting an urgent vendor-payment change while traveling, then becomes unreachable through the usual channel.

Prepare these materials:

• Scenario card: Initial email, sender details, payment amount, deadline, and known business context
• Contact list: Finance approver, IT lead, executive assistant, bank contact, legal contact, and incident-response lead
• Approval matrix: Who can approve payment changes, credential resets, vendor updates, and external notifications
• Incident-response plan: Reporting, containment, evidence preservation, and communications steps
• Verification numbers: Trusted phone numbers and out-of-band contacts drawn from internal records, since numbers supplied in the suspicious message cannot be trusted
• Note template: Time, new information, decision, decision-maker, rationale, and follow-up owner

Remove real employee names, account numbers, and customer data. Use fictional identities and a training-only payment amount so the exercise exposes process gaps without creating operational confusion.

2. Open With a Five-Minute Briefing

Explain that the exercise is a no-fault rehearsal. Participants should respond as they would during a real incident, state assumptions aloud, and avoid contacting real vendors or executives unless the facilitator directs them. The goal is to strengthen employees’ ability to pause, verify, report, and coordinate under pressure.

Set three ground rules. The facilitator controls new information, the note-taker records decisions and leaves opinions aside, and nobody is graded on how quickly they identify the scam. This framing protects psychological safety and produces more honest evidence about where procedures fail.

For a broader training program, connect the exercise to phishing simulations across email, voice, SMS, and deepfake channels while keeping this low-cost session email-led.

3. Present the Initial Scenario

At minute five, provide the scenario card. The fictional CFO requests a $48,500 payment to a familiar vendor, says the beneficiary details changed, and asks finance to bypass the normal approval workflow because of a same-day cutoff. Give participants five minutes to explain what they would do first.

Listen for concrete actions such as checking the sender address, reviewing the approval matrix, calling a trusted number, preserving the email, notifying IT, and pausing the transaction. Do not reveal the correct response immediately. The exercise measures whether the team can apply its own controls under urgency.

4. Deliver Two or Three Timed Injects

Add one new fact every five minutes. The opening inject has the CFO send a text saying email is unreliable and asking the employee to confirm by replying. A later message from the vendor claims the payment is overdue and warns that service will stop. The closing inject has IT report a suspicious sign-in attempt on the CFO’s account.

After each inject, require the group to record its decision, owner, deadline, and escalation path. If participants ask whether the executive’s voice or video could be trusted in a follow-up call, direct them back to the rule that identity must be verified through an independent channel. Familiar faces and voices cannot stand in for that verification.

5. Close With a Hotwash and Assigned Actions

Reserve the final 10 minutes for a rapid hotwash. Ask what worked, where the team hesitated, which contact or approval rule was missing, and what action would have prevented the transfer. Capture observations without naming employees as failures.

Assign no more than three follow-up actions. Finance might update payment-verification rules, IT might confirm executive account-monitoring procedures, and leadership might approve a second-channel verification requirement. Give each action one owner and one due date.

The exercise is complete only when those decisions enter the organization’s normal risk and incident-management process. A documented verification rule is valuable only when employees can use it quickly, even as a familiar voice, text, or video adds pressure.

How Should Teams Debrief and Measure an AI Phishing Tabletop Exercise?

An AI phishing tabletop exercise pays off when the team converts discussion into documented decisions, measurable gaps, and retest dates. Run a blameless hotwash immediately, then complete a formal debrief that separates behavior from capability and control weaknesses. Assign an owner to every corrective action.

Treat the exercise as a baseline for improvement. A pass-or-fail judgment discourages candor. Employees need a safe way to surface uncertainty and report mistakes before a real incident.

1. Run an Immediate, Blameless Hotwash

Start the hotwash within 15 minutes of the scenario ending, while decisions, assumptions, and handoffs remain fresh. Ask participants what they saw, what they did, what information they lacked, and what they expected another team to do.

Avoid asking who made the mistake. Ask which signal was missed, which decision rule failed, or which approval path was unclear.

Capture observations in five categories:

• Observed behavior: What participants said or did, including whether they paused, reported, verified, escalated, preserved evidence, or approved a request.
• Assumed capability: What participants believed a person, process, tool, or vendor could do, such as tracing a spoofed voice or blocking a malicious message.
• Process gaps: Missing or ambiguous procedures, including unclear escalation thresholds, undocumented out-of-band verification, or approval workflows that conflict with urgent business requests.
• Control gaps: Failures in detection, identity verification, access restriction, logging, alerting, or message remediation.
• Unresolved questions: Facts the exercise could not establish, such as whether a finance system logs approval changes or whether a reporting channel works from a mobile device.

Record exact language when possible. “We assumed the caller was verified because the voice matched the CFO” is more actionable than “the team was too trusting.” The distinction protects employee dignity while exposing the verification rule that needs reinforcement.

Complete a formal debrief within five business days. Assign one owner to each finding, define the risk of leaving it open, and specify the evidence required for closure.

NIST Special Publication 800-61 Revision 3 recommends that organizations document incident response and recovery actions and lessons learned in an after-action report. Apply the same discipline to a simulated AI phishing event.

2. Measure Decision Quality and Response Time

Quantitative measurement turns a compelling conversation into an improvement program. Record timestamps for the first recognition of suspicious activity, first report, escalation to the appropriate owner, independent verification, containment, evidence preservation, stakeholder notification, and restoration of trusted operations.

Measure from the moment each participant receives the inject. The facilitator’s announcement that the scenario has become serious is the wrong starting point.

Time alone is insufficient, since a fast decision that bypasses approval controls is a weak outcome. Score whether the team verified the request through an independently sourced channel and followed the required approval workflow.

The score should also reflect whether the team communicated accurate facts without overstating certainty, preserved artifacts for investigation, and distinguished confirmed evidence from assumptions. The principles used to measure a phishing simulation program apply here as well.

Use the exercise results as a baseline and set a retest date for every target. A human risk program can connect these results with reporting and risk dashboards to show whether behavior improves across departments, roles, and later simulations. The scorecard below provides a practical starting structure.

Measure decision quality separately from employee knowledge. An employee who recognizes an AI-generated voice but cannot locate the reporting channel knows the concept but cannot act on it.

An employee who pauses a suspicious request, verifies it independently, and reports uncertainty demonstrates the behavior the organization needs, even without explaining how voice cloning works. A human risk scoring model can track that behavior over time.

3. Convert Findings Into Board-Ready Reporting

A board report should show exposure, business consequence, remediation status, and trend. A transcript of the exercise does not serve directors. Present three layers: what happened, why it happened, and what management will change before the retest.

Highlight decisions involving payments, privileged access, sensitive data, customer communications, and operational downtime, because those outcomes translate human-layer risk into enterprise risk.

Use a small set of comparable indicators, including median time to report, the percentage of high-risk requests independently verified, approval workflow adherence, evidence preservation, communication accuracy, and open high-severity actions past due.

Include the exercise date, scenario assumptions, participating functions, baseline, target, owner, and retest date so directors can distinguish an identified gap from an unmanaged gap.

Close with decisions requiring executive support, such as funding an out-of-band verification process, changing payment controls, updating incident response authority, or scheduling a cross-functional retest.

Directors should leave knowing whether the organization can recognize an AI phishing attempt, challenge it without fear, contain the exposure, and restore trusted operations under pressure. Those judgments become meaningful only when the retest shows whether corrective actions changed behavior.

How Should an AI Phishing Tabletop Exercise Turn Lessons Into Changes to Plans, Training, and Controls?

An AI phishing tabletop exercise improves security only when a failed decision becomes an assigned correction, since a paragraph buried in an after-action report changes nothing. Federal tabletop exercise guidance frames exercises as preparation for real-world response. Every weakness therefore needs an owner, deadline, evidence requirement, and retest condition before the exercise closes.

A mistake is a training signal. Blaming employees for it only encourages them to conceal uncertainty.

How Should Exercise Findings Become a Remediation Register?

Create a remediation register that records the decision, expected behavior, observed gap, business consequence, and corrective action. Vague entries such as “improve phishing awareness” leave nothing to verify.

A useful entry reads: “Finance could not independently verify a voice request to change vendor payment details, so the payment procedure must require callback verification using a pre-approved number.”

Assign each item a risk rating based on potential loss, exposure, decision speed, and control dependency. A request to wire funds, disclose regulated data, or grant privileged access belongs in the highest category, because one unchecked decision can create material financial, legal, or operational damage.

Lower-rated findings still need owners when they reveal repeated confusion, unclear reporting channels, or weak documentation.

The register should contain:

• Finding and consequence: What happened, why it mattered, and which attack path it exposed.
• Owner and deadline: One accountable business owner, one security partner, and a completion date.
• Required evidence: A revised playbook, approved payment procedure, control configuration, completed training record, or retest result.
• Acceptance criteria: The observable condition that proves closure, such as two-person approval for vendor changes or a report reaching the security queue within 10 minutes.
• Residual risk: What remains exposed after the correction and who formally accepts it.

This structure prevents security teams from treating completion as closure. A policy uploaded to a document repository cannot show that employees can apply it under pressure.

Which Plans and Controls Should Change First?

Update the incident response playbook when the exercise exposes uncertainty about who declares an incident, preserves evidence, or contacts law enforcement, regulators, insurers, vendors, and affected customers.

Add decision points for AI-generated email, vishing, smishing, deepfake video, and BEC. Include instructions to preserve call recordings, message headers, meeting invitations, payment instructions, and identity-verification artifacts. The spear phishing incident response playbook offers a useful model for these steps.

Payment and vendor procedures require equally concrete changes. Require independent verification for new payment destinations, urgent invoice changes, executive requests, and unusual procurement instructions.

The verification method should use contact details already stored in the vendor record. A number supplied in the suspicious message is unreliable by design. The verification procedure should define sufficient evidence, when a second channel is mandatory, and who can approve an exception.

Email and cloud controls should reinforce employee behavior and support the judgment employees exercise. Review external sender warnings, mailbox forwarding rules, privileged-access workflows, conditional access policies, and controls for new OAuth applications.

If employees did not know where to report a suspicious message, simplify the reporting path and make its destination visible in email, mobile, collaboration, and voice workflows. A clearly labeled phishing simulation program can test whether the revised reporting behavior works across channels.

How Should Training Reflect the Failed Decision?

Training must mirror the decision that failed. The topic label attached to it matters far less. If an accounts-payable employee trusted a familiar voice, assign a vishing scenario involving payment fraud.

If an executive assistant accepted a last-minute calendar change, rehearse identity verification through a second channel. If a developer pasted sensitive information into an unapproved AI tool, train data-handling decisions in that exact workflow.

Separate role-based security awareness training from general phishing awareness. Finance needs vendor impersonation and payment verification. Executives need protocols for urgent requests made through voice, video, and messaging apps.

Legal and privacy teams need escalation triggers and evidence-preservation steps. Managers need to reinforce reporting without penalizing employees who pause an uncertain request.

Training records should show the scenario, audience, behavior tested, completion date, and follow-up result. Completion alone falls short as an acceptance criterion. The organization should demonstrate that employees can identify the signal, stop the risky action, verify the request, and report it through the correct channel.

How Should Teams Retest Without Hiding Errors?

Retest the failed decision under a different channel or context within the remediation period. An employee who failed an email-based vendor-change scenario might receive a phone request, SMS message, or deepfake meeting invitation using a different pretext.

Surprising or punishing the employee is beside the point. The retest determines whether the underlying behavior has shifted from trusting a familiar request to pausing, verifying independently, and reporting.

Use the same acceptance criteria across the retest. Record whether the employee challenged the request, used the approved verification method, avoided sharing information, and reported the event. If the employee makes another mistake, preserve the result as evidence that the control or training needs refinement.

NIST’s incident handling guidance also emphasizes sharing lessons learned as soon as they are identified, well before recovery concludes. Close the finding only when the owner can show the revised plan, procedure, control, or training in operation and the retest demonstrates the required behavior.

That discipline turns an AI phishing tabletop exercise into a measurable improvement cycle. Every future exercise then starts from a stronger position, free of the same unresolved exposure.

How Often Should Organizations Run AI Phishing Tabletop Exercises?

Organizations should schedule an AI phishing tabletop exercise according to human risk, business change, and threat exposure. An annual calendar alone is too blunt. Customizable federal tabletop packages show why scenarios and discussion questions must reflect an organization’s operating environment.

Annual exercises establish a baseline, but high-risk teams need shorter, targeted rehearsals between enterprise events.

How Should Exercise Frequency Change With Risk?

A risk-based cadence starts with one enterprise-wide AI phishing tabletop exercise every 12 months. Include security, IT, legal, communications, finance, HR, and business leaders so the organization can test decisions from the first suspicious message through customer notification and recovery.

The scenario should follow a realistic chain, such as an AI-generated spear phishing email followed by vishing from a supposed executive and a request to change payment instructions.

High-risk organizations should add focused drills every quarter. Finance teams can rehearse vendor compromise and BEC, while identity and cloud teams can work through stolen credentials, unauthorized OAuth consent, and cloud-account takeover.

Executives should complete a deepfake exercise at least annually, especially when leaders approve payments, disclose sensitive information, or communicate through public video and audio channels.

A practical cadence includes:

• Enterprise exercise: Once a year, with cross-functional leadership and a full AI phishing incident scenario.
• Focused team drill: Quarterly for finance, IT, security operations, executive assistants, and other high-exposure roles.
• Executive deepfake exercise: Annually, with an additional session after leadership changes or a public-facing event.
• Vendor-compromise scenario: Every six to 12 months for procurement, accounts payable, and business owners who approve suppliers.
• Cloud-account scenario: Every six to 12 months for identity, infrastructure, and application administrators.
• One-hour refresh: Monthly or quarterly for teams with recent failures, elevated risk signals, or frequent exposure to external requests.

Shorter exercises carry their own value alongside the annual event. They isolate one decision point, such as whether an employee verifies a voice request through a trusted channel, reports an AI-generated email, or pauses a payment until a second approver confirms the change. That focused practice turns policy into a usable response under pressure.

Which Business Changes Should Trigger an Exercise?

Major changes should trigger an AI phishing tabletop exercise before the new process becomes routine. Run a focused scenario after an acquisition, major system migration, new payment workflow, executive transition, material incident, or regulatory change that alters reporting and response obligations.

New AI use also warrants a drill. Employees might disclose confidential data to an approved or unapproved AI tool, creating another social engineering path.

Control remediation is another clear trigger. If an investigation finds that employees bypassed callback verification, ignored the phishing report button, or lacked a reliable owner for vendor-bank changes, retest that exact weakness after remediation.

An updated policy is no reason to close the issue. Confirm that the right people make the right decision when the request arrives.

Real incidents should shorten the timetable immediately. The Arup transfer and the Cardin impersonation, both from 2024, show why organizations must rehearse trusted-identity failures across voice and video as well as email.

After a comparable event, run a one-hour leadership refresh within 30 days. Schedule a deeper role-based exercise once corrective actions are defined.

In 2024, the federal AI tabletop series examined information sharing, response procedures, and organizational resilience during AI-related incidents. Organizations should apply the same logic internally by testing who decides, who communicates, and who verifies.

How Does Tabletop Practice Fit Into Security Awareness Training?

Tabletops work best as the decision-making layer of a broader security awareness training program. Role-based training teaches the relevant behavior, and phishing simulations test whether employees recognize the lure. Tabletop exercises then test whether teams coordinate after someone reports it.

Use simulation and reporting data to set the exercise agenda. A rise in clicks on vendor impersonation emails should lead to a procurement drill. Slow reporting of vishing attempts should prompt a voice-verification refresh.

Increased executive exposure in open-source intelligence should lead to a deepfake scenario involving assistants, finance staff, and communications teams alongside the executive. Deepfake awareness training scenarios can supply realistic starting points.

Close every exercise with three outputs: an assigned control owner, a remediation deadline, and a trend for leadership reporting. Board updates should show whether reporting speed improved, which roles remain exposed, and whether repeat exercises closed identified gaps.

That evidence turns recurring practice from an annual compliance event into a measurable human risk management program, where every business change becomes a chance to strengthen judgment under pressure.

How Should Organizations Govern AI Phishing Tabletop Exercise Data?

An AI phishing tabletop exercise should be governed as a controlled processing activity, with written consent, defined access, retention limits, and legal review before synthetic media or participant data is created.

NIST’s 2024 Generative AI Profile places privacy, security, and accountability inside AI risk management, so realistic simulations require more than technical accuracy. The exercise should build employee judgment without turning a training artifact into a permanent personnel record or production investigation.

What Must Be Approved Before the Exercise?

Realism starts with approved source material. Unrestricted data collection undermines that foundation. Obtain written consent before using an executive’s likeness, voice, video, biography, or publicly available recordings to create a synthetic persona.

The consent should identify the scenario, channels, audience, duration, storage location, permitted vendors, withdrawal process, and whether the material can be reused.

Do not clone a person who has not authorized the use, even when the source material is publicly available. For most scenarios, synthetic identities work better. A fictional CFO, vendor, recruiter, or legal adviser can create the same decision pressure without exposing a real employee’s personal information.

If a real executive persona is necessary, limit source material to approved recordings and photographs, remove unnecessary metadata, and prohibit prompts that generate unrelated statements or sensitive opinions. Treat prompts, voice models, video files, scripts, contact lists, and scenario logs as restricted exercise data.

Assign named owners, use role-based access, require strong authentication, prohibit copying into consumer AI tools, and log downloads and administrative changes. Legal, privacy, human resources, communications, and security teams should approve the scenario before launch.

Review employment, biometric privacy, data protection, intellectual property, accessibility, and labor requirements that apply in each relevant location.

A practical pre-exercise approval checklist should confirm:

1. 1Written likeness and voice consent is recorded, or a synthetic identity is used.
2. 2Source material, prompts, channels, target groups, and escalation contacts are approved.
3. 3Access permissions, vendor terms, encryption, logging, and participant notices are documented.
4. 4The retention deadline, destruction method, accessibility accommodation, and legal hold process are assigned.
5. 5The exercise owner has separated simulation artifacts from production evidence and briefed facilitators on participant safety.

How Should Organizations Protect Participants and Findings?

Participant privacy determines whether employees treat the exercise as skill-building or surveillance. Tell participants what is being tested, what data will be collected, who can see individual results, how long records will remain, and how to request an accommodation.

Provide captions, transcripts, screen-reader-compatible materials, readable contrast, and a non-voice alternative for participants who cannot use audio or video.

Individual participation should remain confidential when the purpose is education, preparedness, or program measurement. Report organizational findings in aggregate by department, role, channel, or scenario.

Avoid publishing names, rankings, screenshots of mistakes, or raw message content. Managers should receive coaching signals only when they need them to support a documented improvement plan.

Confidentiality has limits. Escalate immediately when an exercise reveals a real credential disclosure, an actual transfer of funds, suspected data exposure, harassment, discrimination, unsafe distress, or a compliance concern. Preserve the minimum relevant evidence, stop the scenario, notify the incident owner, and follow production incident and legal-hold procedures.

Authentic evidence must stay intact even when it surfaces during a simulation. A clear escalation boundary protects employees while preserving the evidence investigators need to assess genuine risk.

How Should Exercise Data Be Destroyed?

Separate exercise artifacts from production evidence at collection. Use distinct storage, labels, access groups, and case identifiers so a synthetic email or deepfake video cannot be mistaken for an authentic incident during an investigation.

Retain only what is necessary to demonstrate participation, measure behavior change, or satisfy an approved audit requirement.

At the end of the retention period, destroy cloned voices, likeness files, prompts, generated media, raw participant responses, contact exports, and temporary working copies. Record the destruction date, data categories, storage locations, deletion method, responsible approver, and any items preserved under legal hold.

The post-exercise destruction record should state that access tokens were revoked, vendor copies were deleted or returned, backups were addressed under the applicable schedule, and no synthetic artifact entered a production evidence repository.

Organizations can use multi-channel phishing simulations safely when governance is designed before realism. That order creates room for harder scenarios while keeping synthetic media within its controlled purpose.

AI Phishing Tabletop Exercise FAQs

What Is the Purpose of an AI Phishing Tabletop Exercise?

An AI phishing tabletop exercise is a facilitated, discussion-based rehearsal of how people and processes respond to an AI-enabled phishing incident. The scenario can include spear phishing, business email compromise (BEC), vishing, smishing, deepfake audio or video, credential theft, and account takeover.

Participants make decisions about verification, escalation, payment approval, evidence preservation, communications, and recovery without conducting a live attack. The National Cyber Security Centre’s tabletop exercise guidance describes tabletop exercises as group discussions built to identify responses to an unfolding cyber incident.

The exercise aims to improve decisions under pressure. It is not about punishing employees or tracking who clicks.

How Is an AI Phishing Tabletop Exercise Different From a Phishing Simulation?

An AI phishing tabletop exercise tests coordinated decisions through discussion, while a phishing simulation measures how people respond to a controlled message in a live environment.

A tabletop can examine executive impersonation, payment authorization, legal escalation, media communications, cloud-account containment, and deepfake verification without sending deceptive content to employees. A simulation typically records actions such as opening a link, submitting credentials, or reporting a message.

UK government exercise guidance frames tabletop work as a group response to an unfolding incident. Organizations benefit from both formats. Tabletop findings expose process gaps, while simulations reveal reporting and verification behavior in context.

How Often Should a Company Run an AI Phishing Tabletop Exercise?

A company should run an AI phishing tabletop exercise on a risk-based cadence, with a full exercise at least annually and focused drills after material changes or incidents. An exercise is due when payment workflows, identity systems, cloud platforms, suppliers, executive roles, regulations, or approved AI use change.

Short refreshers help finance, help desk, executives, and incident responders when a remediation item needs retesting. A single annual discussion cannot validate readiness across email, voice, SMS, and deepfake cyberthreats.

Set a retest date for every finding, assign an owner, and repeat the failed decision in a different channel or context to measure durable improvement.

What Should an AI Phishing Tabletop Exercise Test?

An AI phishing tabletop exercise should test recognition, independent verification, reporting, escalation, authorization, containment, evidence preservation, communication, and recovery. Give participants a realistic path from a suspicious email to a voice request, SMS follow-up, deepfake executive message, compromised supplier account, or cloud-account alert.

Measure whether teams verify payment changes through trusted contact details, challenge secrecy and urgency, preserve headers and logs, disable compromised access, and notify the right stakeholders.

CISA’s AI Cyber Tabletop Exercise Series emphasizes collaboration and information sharing around AI-related incidents. Record decisions, owners, evidence, response times, and unresolved dependencies.

Can a Small Business Run a One-Hour AI Phishing Tabletop Exercise?

A small business can run a one-hour AI phishing tabletop exercise with one focused scenario, a short participant list, and three timed injects. Use a five-minute briefing, a suspicious executive or supplier email, a payment or credential request, and a follow-up voice or SMS message.

Include the people responsible for finance, IT or managed services, operations, and executive approval. Capture the verification number, reporting route, containment authority, customer communication decision, and one remediation owner. The resulting action list gives employee readiness a practical baseline for continuous testing.

See How Adaptive Security Builds Readiness Across Every Phishing Channel

AI-enabled phishing puts employees under pressure across email, voice, SMS, and deepfake channels. Adaptive Security gives teams a way to continuously test readiness and turn AI phishing tabletop exercise findings into targeted improvement. Evaluate Adaptive’s human-layer readiness capabilities to see how the platform supports the organization.