Writing an Information Security Policy That Works: How to Run a Tabletop Exercise for Your Incident Response Plan

Many organizations have an incident response plan, but fewer know whether it will actually work under pressure. A tabletop exercise gives business leaders, IT, security, legal, compliance, communications and operations teams a safe way to test the plan before a real cyber incident forces them to use it.

In this article, you will learn how to plan, run and improve a cybersecurity tabletop exercise, what to include in your scenario, how an incident response plan template can help, and why related governance documents such as a data classification policy matter during a real incident.

Why Tabletop Exercises Matter for Cybersecurity Governance

A tabletop exercise is a discussion-based simulation of a cybersecurity incident. Instead of touching live systems, participants walk through a realistic scenario and explain what they would do, who they would contact, what decisions they would make and where the organization’s policies or procedures are unclear.

For business leaders, tabletop exercises are valuable because they reveal practical questions that written policies often miss:

• Who has authority to declare a security incident?
• Who can approve system shutdowns, vendor notifications or ransom-related decisions?
• How quickly can the organization determine what data was affected?
• Does the communications team know what it can and cannot say?
• Does legal counsel need to be involved before external notices are sent?
• Are cyber insurance, law enforcement, regulators, customers or partners part of the response process?
• Can the organization continue critical operations while systems are unavailable?

A tabletop exercise turns cybersecurity governance from a paper exercise into an operational capability.

How Tabletop Exercises Support Policy and Compliance

Cybersecurity policies define management expectations. Procedures explain how teams carry them out. A tabletop exercise tests whether those expectations are realistic.

For healthcare organizations and business associates, incident response planning may also support broader compliance obligations under the HIPAA Security Rule, including administrative safeguards at 45 CFR 164.308. Depending on the organization, other frameworks or contractual requirements may also apply, such as the NIST Cybersecurity Framework, NIST Special Publication 800-61, PCI DSS, SOC 2, HITRUST, payer requirements, cyber insurance requirements or state breach notification laws.

Requirements vary by state, payer, contract and framework version, so organizations should confirm which obligations apply to them. Legal interpretation, including breach notification obligations, should be handled with qualified counsel.

Start With the Right Foundation: Your Incident Response Plan

Before running a tabletop exercise, you need a plan to test. It does not need to be perfect, but it should be complete enough to guide roles, responsibilities and decisions.

An effective incident response plan should answer the following questions:

• What counts as a security incident?
• How are incidents reported?
• Who leads the response?
• Who is on the incident response team?
• What are the severity levels?
• How are incidents triaged and escalated?
• What are the steps for containment, eradication and recovery?
• How is evidence preserved?
• How are affected systems, users, vendors and data identified?
• Who communicates internally and externally?
• When are legal, compliance, privacy, cyber insurance and executive leadership notified?
• How are lessons learned documented and tracked?

If your organization is using an incident response plan template, treat it as a starting point, not a finished product. Templates are helpful because they provide structure, but they must be tailored to your business model, technology environment, regulatory obligations, staffing, vendors and risk tolerance.

Incident Response Plan Template: What to Include Before the Exercise

A practical incident response plan template should include the following sections.

1. Purpose and Scope

Define what the plan covers. For example:

> This incident response plan establishes the process for identifying, reporting, investigating, containing, recovering from and documenting cybersecurity incidents affecting company systems, data, users, networks, cloud environments and third-party services.

Be clear about whether the plan applies to corporate IT, clinical systems, cloud platforms, operational technology, remote workforce systems, vendors or all of the above.

2. Incident Definitions

Define key terms so teams respond consistently.

Examples include:

• Security event: An observable occurrence that may be relevant to security, such as a failed login attempt or endpoint alert.
• Security incident: An event that indicates actual or suspected compromise of confidentiality, integrity or availability.
• Privacy incident: An event involving potential unauthorized access, use or disclosure of personal, protected or regulated data.
• Major incident: An incident with significant operational, legal, financial, patient care, customer or reputational impact.

3. Roles and Responsibilities

