FAQGlobalISO/IEC 27035

ISO/IEC 27035 FAQ Post Incident Review

Run an ISO/IEC 27035 post-incident review after stabilization and recovery, then assign measurable improvements without losing accountability.

ISO/IEC 27035 is voluntary guidance, not a law or standalone certification scheme. Apply separate legal, contractual, regulatory, privacy, and evidence requirements where relevant.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

A post-incident review reconstructs what happened, tests how decisions and controls performed, and identifies supported changes. The is a primary input, while the broader ISO/IEC 27035 lessons-learned phase also updates plans, controls, risk assessments, training, relationships, tools, metrics, and team capability.

Search this module

Find a question or answer quickly

5 of 5 questions
Question 1

How should a post-incident review be run?

After recovery, create a timeline from event and incident records and compare actual detection, assessment, decisions, response, communications, recovery, and evidence handling with the plan. Include the incident coordinator, relevant responders, affected business or service owners, providers, control owners, and the members needed to route improvements.

The depth should match the incident's nature and severity. Separate urgent remediation from longer-term improvements, and record unresolved facts rather than forcing a final cause. Each action needs a risk-based priority, owner, due date, acceptance criteria, dependency, evidence, and closure authority.

  • Review what worked as well as failures, including informal adaptations worth formalizing; for example, a monitoring rule that detected lateral movement, an emergency authority that allowed timely isolation, or a supplier handoff that delayed recovery.
  • Address technical, process, people, supplier, communications, legal, continuity, and evidence issues.
  • Feed conclusions into the incident plan, playbooks, risk assessment, controls, training, exercises, metrics, and management review.
Citations
Question 2

What should the post-incident review record contain?

Keep the reviewed timeline, participants, evidence consulted, scope and limitations, confirmed findings, unresolved questions, causes and contributing conditions where supported, what worked, failed controls or handoffs, and recommended actions. Link the review to the without duplicating sensitive evidence unnecessarily.

Distinguish facts from hypotheses and recommendations. If legal privilege, personnel confidentiality, law-enforcement restrictions, or supplier terms limit circulation, retain a controlled full record and an appropriate operational version rather than omitting the limitation.

  • Reconcile conflicting timestamps and identify the clock source used.
  • Record who validated each material finding and what evidence supports it.
  • Move approved actions into the normal system used to track owners, due dates, evidence, and closure.
Citations
Question 3

Who should lead and approve the review?

The incident coordinator should ensure the post-incident activity occurs and that the is complete. A reviewer with enough independence to challenge the response should lead or validate significant reviews, while affected teams confirm factual accuracy.

The owner with authority over each affected control, service, supplier, policy, or budget should accept the related action. The appropriate risk or management authority should approve rejected, deferred, or residual-risk decisions.

  • Separate factual validation from approval of corrective action.
  • Avoid assigning final approval only to the team whose performance is being reviewed.
  • Record disagreements and the authority that resolved them.
Citations
Question 4

When should a post-incident review occur and close?

Start after recovery when the incident's nature and severity justify a dedicated review and the essential records and participants are available. Immediate containment or safety actions should not wait for the review, and a complex investigation may require an interim review before all facts are final.

The meeting or report can close once its scope, evidence limits, findings, and actions are approved. Corrective actions remain open in their tracking system until implemented, evidenced, and checked against their acceptance criteria.

  • Set a review trigger by incident type and severity rather than requiring the same ceremony for every event.
  • Reopen findings when later forensic, supplier, regulator, or recovery evidence changes the analysis.
  • Aggregate minor incidents when a pattern offers more useful evidence than separate reviews.
Citations
Question 5

How does a post-incident review fit the ISO/IEC 27035 editions?

ISO/IEC 27035-1:2023 defines the generic process and its records, including the incident-management log and . ISO/IEC 27035-2:2023 provides the detailed lessons-learned activities for the plan, teams, controls, risk assessment, management review, training, relationships, tools, and metrics. ISO/IEC 27035-3:2020 provides ICT operational evidence from notification, triage, analysis, containment, eradication, recovery, and reporting.

