Safeguard 17.8 Post-incident reviews: requirements and evidence

What CIS Safeguard 17.8 post-incident reviews require

Safeguard 17.8 asks the enterprise to run post-incident reviews that capture lessons learned and follow-up actions, so that the same failures do not happen again. It sits in Implementation Group 2, so an IG2 or IG3 enterprise must show that its incident response improves over time, not only that incidents get handled. CIS v8.1 places the Safeguard in the Users asset class and the Recover security function, which signals that the review is about restoring trust in how people and processes behaved during an incident, feeding back into the response process itself. IG1 enterprises do not have to meet it, but many will benefit from a simple version of the same habit.

The Safeguard depends on Safeguard 17.4, the documented incident response process. The CIS Controls Assessment Specification lists 17.4 as a prerequisite for measuring 17.8, so a review has nothing to test against if the response process is not written down. The assessor's first question is whether post-incident reviews appear in the documented process at all, and a missing review step fails the Safeguard outright. The second is completeness: the Assessment Specification measures the share of components included in reviews during incident response exercises. The reader should confirm with their team which components (systems, business units, vendors, and decision points) must be covered, then check that a sample of recent exercises shows reviews reaching each one.

What makes this Safeguard hard is rarely the meeting itself. Teams hold reviews, write a summary, and move on, while the follow-up actions drift without owners, due dates or closure evidence. An assessor will look for the trail from finding to action to verified fix, and a review record with open items from a year earlier signals that the Safeguard is not operating. Before scoping any help, the enterprise should decide who owns each action, where actions are tracked, and how closure is verified. Case management and documentation tools can hold that trail, but the enterprise still owns the process and the decisions.

Which incidents, teams and third parties a post-incident review must cover

Safeguard 17.8 is only as good as the boundary drawn around it. The decisions below set which incidents trigger a review, who must attend, whether provider incidents count and how exercises feed the Completeness metric the CIS assessment specification uses.

Incident classes that trigger a review

Start from the incident thresholds you defined under Safeguard 17.9, which separate events from incidents. Any incident that crosses the threshold should trigger a review, and so should near misses that exposed a gap in detection or response. Write the trigger list down so a review is not optional after a serious case. Confirm that low-severity incidents are either reviewed in batches or explicitly excluded, so the decision is documented rather than assumed.

Internal teams that must attend

A review that involves only the security team misses most of the lessons. Include the incident handling lead named under Safeguard 17.1, the responders and analysts, IT operations, and the owners of the affected systems. Legal, communications, HR and facilities should attend when their roles were engaged under Safeguard 17.5. Record attendance in the review report so an assessor can see the roles that were represented.

Third parties and service provider incidents

Decide in advance whether incidents at service providers that hold your data or run your platforms are reviewed. Where the provider caused or handled the incident, invite their representative to contribute and request their root cause analysis under your contract. Your internal review should still cover how your own monitoring, escalation and contract terms performed. Confirm this approach matches the provider requirements you set under Control 15.

Exercises as review inputs

The Completeness metric measures the share of components included in post-incident reviews held during incident response exercises. This means a tabletop or simulation should produce a documented review, not just a debrief. Define which components, such as detection, escalation, communication channels and decisions, must appear in each exercise review. Track the inclusion rate across exercises so the measure can be shown to an assessor as a number, not an impression.

Evidence that the scope was applied

The review scope should be written into the documented incident response process that Safeguard 17.4 requires, and the process must include post-incident reviews for the assessment to pass. Keep a register of incidents and exercises with a yes or no for whether a review was held. Gaps in that register are the first thing an assessor will test. Record the reason whenever a qualifying incident is not reviewed.

How an assessor tests Safeguard 17.8

This table walks through the steps an assessor follows under the CIS Controls Assessment Specification for Safeguard 17.8, from the prerequisite check to the Completeness measure. Read it as a checklist of what to have ready before an assessment starts, since the assessor tests what exists rather than designing the review process.