Identify who does what during an incident.

Common roles include:

• Executive sponsor
• Incident commander
• IT operations lead
• Security lead
• Legal counsel
• Privacy or compliance officer
• Human resources
• Communications or public relations
• Business unit leader
• Vendor management
• Cyber insurance contact
• Third-party forensic support, if applicable

For smaller organizations, one person may fill multiple roles. The important point is to assign responsibilities before an incident occurs.

4. Severity Levels

Define severity levels with business impact in mind.

Example:

| Severity | Description | Example | |---|---|---| | Low | Limited impact, no evidence of data exposure | Isolated malware blocked by endpoint protection | | Medium | Potential system or data impact requiring investigation | Compromised user account with limited access | | High | Confirmed compromise, business disruption or sensitive data risk | Ransomware affecting a department | | Critical | Enterprise-wide impact, patient/customer safety risk or major data exposure | Widespread outage affecting critical operations |

Severity levels help the organization determine escalation, communications and executive involvement.

5. Response Phases

Many plans follow a lifecycle similar to guidance in NIST Special Publication 800-61, including preparation, detection and analysis, containment, eradication and recovery, and post-incident activity.

Your plan should explain how your organization handles each phase in practical terms.

6. Communication Procedures

Communication failures are common during incidents. Include:

• Internal notification lists
• Executive escalation criteria
• Legal and compliance notification points
• Vendor and managed service provider contacts
• Cyber insurance notification process
• Law enforcement decision process
• Customer, patient, partner or regulator communication workflow
• Approved communication channels if email or collaboration tools are unavailable

Do not assume normal communication tools will be available during a cyber incident.

7. Evidence and Documentation

The plan should explain how to preserve logs, system images, emails, alerts, screenshots, timelines and decisions. Documentation supports investigation, recovery, insurance claims, regulatory response and lessons learned.

8. Post-Incident Review

Every incident should conclude with a lessons-learned process. A tabletop exercise should use the same concept: identify gaps, assign owners and track remediation.

Why Your Data Classification Policy Matters During Incident Response

A data classification policy defines categories of information based on sensitivity, value and regulatory requirements. It helps the organization understand what data it has, where it lives and how it should be protected.

During an incident, this becomes critical. If a compromised system contains only public information, the response may be very different from an incident involving protected health information, payment card data, employee records, intellectual property or credentials.

A practical data classification policy usually includes categories such as:

• Public: Approved for public release.
• Internal: Business information not intended for public distribution.
• Confidential: Sensitive business, employee, customer or operational information.
• Restricted or Regulated: Information subject to legal, regulatory, contractual or high-risk security requirements, such as protected health information or payment card data.

The policy should also define handling requirements, including access controls, encryption, storage locations, transmission methods, retention and disposal.

Example: Why Classification Changes the Tabletop Discussion

Consider two ransomware scenarios:

1. A file server containing public marketing materials is encrypted.
2. A clinical file share containing protected health information is encrypted and may have been accessed by an unauthorized actor.

The technical response may look similar at first: isolate systems, preserve evidence, investigate, restore and monitor. But the governance response is very different. The second scenario may require privacy review, legal analysis, documentation of affected data, potential notification obligations and coordination with compliance leadership.

A tabletop exercise helps determine whether the organization can make those distinctions quickly.

Planning the Tabletop Exercise

A good tabletop exercise requires preparation, but it does not need to be overly complex. The goal is not to embarrass participants or prove failure. The goal is to improve readiness.

Step 1: Define the Exercise Objectives

Start by deciding what you want to learn. Clear objectives keep the exercise focused.

Examples:

• Test whether the incident response team understands its roles.
• Validate executive decision-making during a ransomware event.
• Assess communication procedures if email is unavailable.
• Evaluate how quickly the organization can identify affected data.
• Test escalation from IT to legal, compliance and leadership.
• Review vendor coordination during a cloud service compromise.
• Identify gaps in backup and recovery decision-making.
• Practice response to potential unauthorized access to regulated data.

