Run a Social-Engineering Tabletop That Tests the Process, Not the Person

Put five people around a table and ask what happens when an employee reports approving access to the wrong application. The answer may sound straightforward until someone asks who can revoke the grant, where the report goes after hours, and whether the business owner knows which data the application could reach. That is where a useful exercise begins.

A tabletop is a structured discussion of a hypothetical incident. It can expose missing decisions without deceiving employees, collecting real credentials, or interrupting production systems. The purpose is not to find the least security-aware person in the room. It is to learn whether the organization can move from uncertainty to an authorized response.

Before the room fills up

Choose one workflow the participants actually use. A small team might select unexpected document sharing, supplier payment changes, or a suspicious support request. Do not combine every threat into one dramatic scenario. A narrow exercise makes it easier to identify a concrete gap and assign a realistic repair.

The NCSC offers an identifying and reporting phishing exercise intended for a small facilitated group. CISA also publishes tabletop exercise resources. The workshop below is our original discussion format, not a reproduction of either agency’s exercise or an official certification.

Invite the roles needed to explain the workflow: a person who receives the request, a business owner, an administrator or responder, and someone who can authorize a disruptive decision. One person can facilitate and another can take notes. In a small organization participants may hold several roles, but record which role is speaking.

The scenario card

Fictional starting point: an employee is working with an external project partner. A message asks them to open a shared document through a new application. The employee approves a permission prompt, then notices that the requested access seems broader than the task. They report the concern before knowing whether the message was malicious.

Do not add hidden attacker facts at the start. Participants should work with the information a real reporter could provide: the time, the application name or identifier if visible, the account used, and the action taken. The facilitator can answer questions from a prepared scenario sheet or mark them as unknown.

Explain that uncertainty is intentional. The team does not need to decide immediately that data was stolen. It needs to identify the appropriate owner, preserve useful evidence, assess access, and choose proportionate next steps. A good exercise rewards clear questions as much as decisive answers.

Round one: can the report reach a person?

Ask the employee role to describe the real reporting route. Where do they click, call, or send the message? Is that route available on the device they are using? What happens if they are outside normal hours? Who receives the report, and how does the employee know it was received?

Do not accept “IT will handle it” as a complete answer. Ask which queue or person that means. If the route exists only in a document nobody can find, record that as a discovery problem. If the mailbox is monitored but no one can act, record the distinction between receiving and responding.

Then ask what the reporter should do while waiting. The answer should avoid both continuing the suspicious task and taking improvised destructive action. A concise acknowledgment can say that the report is being assessed and identify the approved support route for additional information.

Round two: what exactly needs containment?

Give the responder role a limited update: the application appears in the account’s connected services, but the team has not established what it accessed. Ask what evidence would distinguish an unwanted grant from confirmed data access. Which authorized person can inspect the relevant platform information?

The discussion should separate account credentials, sessions, application permissions, and resources. A password reset may be one action, but it should not be used as a generic answer to every access question. Our analysis of recovery beyond a password change provides background for this distinction.

Ask who can approve containment if it interrupts legitimate work. Can a responder revoke an obviously unwanted grant under an existing policy, or must a business owner approve? If the owner is unavailable, what authority does the deputy have? Record the actual decision boundary rather than inventing one to finish the exercise.

Capture decisions in a compact worksheet

The worksheet should contain short facts, not a transcript of everyone’s comments. Mark an unknown as unknown. An unanswered question is an exercise result, not a failure by the person who asked it. The record becomes useful when it shows who will resolve the uncertainty afterward.

Round three: the original contact replies

Introduce a new message from the supposed project partner saying the application is legitimate and the deadline is urgent. Do not tell participants whether the sender is genuine. Ask how the team would verify the business purpose without relying only on the same thread that introduced the application.

This tests a different boundary from technical revocation. A real partner can still request an inappropriate scope, and a compromised contact can use accurate project details. The business owner needs a known route and a clear requirement for the tool. The administrator needs to compare that requirement with the permission model.

Our discussion of the social difficulty of verification can help frame the conversation. Ask participants for language they would actually use to hold the request. A process that works only when someone is unusually assertive is not reliably available to everyone.

Round four: communicate without overclaiming

Ask someone to draft a three-sentence internal update. It should state what is confirmed, what action has been taken, and what recipients should do. Do not claim a breach or data theft solely because an unwanted permission was approved. Equally, do not say “all safe” simply because one access route was removed.

Consider who needs the update. The whole organization may not need the reporter’s name or screenshots of the account. Affected users may need the application identity and a reporting instruction. Leaders may need an operational impact summary. Different audiences need different information, not increasingly detailed copies of the same message.

Keep legal and regulatory notification decisions with the appropriate owners. The exercise can identify that a decision is needed without inventing a universal deadline or asking an unqualified participant to interpret every applicable law.

Debrief with evidence, not scores

Ask what worked, where the group had to improvise, and which information was unavailable. A useful observation might be that the reporting route was easy to find but nobody knew the backup approver. Another might be that the team could identify a grant but lacked a shared understanding of when to revoke it.

Do not grade individuals on how quickly they guessed the facilitator’s intended answer. A discussion exercise is not a controlled experiment or a reliable measure of real-world attack success. It can reveal process gaps, but it cannot establish a precise reduction in future incidents.

Separate urgent repairs from longer-term improvements. Fixing an outdated contact is different from redesigning application governance. Give each action an owner, a due date, and a way to verify completion. “More awareness” is not a sufficiently specific action unless the missing knowledge and target audience are clearly identified.

The follow-up is part of the exercise

Keep a simple distinction between an action assigned and an action verified. A new procedure uploaded to a shared folder is not yet evidence that staff can find or use it. Ask the action owner to provide the agreed completion evidence, then record any remaining limitation. This prevents the debrief from becoming a list of reassuring promises that disappears after the meeting.

Return to one unresolved decision after the repair. If the reporting instructions were revised, ask a different employee to find the route. If a deputy was appointed, confirm that the deputy has the required authority and access. If a platform setting changed, use an authorized non-production test where appropriate.

Keep the scenario available for future onboarding, but vary the workflow as the organization changes. Repeating a memorized story can produce confident answers without testing new dependencies. The useful question is whether today’s team can handle today’s decision, not whether it remembers last year’s script.

A successful tabletop ends with fewer unresolved ownership questions and a small set of verified improvements. It does not need a dramatic attacker reveal. The most valuable moment may be the quiet discovery that everyone assumed someone else could make the decision that would matter in a real incident.