Assessment step	What the assessor checks	Evidence to prepare
Prerequisite check	Confirms Safeguard 17.4 (incident response process) is established, because the specification lists it as a prerequisite for measuring 17.8	Current incident response process document with approval date and owner
Documented process	Looks for post-incident reviews written into the documented process; a process with no review step fails outright	Process section or runbook showing when a review is triggered, who leads it and what it produces
Sample of reviews	Selects recent reviews, or reviews from incident response exercises, and reads them for lessons learned and follow-up actions	Review reports, meeting records and exercise debrief notes from the assessment period
Completeness measure	Calculates the share of components (systems, teams, third parties or processes) that were included in post-incident reviews during exercises	Exercise scenario list, participant roster and a component inventory to compare against
Follow-up tracking	Checks that each action item has a named owner, a status and a closure record, not only a list of observations	Action register or ticket export linked to each review, with closure dates
Common findings	Reviews that record no follow-up owners, actions never closed, or components missing from exercise reviews	Ask for a self-check against these gaps before the assessor arrives
Role boundaries	The assessor tests whether the review practice exists and works; the organization designs and runs it	Confirm internal ownership of the review process before any outside help is engaged

How to set up post-incident reviews that pass

This sequence turns Safeguard 17.8 into a documented, repeatable review practice that produces lessons learned, tracked actions and evidence an assessor can sample. Each step ends with an artifact you can show, so the work is provable rather than assumed.

Document the review step in the 17.4 process
Add a post-incident review stage to the incident response process you already maintain under Safeguard 17.4, which the assessment specification lists as a prerequisite for measuring 17.8. Name who starts the review, when it happens after containment and recovery, and where its outputs are stored. Owner: the incident handling lead named under 17.1, with sign-off from the security leadership. Output: a versioned process document with a dedicated review section that an assessor can locate without help.
Define a review template and trigger criteria
Build a standard template covering the incident timeline, detection and response decisions, communication effectiveness, root cause, control gaps and recommended actions. Then write the trigger criteria: which incidents, near misses and exercises always get a review, and which may be reviewed at the incident handling lead's discretion. Owner: the incident handling lead with the security team. Output: an approved template and a written trigger list, so every qualifying event has a known reason for review or for not reviewing.
Assign a facilitator and scribe
For each review, name a facilitator who is not the primary responder, so the discussion can challenge decisions without defending them, and a scribe who records findings in the template as they arise. Keep a standing roster of trained people so reviews do not wait on one individual. Output: a named facilitator and scribe on the review record before the meeting is scheduled, with the roster kept current in the incident response records.
Run reviews after real incidents and exercises
Hold the review once response activity has ended and the facts are reasonably settled, bringing in the responders, the affected system owners and, where roles were involved, representatives from legal, communications, HR or facilities as set out in 17.5. Walk the timeline against the process, and record disagreements rather than forcing consensus. Output: a completed template with a timeline, findings and the attendance list, filed with the incident record. Exercise reviews follow the same steps and feed into 17.7.
Record lessons and actions with owners and due dates
Convert each finding into a lesson and, where a change is needed, a discrete action with one named owner and a due date. Separate immediate containment fixes from process, tooling and training changes so they can be tracked independently. Link each action to the incident record and, where relevant, to the affected asset or Safeguard. Output: an action register entry for every finding that requires change, with owner, due date and status fields populated.
Track closure and verify the fix
Review open actions on a set cadence chosen by the organization, escalate overdue items to the owner's management, and close an action only when evidence shows the change is in place, such as an updated runbook version, a tested alert rule or a completed training record. Output: a closure record per action showing the evidence reviewed and the date verified. Open and overdue counts should be reported to the governance forum.
Feed results into incident response exercises
Use the recurring lessons and unresolved gaps from reviews to design the scenarios for the 17.7 exercises, so the next exercise tests the changes made and the weaknesses still open. Record which review findings each exercise addressed. Output: exercise plans that cite specific review records, closing the loop between 17.7 and 17.8 and giving an assessor a traceable path from incident to lesson to test.

Evidence that shows post-incident reviews happen and drive change

An assessor needs to see that post-incident reviews are written into the process, actually held after incidents and exercises, and followed by completed changes. The cards below cover the records that prove each step, and how to keep them current between audits so they reflect what happened rather than what was planned.

Documented incident response process