For a first tabletop exercise, choose three to five objectives. Too many objectives can make the session unfocused.

Step 2: Select the Participants

A tabletop exercise should include more than IT. Cyber incidents are business events.

Recommended participants include:

• Chief executive, chief operating officer or business sponsor
• Chief information officer or IT director
• Security leader or security service provider
• Compliance or privacy officer
• Legal counsel
• Communications or public relations
• Human resources
• Finance
• Risk management
• Vendor management or procurement
• Business unit leaders
• Help desk or service desk manager
• Clinical operations leader, if applicable to a healthcare organization

Not every participant needs to speak at every point, but each should understand when their role becomes important.

Step 3: Assign Exercise Roles

At minimum, assign:

• Facilitator: Leads the discussion and presents scenario updates.
• Scribe: Captures decisions, gaps, questions and action items.
• Participants: Respond based on their actual roles.
• Observers: Watch and provide feedback without driving the discussion.

The facilitator should understand incident response, business operations and the organization’s policies. This can be an internal leader or an external advisor.

Step 4: Choose a Realistic Scenario

The best scenario is plausible for your organization. It should reflect your industry, systems, vendors, data and business operations.

Common cybersecurity tabletop scenarios include:

• Ransomware affecting file servers and backups
• Business email compromise involving fraudulent payment instructions
• Compromised administrator account in a cloud platform
• Lost or stolen laptop containing sensitive data
• Unauthorized access to electronic health records
• Vendor breach affecting company data
• Distributed denial-of-service attack affecting customer-facing services
• Insider misuse of confidential information
• Phishing campaign leading to credential theft
• Malware infection spreading through remote access tools

For healthcare organizations, scenarios may also consider patient care disruption, downtime procedures, clinical system availability, medical device dependencies and protected health information.

Step 5: Build the Timeline and Injects

An “inject” is a new piece of information introduced during the exercise. Injects move the scenario forward and force decisions.

Example ransomware timeline:

9:00 a.m. Help desk receives calls that users cannot open shared files. 9:15 a.m. IT finds ransom notes on several network shares. 9:30 a.m. Endpoint alerts show suspicious activity from a service account. 10:00 a.m. A department reports that a critical application is unavailable. 10:30 a.m. A manager asks whether staff should shut down workstations. 11:00 a.m. The backup administrator reports that some backups may be affected. 11:30 a.m. A reporter emails the communications team asking about a rumored cyberattack. 12:00 p.m. Security logs suggest large outbound data transfers occurred overnight.

Each inject should be tied to an exercise objective. If the objective is to test communications, include media, employee or customer questions. If the objective is data classification, include uncertainty about what data was stored on the affected system.

Step 6: Prepare Materials

Before the session, gather:

• Current incident response plan
• Contact lists and escalation procedures
• Data classification policy
• Business continuity and disaster recovery plans
• Cyber insurance contact instructions, if applicable
• Vendor contact list
• Network or system diagrams, if appropriate
• Communication templates, if available
• Relevant regulatory or contractual obligations
• Note-taking template
• Action item tracker

Avoid turning the exercise into a document review meeting. The documents are there to support decisions.

How to Run the Tabletop Exercise

A typical tabletop exercise can be completed in two to four hours. More complex organizations may need a half-day or full-day session.

Opening Briefing

Start with ground rules:

• This is a no-fault exercise.
• Participants should respond based on current capabilities, not ideal future capabilities.
• The goal is to identify gaps before a real incident.
• If an answer is unknown, say so and capture it.
• Do not test live containment steps during the discussion unless separately approved.
• Legal and privileged discussions should be handled according to counsel’s guidance.

Then review the exercise objectives, scenario scope and expected outcome.

Walk Through the Scenario

The facilitator introduces the first scenario statement and asks participants what they would do.

Useful questions include:

• Who receives the initial report?
• How is the incident documented?
• Who decides whether this is a security incident?
• What severity level applies?
• Who must be notified immediately?
• What systems or data may be affected?
• What evidence should be preserved?
• What containment steps are considered?
• What business operations are impacted?
• What decisions require executive approval?
• What communications are needed?
• What legal, privacy or compliance review is required?
• What vendors or third parties must be contacted?
• What if the primary communication system is unavailable?