The standards apply globally to organizations of any type, size, or nature and can be adapted to risk and resources. They do not require the same meeting for every event, prescribe a fixed review deadline, or create legal privilege. The organization should define which incident types, severity levels, near misses, failed exercises, or recurring patterns trigger a dedicated review and should apply separate employment, privacy, litigation, regulatory, contractual, and evidence rules.

  • Record the edition and procedure version applied to the review.
  • Start urgent remediation immediately; do not hold a known containment or safety fix for the review meeting.
  • Reassess findings when later forensic, supplier, regulator, legal, or recovery evidence changes a material fact or assumption.
Citations
Primary sources

References and citations

Related guides

Explore more topics

ISO/IEC 27035 Compliance Guide
Understand what the ISO/IEC 27035 series covers, how its three published parts fit together, and how to adopt the guidance without mistaking it for a law or certification scheme.
ISO/IEC 27035 CSIRT Roles FAQ
Assign ISO/IEC 27035 incident coordinator, IMT, IRT or CSIRT, point-of-contact, evidence, communications, and business decision roles.
ISO/IEC 27035 Escalation FAQ
Define ISO/IEC 27035 escalation and elevation triggers, authorities, handoff evidence, and reassessment rules before incidents occur.
ISO/IEC 27035 Event vs Incident FAQ
Distinguish an information security event from an incident under ISO/IEC 27035 and record the assessment without discarding useful event evidence.
ISO/IEC 27035 Evidence Log Template
Use an ISO/IEC 27035-aligned incident log to preserve facts, decisions, actions, communications, evidence references, and chain-of-custody information.
ISO/IEC 27035 Incident Lifecycle Guide
Follow the ISO/IEC 27035 five-phase incident-management process and understand how the detailed ICT response loop fits inside it.
ISO/IEC 27035 Incident Lifecycle Workflow
Turn the ISO/IEC 27035 lifecycle into an operational workflow with explicit decisions, handoffs, owners, evidence, and reopening triggers.
ISO/IEC 27035 Incident Management FAQ
Plain-language ISO/IEC 27035 answers on events, incidents, roles, severity, escalation, evidence, notification, retention, review, and lessons learned.
ISO/IEC 27035 Incident Response Playbook
Build ISO/IEC 27035-aligned playbooks that guide detection, triage, analysis, containment, eradication, recovery, reporting, and evidence preservation.
ISO/IEC 27035 Incident Severity and Escalation Matrix
Design an ISO/IEC 27035-aligned severity and escalation matrix using impact, priority, damage, urgency, recoverability, and reporting triggers.
ISO/IEC 27035 Incident Timer Workflow
Create an incident clock that tracks operational checkpoints and separate legal or contractual deadlines without inventing ISO/IEC 27035 time limits.
ISO/IEC 27035 Lessons Learned FAQ
Apply ISO/IEC 27035 lessons learned to plans, controls, risk decisions, training, relationships, metrics, and future response capability.
ISO/IEC 27035 Notification Evidence FAQ
Preserve evidence for internal and external incident notifications without attributing legal deadlines or reporting duties to ISO/IEC 27035.
ISO/IEC 27035 Notification Threshold Mapping Guide
Map ISO/IEC 27035 incident reporting routes to separate legal, contractual, customer, supplier, insurer, and internal notification thresholds.
ISO/IEC 27035 Retained Logs FAQ
Retain ISO/IEC 27035 incident logs and digital evidence according to purpose, investigation needs, law, contracts, privacy, and organizational policy.
ISO/IEC 27035 Severity Classification FAQ
Classify incident severity under ISO/IEC 27035 using organization-specific criteria and reassess it as facts, impact, and recoverability change.
ISO/IEC 27035 vs ISO 22301 Comparison
Compare ISO/IEC 27035 incident-management guidance with ISO 22301 business continuity management-system requirements and certification scope.
ISO/IEC 27035 vs NIS2 Comparison
Compare voluntary ISO/IEC 27035 incident-management guidance with binding NIS2 duties for in-scope EU entities and national implementation.
ISO/IEC 27035 vs NIST SP 800-61 Comparison
Compare ISO/IEC 27035 with the current NIST SP 800-61 Rev. 3 while preserving this legacy route for visitors using the older publication name.
ISO/IEC 27035 vs NIST SP 800-61 Rev. 3 Comparison
Compare the ISO/IEC 27035 series with NIST SP 800-61 Rev. 3 incident-response guidance and show how organizations can use both.