The written process is the first thing to show, because Safeguard 17.8 is scored against it and a documented process with no post-incident review step fails. Check that the process names who convenes a review, when it is triggered, which incidents and exercises are in scope, and where outputs are stored. It depends on Safeguard 17.4, so confirm that the review step sits inside the process that 17.4 describes.

Review reports with timelines and attendees

Each review should produce a report that records the incident timeline, the decisions made, the people present and the date of the session. The attendee list shows that the right roles took part, such as the incident lead, IT, legal and communications. Ask for reports from at least one real incident or exercise, because an assessor will test whether reviews happen in practice.

Lessons-learned register

A register holds each lesson as its own entry with a root cause, the affected components, the owner and a status. It lets an assessor trace a lesson from the review that raised it to the change that addressed it. Keep entries even when no change was made, and record the reason, so the register shows judgment as well as action.

Action tracker with closure proof

Follow-up actions need an owner, a due date and closure evidence, such as a changed runbook, a patched configuration or a new detection rule with a link to the change record. Most review findings fail at this step, so sample a few closed items and confirm the evidence supports the closure. Open items past due should carry a documented reason and a revised date.

Exercise review records

Safeguard 17.8 counts components included in reviews held after exercises, so exercise debriefs are a direct source of evidence. Keep the exercise scenario, the participants, the observed gaps and the review output together. Confirm that the Safeguard 17.7 exercise cadence produces debriefs that feed the same register, rather than sitting in a separate folder.

Version history of process and reports

Version history shows when the process, templates and review records were edited, by whom and what changed. This matters when an assessor asks whether the review step was added after an audit or has existed for the whole period. Confirm that your wiki or document system keeps prior versions and that edits can be traced to a named person.

What meeting Safeguard 17.8 costs in money and effort

This table breaks down the cost components of running post-incident reviews under Safeguard 17.8, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to separate setup work from the effort that repeats after every incident. No prices or durations are given because none are supplied for this Safeguard; confirm them in writing.

Cost component	Who pays or does the work	One-time or recurring	What drives it up or down
Review process and templates	Internal incident response lead, with legal and compliance input	One-time, revised when the process changes	Number of business units in scope and how many incident types the review template must cover
Staff time for each review	Incident responders, the incident handling lead and affected system owners	Recurring, every review	Incident volume, complexity of each incident and how many people must attend
Writing and approving the report	Incident lead writes it; management or the CISO approves it	Recurring, every review	Depth of the root cause analysis and whether the report must meet regulator or contract deadlines
Tracking tool setup and upkeep	Internal IT or security engineering, or an implementation partner	Setup is one-time; upkeep is recurring	Choice of case or ticketing system, integrations with existing tools and the number of open actions
Follow-up action effort	Action owners across IT, operations and the business	Recurring until each action closes	How many actions each review produces and how well owners are assigned at the meeting
Exercise time feeding reviews	Key personnel and exercise planners tied to Safeguard 17.7	Recurring, at least annually per the exercise cycle	Exercise frequency, scenario complexity and how many lessons each exercise generates
External facilitation or review	Outside facilitator or consultant, paid per written scope	Usually one-time for setup, optional per review	Whether internal staff can facilitate neutrally and how many reviews need outside challenge. Ask for a fixed scope and deliverables
Assessor sampling effort	Internal staff produce evidence; an independent assessor samples it	Recurring at each assessment cycle	Number of incidents sampled, how cleanly reviews are stored, and how quickly evidence can be retrieved
Open-source tooling licences	No licence fee for the open-source platform itself; infrastructure and support are still paid	Infrastructure recurring; licence spend can be removed	Hosting choice, support model and whether the platform needs customization. Ask the vendor or partner to confirm license terms

Which self-hosted open-source tools support post-incident review evidence

DFIR-IRIS is an open-source case management platform for incident response, licensed under LGPL-3.0-or-later. For Safeguard 17.8, its main value is that the incident record used during response can carry through to the review. Each case is kept as one record that holds assets, indicators of compromise, tasks and evidence, so the review can point back to the same source material instead of a reconstructed account.