The facilitator should avoid giving participants the “right” answer too early. The value comes from seeing how the organization thinks through uncertainty.

Keep the Discussion Business-Focused

A common mistake is allowing the tabletop to become entirely technical. Technical details matter, but executives need to practice business decisions.

Examples of business decisions include:

• Whether to disconnect a system that supports critical operations
• Whether to activate downtime procedures
• Whether to engage outside forensic support
• Whether to notify cyber insurance
• Whether to involve law enforcement
• Whether to pause certain business processes
• Whether to issue internal employee guidance
• Whether to communicate with customers, patients, partners or regulators
• How to prioritize restoration when multiple systems are affected
• How to approve emergency spending

The exercise should clarify who makes these decisions and what information they need.

Test Communications

Communication is often the hardest part of incident response.

Ask participants:

• How will employees know what to do?
• Who approves internal messages?
• Who responds to customer or patient questions?
• Who speaks to the media?
• What if email is unavailable?
• Are personal phones or messaging apps approved for incident communications?
• How are board members or owners informed?
• Who coordinates with vendors?
• Are there pre-approved holding statements?

Example internal holding statement:

> We are investigating a technology issue affecting access to certain systems. Please do not restart or modify affected devices unless instructed by IT. Continue to follow department downtime procedures and report any unusual system behavior to the service desk.

This type of message should be reviewed and adapted before a real incident, especially in regulated environments.

Test Data Identification

If the scenario involves possible data exposure, ask:

• What data is stored on the affected system?
• Who owns that data?
• What classification applies?
• Is protected, regulated or confidential data involved?
• Are logs available to determine access?
• Are retention schedules relevant?
• Are third-party systems involved?
• What contracts or data processing agreements may apply?
• Who conducts legal or regulatory analysis?

This is where the data classification policy, asset inventory and data maps become essential.

Capture Gaps in Real Time

The scribe should document:

• Decisions made
• Unclear responsibilities
• Missing contact information
• Outdated procedures
• Technology limitations
• Training needs
• Policy gaps
• Legal or compliance questions
• Vendor dependencies
• Follow-up actions
• Owners and target dates

Do not wait until the end to capture gaps. Important details are easily lost.

Practical Tabletop Exercise Checklist

Use this checklist to prepare and run your exercise.

Before the Exercise

• [ ] Confirm executive sponsorship.
• [ ] Define three to five objectives.
• [ ] Select a realistic scenario.
• [ ] Identify participants and observers.
• [ ] Assign facilitator and scribe.
• [ ] Review the current incident response plan.
• [ ] Gather related policies, including the data classification policy.
• [ ] Confirm contact lists are available.
• [ ] Prepare scenario injects.
• [ ] Decide whether legal counsel should be present.
• [ ] Schedule the session with enough time for discussion.
• [ ] Prepare an action item tracker.
• [ ] Set expectations that this is a no-fault exercise.

During the Exercise

• [ ] Review objectives and ground rules.
• [ ] Present the initial scenario.
• [ ] Ask participants to respond based on current processes.
• [ ] Introduce injects gradually.
• [ ] Test escalation and decision-making.
• [ ] Discuss communications.
• [ ] Discuss data classification and potential data exposure.
• [ ] Identify vendor and third-party dependencies.
• [ ] Capture gaps and action items.
• [ ] Avoid solving every issue during the exercise.
• [ ] Reserve time for immediate observations.

After the Exercise

• [ ] Conduct a hot wash, or immediate debrief.
• [ ] Prepare an after-action report.
• [ ] Prioritize findings by risk and business impact.
• [ ] Assign owners and due dates.
• [ ] Update the incident response plan.
• [ ] Update related policies and procedures.
• [ ] Refresh contact lists.
• [ ] Address training needs.
• [ ] Review technical control gaps.
• [ ] Schedule the next exercise.
• [ ] Report key outcomes to leadership.

