Safeguard 17.7 Incident response exercises

What Safeguard 17.7 incident response exercises asks your team to prove

Safeguard 17.7 asks you to prove that key personnel rehearse the incident response process routinely, through exercises and scenarios run at least annually that test communication channels, decision making and workflows. If your organization has a written incident response process but cannot show a dated exercise, a scenario, participants and findings, an assessor will see a plan that has never been tested. The CIS Controls Assessment Specification scores this Safeguard with a Completeness metric, measuring the share of components included in the documentation for the exercises, and it gives a failing score when no exercises appear in the documented process at all. The risk is simple to state. A plan that has never been rehearsed tends to break at the first points where people must act without reference material: who is paged at night, which channel is used when email may be compromised, who can approve taking a system offline, and when legal counsel or a regulator must be contacted. Those gaps show up in an exercise, where the cost is a few hours of discussion, and in a live incident, where the cost is far higher.

Running this safeguard is hard in practice for three reasons. First, senior decision makers are the people who most need to attend and the hardest to schedule, so the exercise must be planned around their calendars well before the date. Second, a scenario has to be realistic enough to force decisions yet written so that its injects, timing and expected outcomes are controlled, which takes a facilitator who knows both the threat and the organization. Third, findings must be captured, assigned and tracked, or the exercise produces no evidence and no improvement. Safeguard 17.7 is an IG2 safeguard, so it applies to IG2 and IG3 enterprises rather than IG1. The CIS Controls Assessment Specification lists Safeguard 17.4, the documented incident response process, as a prerequisite, so an exercise cannot be measured until that process exists and names its roles and communication plan. Before scheduling anything, confirm with your assessor which exercise records and attendance evidence they will request, and check that each exercise traces back to the process it tests.

Which teams, systems and third parties an IG2 exercise must reach

Safeguard 17.7 is an IG2 safeguard, so the first scoping decision is whether the enterprise carries it at all. Once it does, the remaining decisions set who takes part, what the scenarios cover and which systems and channels are tested, and each choice changes how much design and evidence work the exercise program needs.

Key personnel in the exercise

Decide which roles count as key personnel for this safeguard, such as the incident handling lead and backup named under 17.1, the people with decision rights, and the staff who run the response. Each role you include should appear in the exercise plan and in the record of who attended. Check that the list matches the roles in your incident response process, since the assessment specification treats 17.4 as a prerequisite for measuring 17.7. A narrow list is cheaper to run but leaves decision-making by executives and legal untested.

Users and Recover functions in scope

Safeguard 17.7 sits in the Users asset class and the Recover security function under the v8.1 mappings, so scenarios should show how people and recovery decisions work, not only detection. Decide whether scenarios include restoring service, deciding when to resume operations and communicating with affected users. Scenarios that stop at containment will not show whether recovery steps are documented. Ask your assessor how completeness will be judged for these components.

Business systems and tested channels

List the business systems that scenarios touch, such as identity, email, customer-facing applications and backups, and the communication channels the response plan names as primary and secondary. Test whether the channel you would normally use is still available when email is assumed compromised, since that is the case 17.6 allows for. Every system or channel left out should be a documented, deliberate choice. Systems excluded from exercises tend to be the ones that fail first in a real incident.

Service providers in the exercise

Decide whether managed security providers, hosting partners, legal counsel or an outsourced forensic firm take part. Where a third party handles part of your response under 17.1, its contacts and handoffs belong in the scenario. Confirm contractual terms that allow participation and specify who writes the after-action record. Excluding providers keeps the exercise contained, but it leaves the handoff between your team and theirs unproven.

Confirming IG2 applicability

Confirm the enterprise's Implementation Group before scoping anything. IG1 organizations do not carry Safeguard 17.7, while IG2 and IG3 enterprises do. Document the reasoning in your scope statement, including how the enterprise decided its IG, and record any sector rule, such as a regulator's expectation for exercises, that applies independently of the Controls. Revisit the decision when the organization's size, data sensitivity or service mix changes.