Audit trail: Changes to a case are logged with a full audit trail, which lets reviewers see what was recorded and when during the incident.
Consolidated timeline: The platform builds an investigation timeline from case data, a useful starting point for the timeline section of a post-incident review.
Evidence handling: Evidence is logged with SHA-256 verification and chain of custody, which helps show that artifacts reviewed later are the ones collected.
Report generation: Reports are generated from case data, so the review can draw on recorded facts rather than memory.
Alert intake: Alerts from SIEM, EDR and REST sources can be triaged into cases, linking the review to the original detection.

The platform records the investigation, but it does not decide what the lessons learned are or track follow-up actions to closure unless your process adds that. Confirm in your environment which fields and tasks your team will use for review actions, and whether the LGPL-3.0-or-later license terms fit how you plan to modify or distribute the software.

Where post-incident reviews usually fall short

Most organizations hold some form of post-incident discussion, so the gaps under Safeguard 17.8 are rarely about whether a meeting happens. They appear in the documented process, the written record, the follow-up actions and the places where lessons should flow next. Each card below names one gap and the step that closes it.

No review step in the process

The assessment specification fails an enterprise that has no post-incident reviews in its documented process, so this gap is a paperwork failure with a practical cause. Reviews often happen informally after a major incident and nowhere else. Check that the incident response process, which Safeguard 17.4 requires as a prerequisite, names the review step, who triggers it, who attends and the deadline for holding it. Closing it means writing the step into the process and naming an owner for it.

Reviews held but not written up

A review that exists only in someone's memory cannot show an assessor what was learned. Meetings without minutes, timelines or a recorded set of findings produce no evidence, even when the discussion was good. Check whether every review ends with a written record that covers the incident timeline, the root causes and the lessons identified. Closing this gap usually means a fixed template that the incident lead completes before the review is closed, stored in a system that keeps earlier drafts.

Actions without owners or closure

Lessons only prevent recurrence when someone carries them out. Follow-up actions with no named owner, no due date or no closure record tend to stall after the meeting. Check that each action has one accountable person, a target date and a status that is updated until the change is verified. Closing this gap means tracking actions in the same case or task system as the incident, so open items stay visible to the people who review the program.

Lessons not fed into exercises or thresholds

Safeguard 17.8 sits alongside Safeguard 17.7 on exercises and Safeguard 17.9 on incident thresholds, and the lessons from a review should change both. When a review finds that an event was escalated too late or a scenario was missing from the exercise plan, the finding should appear in the next exercise design or threshold definition. Check whether the exercise calendar and the threshold document reference recent review findings. Closing this gap requires a named step where review outcomes are sent to the owners of those documents.

Reviews skipped for third-party incidents

Incidents at a cloud provider, managed service or software supplier often affect the enterprise without occurring inside its own estate, and teams sometimes assume a review is unnecessary. Yet the enterprise still owns the response, the customer communications and the decisions about its own systems. Check whether the review scope covers incidents reported by service providers and whether the incident lead can require a review when the enterprise was affected. Closing this gap means stating in the process that third-party incidents trigger a review, with the same record and action tracking as internal ones.

No version history for review records

Review records are often edited after the fact, especially when a regulator, insurer or auditor asks questions months later. Without version history, an organization cannot show what the record said when the review closed or who changed it. Check whether the review documentation keeps each revision with its author, date and the differences between versions, and whether earlier versions can be restored. Closing this gap means storing review records in a wiki or document system that keeps version control, or in a case platform with a full audit trail.

Questions buyers ask about Safeguard 17.8

Does Safeguard 17.8 apply to IG1 organizations?

No. Safeguard 17.8 is assigned to Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 covers essential cyber hygiene as a minimum standard, and its incident response basics sit in Safeguards 17.1 to 17.3. An IG1 organization can still run a review after an incident as good practice, but the assessment specification does not measure it against 17.8. Confirm your Implementation Group against the CIS Implementation Groups pages before scoping work, since it determines which Safeguards your assessment covers.

Do we need an outside partner to run post-incident reviews?

