Vishing simulation by AI role play: building a scenario

A vishing simulation using AI role play means having the employee talk to an attacker persona, played by an AI, who raises the pressure in stages. To build one, the trainer defines a persona, a sequence of levers, a few trap details and a list of debrief criteria. Here is the method, step by step.

The aim is not to trap employees, but to get them to say out loud the phrases that stop an attack. For the general framework, see our guide to cybersecurity awareness and vishing.

Why use role play rather than a module?

A module explains what vishing is. It does not put the employee in front of someone who keeps pushing. Yet vishing plays out in the relationship: a pleasant voice, an urgency, an authority growing impatient.

Role play recreates this tension in a safe setting. The learner speaks, the other party reacts, and the debrief shows what was said. They can then start again.

Step 1: choose a real case and a job

Start from an incident you have experienced, a report, or a scenario your security team fears. One job and one request per scenario. For example: an advisor being asked for a code, a help desk asked for a password reset, or an accountant told of a change of bank account details.

The closer the case is to everyday work, the more the learner recognizes the situation. Avoid spectacular scenarios and favor ordinary requests, because those are the ones that get through.

Step 2: write the attacker persona

The persona is a profile, not a script. It describes who they claim to be, what they want to obtain and how they speak.

• Stated identity: “Mark, from your bank's security team”, “Julie, from IT support”.
• Real goal: obtain a code received by text, access, a transfer, information about a third party.
• Tone: courteous at first, increasingly pressing, never a caricature.
• Knowledge: what they already know (the employee's name, a supplier's name) and what they do not.

A credible persona is worth more than an aggressive one. Real attackers stay pleasant as long as they are getting what they want.

Step 3: program levers that build up

The scenario is more useful when the pressure rises in stages, as in a real call. Each stage activates a psychological lever: urgency, authority, guilt, reciprocity, the small ask, isolation. Our article on the levers of social engineering details them.

Example of an escalation for a fake bank advisor:

1. Building trust: “Hello, I'm calling about an unusual transaction on your account.”
2. Urgency: “We need to act within ten minutes, otherwise the transfer goes through.”
3. Authority: “I'm head of the fraud unit, here is my employee ID.”
4. The small ask: “All I need is the code you're about to receive, nothing else.”
5. Guilt: “If you refuse, you'll be the one responsible for the loss.”

The persona only moves to the next stage if the learner has not refused. If they verify properly, the persona changes tactics or gives up.

Step 4: seed trap details

A trap detail is a detail that should raise an alarm. The trainer places three or four in the scenario, without pointing them out.

• A case number that does not exist or matches nothing.
• A colleague's first name that is correct, but a department name that is wrong.
• A call-back number supplied by the caller, different from the official number.
• A request for a one-time code presented as “a simple formality”.

The learner must spot them and use them: ask for the case number, compare, offer to call back. These details then serve as the basis for the debrief. For the list of questions that prove something, see how to verify a caller's identity.

Step 5: define observable debrief criteria

A useful criterion can be checked in the transcript: it is true or false, without interpretation. The debrief relies on wordings such as:

• “Asked for a case number.”
• “Offered to call back on the official number.”
• “Gave no code.”
• “Did not confirm any personal information before verifying the caller.”
• “Noted the name, department and number given.”
• “Reported the call to the right person at the end of the exchange.”

With Face Up, the trainer writes these criteria in their own scenario, helped by a design assistant. After the session, the learner receives a debrief: objectives met or not, strengths, points to improve, an action plan and quotes of what they said. They can play again.

Step 6: plan the trainer-led report-back

A real call does not end when the line goes dead. You have to report on it: who called, what was asked, what was said. The report-back is therefore an exercise in its own right, which the trainer leads after the session, in a small group or in pairs.

Each participant tells the story of their call as if reporting it to the security team: name given, department, number, requests, levers spotted, what they gave or refused. The trainer follows up with the checklist for reporting a security incident and corrects any omissions.

This exercise is a training activity, not a feature of the tool. It turns the lived experience into a reporting habit, which is often the weakest link.

Common mistakes to avoid

• A persona that is too aggressive. The learner defends themselves instead of verifying, and the scenario no longer resembles a real call.
• Too many traps. Beyond four trap details, the debrief becomes unreadable.
• Vague criteria. “Was cautious” cannot be checked. “Offered to call back” can.
• A one-off exercise. A reflex is anchored by repetition. Plan several scenarios spread across the year.
• An implicit sanction. State clearly that the exercise does not count toward individual performance review.

Example: an extract of a good answer to a fake security team

Imagine a call to an advisor. The persona introduces themselves as “Mark, from the fraud unit” and asks for a code received by text to “cancel a fraudulent transfer”. Here is what a learner who gets through the stages might say:

“I never give out a code over the phone, whatever the reason. Give me your name, your department and the case number. I'm hanging up and I'll call you back on the department's official number.”

This answer does not justify itself, accuses no one and gives no hold to the next lever. It contains three observable criteria: asking for the case number, offering a call-back, giving no code. That is exactly what the debrief should be able to quote.

If the learner gives in at the guilt stage, the debrief can quote their sentence and suggest an alternative. The gap between what they said and what they could have said is the heart of the learning. To hold a refusal when the caller insists, see phrases for saying no under pressure on the phone.

A checklist to review your scenario before offering it

Before launching the exercise, run your scenario through these questions. Each one should get a “yes”.

1. Does the persona pursue a single, clear goal that can be described in one sentence?
2. Do the levers rise in stages, with a way out at each stage if the learner verifies?
3. Are three or four trap details present, without being pointed out?
4. Can each debrief criterion be checked in the transcript, without interpretation?
5. Does the situation match a call that this job really receives?
6. Is the trainer-led report-back planned, with the reporting checklist?

Have a colleague test the scenario before offering it to the team. A dry run quickly reveals a trap that is too obvious or an ambiguous criterion. Adjust, then roll out, and revisit the scenario when a new method appears in the reports.

Frequently asked questions

Should employees be told they will be talking to an AI?

Yes. The exercise is announced, framed and debriefed. It is not a surprise call on their phone, but a practice scenario in which they know they are training.

How long does a scenario last?

A few minutes are enough for a complete call, followed by the debrief and a possible second attempt. Short, frequent scenarios are better than one long annual session.

How do you measure progress?

Compare the criteria met from one session to the next, for example the proportion of employees who offer a call-back. Our article on measuring the effectiveness of awareness training suggests indicators.

How does this relate to phishing campaigns?

The two complement each other: the campaign measures the click, the role play trains the conversation. See the limits of phishing simulation when it comes to voice.

To build your first vishing scenario with your own cases, book a Face Up demo.