Annual cadence and scope size

Set the exercise cadence to at least once a year, as the safeguard requires, and decide how many scenarios cover the in-scope personnel, systems and providers. Each added scenario, participant group or third party increases design time, facilitation hours and reporting effort. Ask any outside facilitator for a quote built from the written scope, and state which scenarios recur each year so the work is not rebuilt from scratch.

How an assessor tests incident response exercises under the CIS assessment specification

This table walks through the steps an assessor follows when measuring Safeguard 17.7 under the CIS Controls Assessment Specification, from the prerequisite check to sampling exercise records. Read it as a preparation checklist: each row names what the assessor asks for, the evidence that passes and the findings that most often appear. The main takeaway is that a documented exercise program is necessary but not sufficient, because the records must show the exercises actually ran across the review period.

Test step	What the assessor requests	Evidence that passes	Common findings
Applicability check	Confirm the enterprise is in Implementation Group 2 or 3, since 17.7 does not apply to IG1	Current IG determination and a documented scope statement	IG is assumed rather than determined, or the scope is not written down
Prerequisite check against 17.4	The documented incident response process that 17.7 depends on	A current incident response process covering roles, compliance requirements and communication	Exercises are described but the underlying process is missing or outdated
Exercise program in documented process	Evidence that incident response exercises appear in the documented process	Process text that names exercises, scenarios and the personnel who take part	No exercises appear in the documented process, which results in a failing score
Completeness metric	The components that the exercise documentation should include, checked against what is actually written	Exercise plans listing objectives, scenarios, participants, communication channels, decision points and workflows, with a higher share of components present	Plans cover only the scenario and omit channels, decisions or workflow steps, lowering the completeness share
Scenario coverage for key personnel	Which roles were exercised and whether the scenarios reflect those people's actual responsibilities	Participant lists matched to roles from the incident response roles process	Exercises include only the security team, leaving legal, communications and business owners untested
Sampling of exercise records	Records of exercises held across the review period, selected for review	Dated reports, attendance records, injects, decision logs and post-exercise actions for each sampled exercise	Records cluster at one date, are missing for part of the period, or cannot be traced to a documented plan
Follow-up on exercise results	How lessons from exercises changed the plan, contacts or workflows	Action items with owners and closure evidence linked to the exercise report	Findings from exercises are recorded but never closed or fed back into the process

How to plan and run an annual incident response exercise

This sequence turns Safeguard 17.7 into a repeatable annual cycle that tests whether people, channels and decisions work under pressure, and leaves a documented record that an assessor can follow from scenario to corrective action.

Confirm the Safeguard 17.4 process exists
Before planning any exercise, check that your documented incident response process under Safeguard 17.4 is current and covers roles, compliance requirements and a communication plan. The CIS Controls Assessment Specification lists 17.4 as a prerequisite for measuring 17.7, so an exercise against an undocumented process produces findings with no baseline. The output is a short confirmation note that names the process version, its owner and the date it was last reviewed, which becomes the reference the exercise scenarios are tested against.
Select key personnel and roles
Name the people who must take part, drawing on the incident response roles set under Safeguard 17.5 and the incident handling lead and backup named under 17.1. Include decision makers from legal, IT, security, communications and business leadership where your process requires them, and note any service provider staff whose role depends on a contract. The output is an attendance list that records each participant, their response role, whether they are a primary or alternate, and which parts of the exercise they must join.
Write scenarios tied to real systems and channels
Draft one or more scenario briefs based on the systems, data and communication paths your organization actually uses, such as a compromised administrator account, a ransomware event affecting file shares, or a suspicious vendor notice. Build in conditions that test the primary and secondary communication mechanisms under Safeguard 17.6, including a case where email is unavailable. Label any hypothetical details as illustrative in the brief. The output is a scenario brief with injects, expected decision points and the contacts from the 17.2 list that should be engaged.
Define success criteria before the exercise
Agree in advance what a successful run looks like, such as whether the right people were notified through the right channel, whether decisions were made by the named roles, and whether the workflow followed the documented steps. Tie each criterion to a part of the 17.4 process or the 17.3 reporting process so the results can be scored. The output is a criteria sheet that the facilitator and observers use during the run and that the final report measures against.
Run the exercise and keep a timeline
Deliver the scenario in a controlled setting, with a facilitator who releases injects, observers who record actions and an agreed way to stop or pause the exercise. Assign someone to keep a timestamped log of when each message was sent, which channel was used, who responded and which decisions were taken. The output is a consolidated exercise timeline that shows the actual sequence of events, which can be compared with the scenario brief and success criteria.
Record decisions, gaps and actions
After the run, hold a structured debrief in which participants and observers compare what happened against the success criteria. Record each decision taken, each communication that failed or was delayed, and each place where the documented process was unclear or not followed. Assign an owner and a tracking status to every gap. The output is an exercise record with a findings register and an action log, which shows the assessor the evidence that the exercise tested communication, decisions and workflows.
Feed findings into post-incident reviews
Pass the findings and action log into the post-incident review process under Safeguard 17.8, so that lessons learned from the exercise lead to documented follow-up changes to the process, contacts, channels or training. Confirm that each action is closed or has an accepted risk decision. The output is a linked set of records showing that exercise findings reached the review process and changed the response capability, which is the evidence that the annual cycle works as a continuing improvement loop.