Example Tabletop Scenario: Ransomware and Data Exposure Concern

The following example can be adapted for many organizations.

Scenario Overview

Employees in the finance department report that shared files have strange extensions and cannot be opened. A ransom note appears in multiple folders. The note claims that data was copied before encryption. Several users also report that email is slow, and the service desk is receiving a high volume of calls.

Exercise Objectives

• Test incident escalation and severity classification.
• Confirm executive decision-making authority.
• Evaluate containment and recovery coordination.
• Assess communications if normal channels are unreliable.
• Determine whether affected data can be identified using the data classification policy.
• Identify legal, compliance and privacy review points.

Discussion Questions

Initial Detection

• Who receives the first report?
• How is the incident ticket categorized?
• When does IT escalate to security leadership?
• Who declares an incident?

Containment

• Who can approve disconnecting servers or disabling accounts?
• Are there known dependencies that could affect operations?
• How are remote users handled?
• Are backups isolated?

Leadership

• When is executive leadership notified?
• Who leads the incident response bridge?
• What decisions require senior approval?

Data

• What data is stored on the affected shares?
• Is there a data owner?
• What classification applies?
• Are regulated records involved?
• Are access logs available?

Communications

• What do employees need to know immediately?
• Who approves internal updates?
• What if customers, patients or partners ask questions?
• Who handles media inquiries?

Legal and Compliance

• When is counsel engaged?
• Is cyber insurance notified?
• Are there contractual notification obligations?
• Do any state or sector-specific requirements need review?

Recovery

• What systems are restored first?
• Who validates that systems are clean?
• How are passwords, service accounts and administrative credentials handled?
• How is the business informed that services are restored?

Expected Outputs

At the end of the exercise, the organization should have:

• A list of incident response plan gaps
• Updated role and escalation clarity
• A better understanding of data location and classification issues
• Communication improvements
• Backup and recovery questions to resolve
• Assigned remediation actions

Common Findings From Tabletop Exercises

While every organization is different, tabletop exercises often reveal similar governance issues.

Roles Are Unclear

The plan may name an incident response team but not specify who has final authority. For example, IT may assume executives will decide whether to shut down a system, while executives assume IT has that authority.

Action: Add a decision matrix to the incident response plan.

Contact Lists Are Outdated

During an incident, outdated phone numbers and vendor contacts waste time.

Action: Review and update contact lists at least periodically and after major staffing or vendor changes.

Data Locations Are Poorly Understood

Organizations often cannot quickly determine what sensitive data resides on a server, application or cloud repository.

Action: Strengthen asset inventory, data mapping and the data classification policy.

Communications Are Too Informal

Teams may rely on email, chat or personal contacts without a documented backup plan.

Action: Define approved incident communication channels and alternates.

Legal and Compliance Are Engaged Too Late

Privacy, regulatory, contractual and evidentiary issues can arise early.

Action: Define clear triggers for involving legal, privacy and compliance leaders.

Backup Assumptions Are Untested

The team may assume backups are available, isolated and restorable, but the exercise exposes uncertainty.

Action: Align incident response exercises with backup restoration testing and disaster recovery planning.

Vendor Dependencies Are Missing

Managed service providers, cloud vendors, software providers and third-party platforms may be essential to response and recovery.

Action: Include vendor contacts, support procedures and contractual obligations in the plan.

Updating Policies After the Exercise

A tabletop exercise should produce policy improvements. This is especially important if your organization is writing an information security policy or updating a broader security governance program.

Policies that may need updates include:

• Information security policy
• Incident response plan
• Data classification policy
• Access control policy
• Acceptable use policy
• Business continuity plan
• Disaster recovery plan
• Vendor risk management policy
• Logging and monitoring policy
• Backup policy
• Remote access policy
• Security awareness training policy

Turning Findings Into Policy Changes

For each finding, ask:

• Is this a policy issue, a procedure issue, a technology issue or a training issue?
• Who owns the change?
• Is leadership approval required?
• Does the change affect compliance obligations?
• Does the change need workforce training?
• How will completion be verified?

