# Inclusive Security Exercises: Testing Your Human Defenses

Tabletop exercises and simulations reveal gaps that policy documents never do, and they work best when they reflect the full diversity of the people who will actually respond.

A security **exercise** is a rehearsal: you act out a security incident in a safe setting to see how people and plans really respond. Exercises are among the most valuable and most skipped parts of a security program, much like a fire drill. A fire plan on paper tells you what should happen. A drill shows what does happen, and the gap between the two is usually larger than expected.

## Why exercises reveal what plans cannot

A written incident response[↗](/incident-response) plan is a description. An exercise is a test. The most common discoveries are unclear ownership of key decisions, out-of-date contact lists, and wrong assumptions about who has access to critical systems. It is far better to find these on a quiet Tuesday morning than during a real attack. [Building an Incident Response Plan for Small TeamsYou don't need a security team to have a plan. A simple, written incident response plan turns a chaotic security event into a manageable one.](/building-an-incident-response-plan-for-small-teams)

## Types of exercise, from easy to demanding

| Type | What happens | Time and effort |
| --- | --- | --- |
| Tabletop discussion | A group sits around a table and talks through a scenario step by step: "It is Friday 5 p.m. and our files are locked. What do we do?" | About an hour, no technology needed |
| Walk-through of the plan | Participants check each step of the written plan against reality: are the phone numbers right, can people open the shared folder? | A few hours |
| Live simulation | A realistic mock attack, such as a test phishing↗ email or a "red team↗" that plays the attacker, while the "blue team↗" defends | Days of planning, done with care and permission |

## Designing exercises inclusively

An exercise built on one set of assumptions, such as a single chat tool, a single working style, or one level of technical skill, will only prepare you for incidents that unfold exactly that way. Real teams are mixed, so design for that:

- **Multiple communication channels.** In a crisis, not everyone watches the same chat app or checks email at the same pace. Practice reaching people by phone, text, and in person.

- **Varied technical backgrounds.** A scenario that only technical staff can follow leaves out the managers, communications staff, and legal advisers who will also be in the room during a real incident. Write the scenario in plain language.

- **Accessibility.** Make sure participants with different needs can take part fully: readable materials, flexible formats, and time to think.

- **Safe to speak up.** The goal is to find gaps, not to blame anyone. Say so at the start.

## Start small: a one-hour tabletop

- **Pick a realistic scenario** that fits your organization, such as a staff member reporting a suspicious email they already clicked.

- **Invite a mixed group:** someone from IT, a manager, someone who handles communications, and a front-line staff member.

- **Walk through it in stages.** Reveal one development at a time and ask "what do we do now, who decides, and who do we tell?"

- **Write down the gaps** you find, such as a missing phone number or nobody knowing who can approve shutting a system down.

- **Assign owners and dates** for fixing each gap, then run it again later.

## People-centred security in practice

Inclusive exercise design and people-centred security share one idea: security that works for only one type of person, in one set of circumstances, is not robust. It just happens to work in the scenario someone imagined while designing it.

> An exercise that reflects how only one type of person thinks and communicates prepares your organization only for incidents that unfold exactly that way.

## Related reading

[Incident Management and Security Logging in PracticeWhen an incident happens, the quality of your logs determines how quickly you understand what occurred, and how confidently you can say it's truly resolved.](/incident-management-and-security-logging-in-practice) [People-Centred Security: Designing Policies Humans Actually FollowSecurity policies that ignore how people actually work get quietly ignored. A practical look at designing remote work, video conferencing, and social media policies people follow because they make sense.](/people-centred-security-designing-policies-humans-actually-follow)