Which exercise records satisfy an assessor's completeness check

The CIS Controls Assessment Specification scores Safeguard 17.7 on the completeness of the documentation for incident response exercises, so an assessor looks for a documented exercise program and a record trail behind it. The six artifacts below are the records we would expect an assessor to ask for, and each one should be dated, owned and kept current for every annual cycle.

Exercise plan with scenarios

The annual exercise plan names the scenarios, objectives, participants and the Safeguard 17.4 response process each exercise tests. Because the assessment specification treats the Safeguard 17.4 process as a prerequisite, the plan should cite the version of that process in force on the exercise date. Check that every scenario maps to a real decision point in the documented process, and that the plan is approved and dated before the exercise runs.

Attendee and role records

Attendance sheets and role assignments show which key personnel took part and which responsibilities each person held during the scenario. An assessor compares these records against the roles defined for incident response, so gaps such as a missing legal or communications lead are visible. Record substitutes and backups as well, since the incident handling lead and backup are expected to be exercised too.

Scenario injects

Injects are the timed prompts, such as a simulated alert, a fabricated vendor notice or a phishing message, that the facilitator released during the exercise. Keep the inject script with its release times and the response each inject was meant to trigger. Assessors use injects to confirm that the exercise tested decisions and workflows, not just a tabletop reading of the plan.

Communication logs by channel

Communication logs record which channels were used during the exercise, such as the primary phone bridge, email, secure chat and the out-of-band fallback. Note any channel that failed or was unavailable, because Safeguard 17.6 expects planning for a compromised email system. A log that shows only one channel in use is a signal that the secondary mechanisms were not tested.

Decision logs

Decision logs capture who decided what, when, and on what information during the scenario, including escalations, containment choices and notification calls. They show whether the decision making in the process was exercised and whether decisions were made within the timeframes the plan set. Keep the log timestamped in the same time zone and source as the other exercise records.

After-action report with tracked actions

The after-action report summarizes what worked, what failed and what changes are required, and each action needs an owner, a due date and a closure record. Assessors check that findings feed the Safeguard 17.8 post-incident review and the next exercise plan. An action list with open items from earlier cycles and no closure evidence weakens the completeness case.

What meeting Safeguard 17.7 costs in money and effort

This table lists the cost components of running Safeguard 17.7 exercises, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No price or duration figures are supplied for this Safeguard, so use the table to shape a written scope and ask each provider to quote every line.

