Tabletop Exercises: How to Run One With a Non-Technical Team

A cyber attack may begin with technology.

The response very quickly becomes a business problem.

If ransomware shuts down shared systems, somebody has to decide which services matter most.

If a finance mailbox is compromised, somebody may need to contact the bank.

If customer information is stolen, somebody must decide:

who needs to know

what can safely be said

who has authority to approve it

whether legal, regulatory or contractual reporting is required

Those decisions are not made solely by IT.

That is why a cyber-security tabletop exercise should involve the people who would actually have to manage the business during an incident—not just technical staff.

A tabletop exercise gives them a safe opportunity to practise.

No servers need to be switched off.

No malware needs to be released.

Nobody needs to know PowerShell or understand packet captures.

The exercise is essentially a structured discussion around a fictional but realistic incident.

The National Cyber Security Centre describes cyber incident exercising as a controlled, scenario-based way to practise, evaluate and improve an existing cyber incident response plan. A tabletop specifically focuses on roles, responsibilities and important decisions rather than live technical activity.

What Is a Cyber-Security Tabletop Exercise?

A facilitator presents an incident in stages.

After each development, the group discusses:

What do we know?

What should happen next?

Who has authority to make the decision?

Who needs to be contacted?

What information are we missing?

What happens if the usual process is unavailable?

The aim is not to produce perfect answers.

It is to expose assumptions before a real incident does.

For example, somebody may say:

“Finance would call the bank immediately.”

Good.

Then ask:

“Where is the emergency fraud number stored?”

If the answer is:

“Probably in Sarah's Outlook.”

and the exercise scenario says Microsoft 365 is unavailable, you have just discovered a genuine resilience problem.

That is exactly what a useful tabletop should achieve.

A Tabletop Is Not a Test of the Employees

This point is particularly important with non-technical teams.

People often become nervous when they hear:

cyber-security exercise

because they assume somebody is about to test how much they know.

Set the expectations at the start:

nobody is being graded

technical knowledge is not required

saying “I don't know” is useful

discovering a missing process is a successful result

the fictional incident is testing the organisation, not individual employees

The NCSC explicitly treats exercising as a way to evaluate and improve response plans in a safe environment.

You want honest answers.

An employee who admits:

“I wouldn't know who is authorised to shut the system down”

has just given you useful information.

Do Not Use the Exercise to Create Your Incident Plan

This is one change I would make especially prominent.

A tabletop should test an existing plan.

The NCSC specifically advises that cyber exercising should strengthen and stress-test existing plans rather than be used as the exercise in which the response plan is invented for the first time.

If you currently have no incident-response plan, first establish:

roles

escalation routes

emergency contacts

decision-making authority

communication arrangements

technical responsibilities

Then exercise it.

Otherwise the session can turn into two hours of:

“Well, I suppose someone should probably…”

That is a planning workshop, not really an exercise.

Choose One or Two Objectives

Do not try to test the entire organisation in one meeting.

Choose one or two questions.

For example:

Can we manage a compromised Microsoft 365 mailbox involving payment fraud?

or:

Could we continue operating for a day if ransomware made the main systems unavailable?

or:

Do we know what to do if a critical supplier suffers a cyber attack?

The NCSC recommends designing exercises around defined objectives rather than trying to test everything simultaneously.

A clear objective also gives you something meaningful to review afterwards.

Instead of:

“Everyone thought it went well.”

you can ask:

“Did we establish who can stop a suspicious payment?”

Choose a Scenario People Understand

For a first exercise, avoid an elaborate nation-state intrusion involving ten systems and obscure technical indicators.

Use something the participants could imagine happening tomorrow.

Good scenarios include:

ransomware stops access to business files

finance mailbox is compromised

fraudulent payment instructions are sent

company laptop or phone is stolen

sensitive information is shared publicly

a critical supplier reports a breach

Microsoft 365 becomes unavailable

employee accepts a suspicious MFA prompt

The NCSC's free Exercise in a Box includes tabletop scenarios around ransomware, phishing, supply-chain compromise, BYOD and other common risks, and it is specifically designed so organisations do not need to be cyber-security experts to use it.

Invite the People Who Would Actually Be Involved

Participants might include:

senior management

finance

operations

HR

communications

data protection/legal

customer service

IT or your MSP

somebody responsible for key suppliers

Do not invite somebody purely because they are senior.

Invite them because they would have a real responsibility during the incident.

