Assessment guide

How to run a vishing assessment: a step-by-step guide for MSSPs and pentesters

Run a vishing assessment in ten steps: get written authorization, set rules of engagement, research public information, choose pretexts, build the target list, pilot, run the campaign, handle the evidence, score and report, then debrief and retest. The same workflow applies whether people or an AI voice agent make the calls. Each step is covered below.

By . Published . Last updated .

Key takeaways

  • Agree scope, rules of engagement and recording rules in writing before anyone dials.
  • Tie each pretext to a measurable objective, and write down what counts as a failure before the first call.
  • Pilot with friendly targets, and log every attempt, including calls that were never answered.
  • Score four things per call: what was disclosed, verification attempts, response to pressure and reporting.
  • Report on process, not blame, then train and retest to show the program works.

Phone-based social engineering is a standard part of a full-scope engagement, but it is also the part most often skipped, because live calls are slow to run and hard to repeat. The workflow below is written for client assessments.

Step 1: What should you agree in writing before any call?

Agree in writing what is being tested before anyone dials. Record who signed, which departments and numbers are in scope, the dates and times calls may be placed, and who at the client is the emergency contact if a call goes wrong. Settle the recording question for every state involved at the same time. The legal checklist covers what to settle, and it is general information, not legal advice, so have counsel review your engagement letter.

Two standards help here. NIST SP 800-115 includes a rules of engagement template in Appendix B. The PTES pre-engagement guide treats scope and rules of engagement as separate things, calls the signed permission to test one of the most important documents to obtain, and says social engineering pretexts must be approved in writing before testing begins.

Step 2: Set rules of engagement

Decide what the caller may and may not ask for. Typical rules:

  • The caller may ask for a password, an MFA code, an employee ID or for the target to visit a URL. Decide which of these are in play, and agree that nothing real is used after the call. If a target reads out a live credential, the client rotates it.
  • No threats, no references to real emergencies and no impersonation of real named people unless the client has agreed to it.
  • A stop rule: if a target is upset or the call reveals something dangerous, the caller ends the call and the client contact is told.
  • Financial institutions: design the scenario so the caller never collects real customer data.

Step 3: Gather public information

Real attackers research targets first, and a realistic test does too. Use only public sources: the company website, job postings, press releases and professional networking profiles. Look for names, titles, reporting lines, vendor names and internal terms that make a pretext believable. Keep notes on what you found and where, because the report should show the client how much an outsider can learn without any hacking.

Step 4: Which pretexts should you test?

Pick one to three scenarios and tie each to a measurable objective. Three that work well:

  1. IT help desk, password reset. The caller reports a lockout and asks for a reset or a credential. Objective: does the target verify the caller before acting?
  2. HR or payroll. The caller needs to confirm an employee ID or bank details to fix a payroll problem. Objective: does the target give out personal data?
  3. Vendor or executive request. The caller pushes urgency to skip a normal process. Objective: does the target follow the process under pressure?

The help desk pretext is not hypothetical. A CISA and FBI advisory on Scattered Spider reports actors posing as IT or help desk staff by phone to get passwords reset and MFA tokens transferred. Write down what counts as a failure for each one before the first call. Then you are scoring behavior against a rule, not forming an impression afterward.

Step 5: Build and clean the target list

You need a name, a title, a department and a phone number for each target. Prefer business lines. Group targets by department so you can compare groups. Remove anyone the client has excluded, and check that every number belongs to someone on the authorized list. In vishin.ai you import this as a CSV and targets are grouped by department automatically.

Step 6: Run a pilot

Call a handful of friendly targets, such as the client contact and a few volunteers, before the full run. A pilot catches a script that sounds wrong, a number that rings the wrong desk and a pretext that falls flat. With an AI caller you can adjust the scenario and retry within the same day.

Step 7: Run the campaign

Spread calls across the agreed hours and keep a log of each attempt. Note the outcome of every call, including the ones that go to voicemail or are never answered, because the report needs to separate "refused" from "never reached". In vishin.ai a campaign needs legal signoff before it can launch, and each call produces a recording and a transcript, so the log builds itself.

Step 8: How should you handle recordings and evidence?

Recordings and transcripts contain personal information and sometimes real credentials. Limit access to the assessment team, keep them in one place and set a retention period with the client. Do not paste real credentials into the report. Redact them and say they were redacted.

Step 9: What should a vishing assessment report include?

For each call record four things: what was disclosed, whether the target tried to verify the caller, how the target responded to pressure and whether anyone reported the call. Roll the results up by department. A useful report has:

  • An executive summary with pass rates by pretext and by department
  • Two or three short transcript excerpts, redacted, showing what good and bad calls looked like
  • What an outsider learned from public sources
  • Specific fixes, such as a callback rule for password resets or a change to how the help desk verifies callers

Frame results around process, not blame. NIST SP 800-115 says social engineering tests should improve the security of the organization and not single out individuals, and that the final report should identify both successful and unsuccessful tactics. Individual names do not belong in a report that goes to a wide audience.

Step 10: Debrief, train and retest

Tell employees afterward what happened and why, and give them the specific red flags they missed: unsolicited calls that ask for credentials, pressure to skip verification, a caller who cannot be verified through a known channel. Then run the same scenarios again after training. A change between the two runs is the evidence that the program works.

Why pay-per-call suits consultants

Seat licenses are priced around one organization's headcount. A consultant runs a different campaign for each client, in bursts. vishin.ai charges 5 tokens per call, with tokens starting at $1 and packs from $10, so you can price each engagement by the number of calls and carry unused tokens to the next one, because they do not expire. There are no limits on campaigns, targets, users or scenarios. See the pricing page.

Sources