Cost component	One-time or recurring	What drives it	How to reduce it
Internal staff time for planning	Recurring each cycle	Number of exercise scenarios, number of teams involved, and how much documentation the CAS Completeness check requires	Reuse a scenario library and update only the components that changed since the last exercise
Internal staff time for attendance	Recurring each cycle	Number of key personnel named in the incident response roles, including legal, IT, security, HR, facilities and public relations	Limit each exercise to the roles it tests and rotate participants across cycles
Scenario design	One-time build, then recurring updates	Realism needed for the organization's threat profile, and whether scenarios cover communication, decisions and workflows	Build scenarios from the organization's own incident thresholds and past post-incident reviews
Facilitation	Recurring each cycle	Whether an internal lead or an external facilitator runs the exercise, and the number of sessions	Train an internal facilitator and keep external support for the first cycle or for independent review
External facilitator or red team support	Recurring if used	Scope of the exercise, depth of technical injects, and whether the provider also tests detection	Agree a fixed written scope with deliverables before work starts so the exercise does not expand
Tooling and licenses for case tracking	Recurring if commercial	Number of users, case volume during the exercise, and required integrations with alerting sources	Self-hosted open-source case management, such as DFIR-IRIS, can remove license spend; confirm features and support with the project
Hosting and infrastructure for the exercise platform	Recurring	Whether the exercise runs on production-like or isolated environments and how long they must stay available	Use a shared isolated environment or a private cyber range rather than building a new one for each exercise
Evidence upkeep	Recurring each cycle	Number of exercises, format of records, and how long records must be retained to show each exercise happened at least annually	Store exercise plans, attendance, injects and after-action notes in one dated repository
Auditor sampling effort	Recurring each assessment	Number of exercise records an assessor samples, and whether the process references the exercise cycle clearly	Keep one index that links each exercise to its scenario, participants and resulting improvements

How DFIR-IRIS can hold exercise records as cases

DFIR-IRIS can record a tabletop or simulated incident exercise as a case, so the exercise lives in one record with its assets, indicators of compromise, tasks and evidence, and every change to that record is kept in a full audit trail. For Safeguard 17.7, this matters because the assessor will look for documentation of what was exercised, who took part and what was learned. A single case per exercise gives the team one place to answer those questions. Before adopting this approach, the team must confirm that DFIR-IRIS fits its tabletop format, since the platform is built around case handling rather than facilitated discussion, and must confirm the current feature set in the DFIR-IRIS documentation at DFIR-IRIS documentation.

The consolidated timeline is the part most useful for reconstructing decisions. When facilitators enter injects, responder actions and decision points as they happen, the timeline shows the order in which the team reacted, which is the evidence that the communication channels, decision making and workflows were actually tested. Exercise records are only useful if they cannot be quietly edited after the fact. Evidence entries with SHA-256 verification and chain of custody help show that exercise artifacts, such as screenshots of simulated alerts, recorded calls or exported chat logs, were not altered between the exercise and the review. Decide in advance who may add evidence and who approves it, and record that decision in the process documentation.

Case reports generated from the record can serve as the starting draft of the after-action report that feeds Safeguard 17.8 post-incident reviews. The report should still be reviewed by the people who ran the exercise, because the platform records what was entered, not what was intended or what was missed. DFIR-IRIS does not run the exercise, design the scenarios or replace the documented incident response process that Safeguard 17.4 requires. Those remain the organization's responsibilities, and an implementation partner can configure the platform and the evidence workflow, but the organization owns the exercise program and the auditor will test it.

Who owns the exercise, who can help and what the auditor reviews

Your organization owns Safeguard 17.7. The exercise programme is a process you run, so the people who decide what is tested, who takes part and whether the results lead to change must be your own staff. A partner can help you build the process, but it cannot stand in for your accountability. Under the CIS Controls Assessment Specification, the measure is whether incident response exercises appear in your documented incident response process, so your team must write, approve and keep that documentation current.

Process ownership: Assign an accountable owner for the exercise programme and confirm the annual cadence in your documented process.
Key personnel selection: Choose which roles take part, such as incident handling lead and backups, legal, communications, IT operations and executives.
Running and sign-off: Staff run each exercise, record decisions and timings, and an accountable manager approves the outcome.
Corrective actions: Track every gap found in the exercise to closure, with owners and dates.
Records retention: Keep scenarios, attendance, observations and action logs where an assessor can sample them.