The NCSC's exercises commonly specify senior decision-makers alongside technical, HR and communications representatives depending on the scenario.

For a small SME, six to eight people can be plenty.

Too many participants can make the exercise slow and artificial.

Nominate a Facilitator

Someone needs to control the exercise.

The facilitator should:

explain the rules

introduce each development

ask questions

keep the discussion moving

stop one person dominating

challenge assumptions

capture unresolved issues

They do not need to be the most technical person in the room.

In fact, a facilitator who repeatedly asks simple questions such as:

“Who actually makes that decision?”

can be extremely effective.

The facilitator should resist solving the scenario for everyone.

If the team makes an assumption, follow it.

For example:

“We'll just call everyone.”

Ask:

“How, if your normal Microsoft 365 accounts are unavailable?”

That is where the useful discussion begins.

Build the Incident in Stages

Do not tell participants the whole scenario immediately.

Introduce developments gradually.

These developments are often called injects.

Consider a business-email-compromise exercise.

Inject 1 — Something Is Wrong

09:10

Two suppliers contact the finance department.

They have received emails from the finance manager's real company mailbox telling them to use new bank details.

Ask:

What happens first?

Who takes control?

Should the account be disabled?

Who contacts the finance manager?

Should suppliers be warned?

Let the team discuss.

Then introduce the next development.

Inject 2 — Evidence of Compromise

IT reports:

There was an unfamiliar successful Microsoft 365 sign-in overnight.

A mailbox rule forwarding messages externally has also been discovered.

Ask:

Could other accounts be affected?

What evidence should be retained?

Who needs to know?

Which communications channel can be trusted?

What business activity should be temporarily stopped?

The technical representative can explain what IT would do.

The rest of the team needs to deal with what that means operationally.

Inject 3 — Money Has Already Gone

At 09:45:

A supplier confirms that £38,000 has already been transferred to the fraudulent bank account.

Now ask:

Who calls the bank?

Who has authority to speak for the business?

Does the insurer need notifying?

Who records the timeline?

Who informs senior management?

Does legal or regulatory advice need to be obtained?

This is where a cyber incident becomes a business incident.

Inject 4 — Remove a Key Person

Now make the exercise more realistic.

Tell participants:

The Managing Director is on a flight and cannot be contacted for five hours.

What happens?

The NCSC's January 2026 resilience guidance specifically recommends exercising scenarios where key personnel are unavailable.

This is extremely useful.

Many incident plans quietly assume that one particular person will always be available to approve:

emergency expenditure

shutdowns

public statements

customer notifications

A tabletop can expose that single-person dependency.

Inject 5 — Make the Normal Tool Unavailable

Now say:

Microsoft 365 has been temporarily restricted while the compromise is investigated.

Ask:

Where is the incident plan stored?

Where are emergency telephone numbers?

How will the team communicate?

Can employees access supplier contacts?

Where are insurance details?

Where are recovery credentials?

If all your emergency information is stored only inside the system that has failed, you do not really have independent recovery information.

Test External Dependencies Too

Cyber incidents rarely involve only your organisation.

You may depend on:

MSP

cyber insurer

solicitor

bank

cloud provider

software vendor

telecoms company

important customer or supplier

The NCSC's 2026 guidance specifically recommends exercising recovery plans with external partners and suppliers rather than assuming they will seamlessly support the response when needed.

Ask:

Do we know who to contact?

Better:

Have we verified the number?

Better still:

Has that relationship or process ever actually been tested?

Test the Backup Plan, Not Just the Main Plan

For a ransomware scenario, do not make the exercise too easy.

Instead of:

“IT restores the backup and everything is fine.”

introduce:

The most recent backups appear to have been affected.

or:

The normal recovery platform is unavailable.

The NCSC's January 2026 severe-threat guidance recommends exercises where primary recovery tools are compromised.

Now the discussion changes:

Which older recovery copies exist?

What gets restored first?

How long can each department operate manually?

Can the business still invoice?

Can customers still contact us?

What happens if recovery takes three days instead of three hours?

That produces a much more valuable exercise.

Consider an Attacker Still Being Present

Another strong 2026 scenario inject is:

IT says systems could potentially be restored, but investigators are not yet confident the attacker has been completely removed.

Do you:

restore immediately to get the business running

or:

delay recovery to avoid reinfection?

The NCSC specifically recommends testing scenarios in which attackers may still be present during the transition back to normal operations.

That is exactly the kind of uncomfortable decision executives may have to make during a serious incident.