No. The organization owns its incident response process and runs its own reviews, and CIS does not require an external party. A partner becomes useful when the team lacks experience facilitating root cause analysis, when the review needs to be documented in a form an assessor will accept, or when the internal team is too close to the incident to review it objectively. An implementation partner can prepare review templates, workflows and evidence stores, but it cannot issue a compliance opinion. Only an independent assessor or auditor tests the control and reports on it.

How long does a post-incident review take?

The duration depends on the incident, and no fixed figure applies across organizations. The main drivers are the number of systems and people involved, how well the timeline was recorded during response, whether the root cause is clear, and how many follow-up actions need owners and due dates. A review of a contained phishing event with good notes will be far shorter than one covering a multi-system intrusion. Ask any provider to estimate effort against a written scope with the incident types you expect, and ask how the review records are kept so the next review is faster.

What does the work need from our team?

The review needs the people who ran the response, plus owners of the affected systems and, where relevant, legal, communications and management. In practice, the team must:

Reconstruct the incident timeline from logs, tickets and chat records.
Identify what worked, what failed and where decisions were delayed or unclear.
Agree on the root cause and the contributing conditions.
Assign follow-up actions with owners, deadlines and a way to verify they were completed.

The review should also update the response process and the relevant runbooks, so the lessons reach the people who will handle the next incident.

Do we need self-hosted tools to run post-incident reviews?

No. Safeguard 17.8 requires a documented, repeatable review process, not a particular product. Many organizations run reviews with a ticketing system and a document repository. Self-hosted open-source tools can help when you want records to stay inside your own infrastructure. DFIR-IRIS keeps each case as one record with a full audit trail and a consolidated timeline, which supports reconstructing the incident. XWiki keeps version history of review documents, showing what changed, when and by whom. Confirm each tool's capabilities against its documentation before relying on it for evidence.

How does Safeguard 17.8 relate to 17.4 and 17.7?

Safeguard 17.4 is a prerequisite. The CIS Controls Assessment Specification lists the establishment of an incident response process as the basis for measuring 17.8, so reviews must be part of a documented process. Safeguard 17.7 covers incident response exercises, and the assessment specification measures 17.8 by the share of components included in post-incident reviews during those exercises. In practice, exercises give you a low-risk way to test the review step, and the lessons from them should feed the same follow-up tracking used for real incidents.

Does CIS certify that we comply with Safeguard 17.8?

No. CIS publishes the Controls and the Assessment Specification, but it does not certify organizations. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. Assessment against 17.8 is performed by an independent assessor or auditor who tests the documented process and the review evidence. Your own team can self-assess using the specification, and a partner can prepare the evidence. Only the independent assessor's report or attestation, issued under the scheme your contract requires, carries that weight with customers and regulators.

How DeployOpen prepares post-incident review evidence

DeployOpen's part in Safeguard 17.8 is to prepare the systems, templates and evidence trails that let your team run post-incident reviews and show they happened. The organization owns its controls and decides what a review must cover. Before any build work starts, DeployOpen scopes the review process in writing: which incident classes trigger a review, who attends, which components of the affected environment must be included, how findings become tracked follow-up actions, and how the output feeds back into the documented incident response process that Safeguard 17.4 requires. Because the CIS Controls Assessment Specification measures the share of components included in reviews run during exercises, the scope should name those components explicitly so the measurement can be repeated.

DeployOpen then configures self-hosted open-source tools inside your own cloud accounts, data centers or air-gapped network. DFIR-IRIS can hold each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail and a consolidated timeline that a review team can walk through. XWiki or BookStack can hold the review template, the lessons learned and the action register. XWiki keeps version history of every page, so an assessor can see what changed, when and by whom, and BookStack permissions can be set per role at shelf, book, chapter or page level so that reviewers edit and the wider workforce reads. Confirm with your own assessor which retention period and access model satisfy your evidence needs before you configure either tool.

DeployOpen can also support testing of the review process through its security testing and cyber range services, for example by running an exercise scenario and checking whether the review captures every component in scope and produces tracked follow-up actions. Ask for the written scope, the list of deliverables and the evidence samples before agreeing to any work. An independent auditor or certification body is the only party that issues reports or certificates, so the evidence set should be designed for that assessor's testing, not for DeployOpen's sign-off.

Safeguard 17.8 Post-incident reviews