Before any engagement, confirm internally who signs off the exercise record and how corrective actions are tracked, because an outside party cannot make those decisions for you.

Where exercise programs usually fall short and how to close each gap

Most organizations run some kind of tabletop or drill, but few can show the documented scenario, the full set of participants, a working fallback channel or a path from findings to follow-up. The cards below pair each common gap with a specific remedy that an assessor can check against the Safeguard 17.7 measures.

Exercises run without a written scenario

A session held from memory leaves no record of what was tested, so an assessor cannot score completeness. Under the Assessment Specification, the Completeness metric looks at the components included in the documentation for exercises, and a process with no exercises fails outright. Keep a dated scenario file for each exercise that states the injected event, the objectives, the roles tested and the decisions expected. Confirm that every exercise has a matching record before the next one is scheduled.

Only the IT team takes part

Safeguard 17.7 targets key personnel, and incidents that involve customer notices, regulators or public statements stop at legal, communications or executives if those roles never practice. Invite the people named in your 17.5 role assignments, and include at least one decision point that only legal or communications can resolve. Record which roles attended and which were absent, and treat an absent required role as an open finding.

Email assumed to work during a compromise

Many response plans name email as the default channel, yet a compromised mail tenant can silently delay or expose the very messages responders need. Run at least one exercise where the primary channel is removed and the team must reach the incident lead through the secondary path from 17.6. Check that the out-of-band contact method works, that phone numbers are current, and that responders know which channel to use first.

Decisions not tested against the process

An exercise that ends with a good discussion but no check against the documented process proves little about 17.4. Compare what participants actually did with the steps, thresholds and escalation paths written in the plan, and note every divergence. Where a decision took longer than the plan allows or relied on a person who was unavailable, log it as a gap. These observations give the exercise its evidential value.

Findings never reach post-incident reviews

Exercise findings often stay in a slide deck and never become tracked actions, which weakens the link between 17.7 and 17.8. Enter each gap as an item with an owner, a due date and a status, and review open items in the next lessons-learned meeting. Ask the assessor to see how a finding from one exercise was closed in a later one, since that trail shows the program improves rather than repeats itself.

No exercise repeated the following year

The safeguard expects exercises at least annually, so a single well-run exercise does not carry the program into the next cycle. Put the calendar entries and the owner for the next exercise in the record of the current one, and vary the scenario so the team does not simply rehearse the same script. Confirm that the schedule survives staff changes by naming a backup owner for the exercise program.

Questions buyers ask about incident response exercises

Do IG1 organizations have to run incident response exercises under CIS Safeguard 17.7?

No. Safeguard 17.7 is assigned to Implementation Group 2 and Implementation Group 3, so it does not apply to IG1 enterprises under the CIS Controls v8.1 assignments. IG1 still expects basic incident handling foundations such as a designated lead, contact details and a workforce reporting process. An IG1 organization that runs exercises anyway can use them as evidence of maturity, but it should not expect an assessor to score 17.7 against it. Confirm your Implementation Group with the CIS Implementation Groups pages before scoping. The CIS Controls v8.1 page lists the assignments.

How often must incident response exercises be run to meet Safeguard 17.7?

Safeguard 17.7 asks for routine exercises and scenarios at least annually. Annual is the minimum, not the target. Many organizations run smaller exercises more often, such as quarterly tabletop walkthroughs of a single scenario, and a fuller exercise once a year. The assessment specification scores completeness of the exercise documentation, so frequency matters less than a documented, repeatable cycle with dates, participants and scenarios recorded. Confirm with your assessor how they will count a year in which an exercise slipped by a few weeks.

Does a tabletop exercise count as an incident response exercise?