Example:

Finding: No one knew who could approve taking a critical application offline. Policy update: Add an incident decision authority matrix that defines who can approve containment actions by severity level. Procedure update: Add a call tree for emergency approvals. Training update: Include the decision matrix in annual incident response training.

Measuring the Success of a Tabletop Exercise

A tabletop exercise is successful if it produces honest insight and actionable improvement. It is not successful merely because the team “got through” the scenario.

Useful measures include:

• Were the right participants involved?
• Did the team identify and escalate the incident appropriately?
• Were roles clear?
• Were severity levels useful?
• Were communication paths effective?
• Could the organization identify affected systems and data?
• Were legal, privacy and compliance issues recognized?
• Were business impacts considered?
• Were recovery priorities clear?
• Were action items assigned and tracked?

Avoid scoring the exercise in a way that discourages transparency. The goal is readiness, not blame.

How Often Should You Run a Tabletop Exercise?

Frequency depends on the organization’s size, risk, regulatory obligations, customer expectations and rate of change. Many organizations conduct cybersecurity tabletop exercises at least annually, with additional exercises after major technology changes, acquisitions, significant incidents, new regulatory requirements or changes in leadership.

Healthcare organizations, organizations handling regulated data and companies with complex vendor environments may benefit from more frequent exercises or targeted mini-tabletops focused on specific risks such as ransomware, cloud compromise or downtime procedures.

Tips for Executives Participating in a Tabletop Exercise

Business leaders do not need to be technical experts, but they do need to make decisions under uncertainty.

Executives should be prepared to discuss:

• Business priorities during system outages
• Customer, patient, employee and partner impacts
• Risk tolerance
• Financial authority for emergency response
• Public communications
• Legal and regulatory escalation
• Board or ownership notification
• Operational workarounds
• Recovery priorities
• Reputation management

The most useful executive question is often: “What information do we need to make this decision, and who can provide it?”

Tips for IT and Security Teams

IT and security teams should use the tabletop to validate practical response capabilities.

Be ready to explain:

• How alerts are triaged
• How compromised accounts are disabled
• How endpoints or servers are isolated
• Where logs are stored
• How long logs are retained
• How backups are protected
• How systems are restored
• How administrative access is controlled
• Which vendors are required for support
• What technical limitations exist

Avoid assuming that business leaders understand technical tradeoffs. Explain the operational impact of each option.

From Exercise to Readiness: The After-Action Report

The after-action report is where the exercise becomes useful. It should be concise, factual and focused on improvement.

Include:

• Exercise date and participants
• Scenario summary
• Objectives
• Key decisions discussed
• Strengths observed
• Gaps identified
• Risk ratings or priority levels
• Recommended corrective actions
• Assigned owners
• Target completion dates
• Items requiring leadership decision
• Date for follow-up review

The report should be shared with appropriate leadership and tracked like any other risk remediation activity.

Conclusion and Next Steps

A tabletop exercise is one of the most practical ways to test whether your incident response plan, information security policy and data classification policy will work during a real cyber incident. It helps business and technical teams practice decision-making, clarify roles, improve communications and identify gaps before attackers, outages or regulatory deadlines create pressure.

Next steps:

1. Review your current incident response plan.
2. Confirm that roles, severity levels and escalation paths are clear.
3. Validate that your data classification policy supports incident decision-making.
4. Choose a realistic scenario, such as ransomware or business email compromise.
5. Schedule a tabletop exercise with business, IT, legal, compliance and communications leaders.
6. Document lessons learned and assign action items.
7. Update policies, procedures and training based on the results.

How ThornShield Can Help

ThornShield Technologies helps organizations build practical security governance programs, including incident response plans, tabletop exercises and policy updates. If your organization is writing an information security policy or strengthening related governance documents, our [Security Policy Development](https://www.thornshield.tech/services/policy-development) services can help you create clear, usable policies aligned to your risk and compliance needs.

This article is general information and not legal advice.