Ask Business Questions

Avoid turning the session into cyber-security trivia.

Do not ask the finance manager:

“Which Entra Conditional Access policy would stop this attack?”

Ask:

“Do we temporarily suspend payments?”

“Who can authorise that?”

“How long can finance operate manually?”

“How do we tell suppliers which messages to trust?”

Other useful questions include:

What is the most important service to restore?

Who communicates with staff?

Who communicates with customers?

Who has authority to shut a system down?

What if the incident lead is unavailable?

Where are emergency contacts stored?

What contractual deadlines exist?

Who records decisions?

When would the insurer be notified?

Which workaround would we use?

A non-technical tabletop should test business judgement and coordination, not vocabulary.

Keep the Exercise Manageable

For many first tabletop sessions:

60–90 minutes

is plenty.

A simple structure is:

Time    Activity

10 minutes    Purpose, ground rules and scenario
40–50 minutes    Incident injects and discussion
15 minutes    Debrief
10–15 minutes    Actions, owners and deadlines

Some of the NCSC's shorter Exercise in a Box activities can be completed in as little as 15–30 minutes, while broader tabletop scenarios can take considerably longer.

The correct duration depends on the objective.

Do not make the exercise longer simply to make it feel more serious.

Have a Dedicated Note-Taker

Someone should record:

decisions

unanswered questions

conflicting responsibilities

missing information

dependencies

workarounds

delays

assumptions

required improvements

Do not attempt to create a transcript of every sentence.

Focus on what needs to change.

For example:

Finding: Nobody knows who can notify the cyber insurer.

Action: Confirm notification process and emergency contact.

Owner: Finance Director.

Deadline: 14 days.

That is useful.

“We should probably look at insurance at some point.”

is not.

Finish With Actions, Not Applause

At the end, ask:

What worked?

What caused confusion?

Which decision took too long?

Which information was missing?

What surprised us?

What needs changing before the next exercise?

The NCSC describes exercising as a process for practising, evaluating and improving incident response—not simply proving that a plan exists.

Every meaningful finding should therefore become one of:

action

owner

deadline

Then update the incident-response plan.

Run the Exercise Again

A tabletop should not be a once-a-year event that disappears into a compliance folder.

The NCSC recommends making testing and exercising a routine part of cyber resilience, with lessons from one exercise feeding into the next.

You might run:

Exercise 1
Business email compromise

then:

Exercise 2
Ransomware

then:

Exercise 3
Critical supplier breach

Each tests a different weakness.

More importantly, the next exercise should verify whether actions from the previous one were actually completed.

A Simple Tabletop Checklist

Before the exercise:

1. Start with an existing response plan.

2. Choose one or two objectives.

3. Select a realistic scenario.

4. Invite people who would genuinely have a role.

5. Nominate a facilitator.

6. Nominate a note-taker.

7. Create several staged injects.

During it:

8. Ask business questions, not technical trivia.

9. Remove assumptions gradually.

10. Make a key person unavailable.

11. Test communication outside normal systems.

12. Test suppliers and other external dependencies.

13. Challenge recovery assumptions.

14. Record decisions and gaps.

Afterwards:

15. Agree actions, owners and deadlines.

16. Update the response plan.

17. Verify that improvements actually happen.

18. Run another exercise later.

The key principle is:

The success of a tabletop exercise is not that everybody knew the answer. It is that the organisation discovered which answers it needs before the real incident happens.

How Hamilton Group Can Help

Hamilton Group can help businesses prepare for cyber incidents before they are dealing with one for real.

We can assist with:

cyber incident-response planning

tabletop exercises

ransomware scenarios

Microsoft 365 compromise scenarios

business email compromise

backup and recovery planning

business continuity

cyber-security training

Microsoft 365 security

incident-response reviews

The goal is not to turn non-technical employees into cyber-security engineers.

It is to make sure everyone understands their role when technology failure becomes a business crisis.

Visit hgmssp.com or call 0330 043 0069 to discuss cyber-security preparedness and incident response.

SEO Meta Description

SEO Keywords

Drupal-ready blog summary

I would replace the current article with this version. The live page is already very good, so this is more of a 2026 strengthening than a correction. The biggest improvements come from the NCSC’s newer guidance: exercise unavailable key personnel, compromised recovery tools, external suppliers and the possibility that attackers remain present during recovery. Those situations turn a straightforward discussion exercise into a much more realistic test of whether the business could actually operate under pressure.