A tabletop can count if it tests the things Safeguard 17.7 names: communication channels, decision making and workflows for key personnel. A discussion-only session that never checks whether the contact list, backup channels or escalation path actually work is weaker evidence. Stronger programs combine a tabletop with a functional exercise, such as a simulated alert routed through the ticketing or case tool, or a test of the secondary communication channel. Ask your assessor which exercise types they accept and what artifacts they expect, such as the scenario, attendee list, injects, observations and follow-up actions.

How much staff time does an incident response exercise take?

Staff time depends on scenario complexity, the number of roles involved and whether the exercise is a discussion or a live test. The main cost components are planning (writing the scenario, injects and success criteria), the session itself with legal, IT, security, communications and business owners, and the write-up with corrective actions. Planning and write-up usually take more effort than the session. Recurring effort comes from keeping the process and contact lists current between cycles. No supplied figure sets a duration, so ask your team or a partner to estimate hours per role in writing before you commit calendars.

Must an outside partner run our incident response exercises?

No. Safeguard 17.7 does not require an external party. Your organization owns the incident response process, the exercise program and the evidence. Some organizations run exercises internally, while others bring in a partner to design scenarios, facilitate sessions or test technical workflows. An outside facilitator can add independence, but it adds cost and coordination. An implementation partner can prepare scenarios, runbooks and evidence templates, but only the organization can own the decisions and results. Independent auditors assess the outcome and issue any reports.

What will an auditor ask to see for Safeguard 17.7?

Expect requests for documented evidence that exercises are part of your incident response process. Typical items include the exercise plan or schedule, the scenarios used, dates and attendee lists for each run, the communication channels tested and results, observations and lessons learned, and records showing corrective actions were tracked to closure. The assessment specification treats the Safeguard as dependent on Safeguard 17.4, so an assessor will also look for a documented incident response process that the exercises test. Confirm the exact evidence set with your assessor before the cycle begins, because each framework that maps to 17.7 may request it differently.

Are open-source tools enough to run and record incident response exercises?

Open-source tools can cover much of the record keeping, and the exercise itself needs no special tooling. For case tracking, DFIR-IRIS keeps each case as one record of assets, IOCs, tasks and evidence with a full audit trail, can ingest alerts from SIEM, EDR and REST sources, builds an investigation timeline and generates reports from case data. These features help capture what happened during a simulated case. Confirm that a chosen tool fits your environment, data handling rules and integration needs, since DeployOpen does not claim a tool covers every communication or notification step by itself. Read the DFIR-IRIS documentation before deciding.

What does our team need to provide for exercises to work?

Your team needs to own the decisions that an exercise tests. That means named incident handling roles, a current contact list, documented communication channels, an agreed incident response process and senior sponsorship for scheduling. Your team also has to supply realistic system context for scenarios, access to the tools used in the exercise and people who will record observations. A partner can help design the scenario, run a test environment or document results, but the internal owner must approve the scope, act on findings and track corrective actions. Define these responsibilities in a written scope before work starts.

How DeployOpen works on this

DeployOpen plans, builds and hands over incident response exercises inside your own infrastructure, so the scenarios test your real communication channels, decision making and workflows. The work is scoped in writing before it starts, and the documentation is written so your team and an independent assessor can verify that exercises run at least annually.

How we scope

Agree in writing which key personnel, teams and third parties take part in each exercise
Confirm which incident response process from Safeguard 17.4 the exercises will test
Record the annual exercise cadence, owners and the evidence your assessor should expect

How we build

Design scenarios around your own communication channels, decision points and response workflows
Set up the case tooling, such as DFIR-IRIS, so exercise activity is recorded in the same way as live cases
Prepare exercise scripts, injects, observer checklists and the Completeness check against your documented components

How we hand over

Deliver exercise plans, run records, observations and corrective action lists in your document set
Walk your incident response lead through the scenarios so they can run future exercises
Confirm with your independent assessor which exercise records they need to verify the Safeguard

How we support

Offer ongoing support and scheduled exercises as a retainer after the fixed-scope work ends
Update scenarios when your architecture, vendors or response process change
Review each exercise's results so findings feed into the post-incident review process