FAQGlobalISO/IEC 27035

ISO/IEC 27035 FAQ Lessons Learned

Apply ISO/IEC 27035 lessons learned to plans, controls, risk decisions, training, relationships, metrics, and future response capability.

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

Lessons learned is the fifth ISO/IEC 27035 phase, not a meeting or final report. The uses evidence from incidents, related vulnerabilities, exercises, and recurring patterns to propose changes, route them to the proper owner, and verify whether approved changes improve the capability.

Search this module

Find a question or answer quickly

5 of 5 questions
Question 1

What should the ISO/IEC 27035 lessons-learned phase produce?

Analyse patterns across events and incidents as well as the individual case. Identify improvements to the incident plan, and performance, security controls, risk assessment, management review inputs, awareness, training, external relationships, tools, and metrics.

Prioritize improvements by risk, recurrence, and feasibility. A recommendation remains open until an accountable owner implements it and verifies effectiveness, or an authorized decision maker records why it was rejected, deferred, or accepted as residual risk, meaning the risk that remains after current controls and the approved decision.

  • Connect each lesson to the observation and incident evidence that supports it; examples include a delayed alert caused by a missing monitoring rule, an isolation delay caused by unclear authority, repeated supplier handoff failures, or a recovery test that did not cover a critical dependency.
  • Track actions with owner, priority, due date, dependency, success measure, closure evidence, and residual risk.
  • Use exercises and later incidents to verify that the change improved capability rather than only changing documentation.
Citations
Question 2

What evidence should connect a lesson to action?

Link each lesson to the incident report, timeline, exercise observation, vulnerability, metric, or repeated event pattern that supports it. Keep the proposed change, affected control or plan element, risk, owner, priority, due date, dependency, approval, implementation evidence, and effectiveness result.

Preserve decisions not to act. The record should identify the decision authority, rationale, residual risk, review trigger, and any compensating action instead of making the recommendation disappear.

  • Distinguish an observation, a proposed lesson, an approved action, and a verified improvement.
  • Use version-controlled plan, playbook, control, training, contract, or tool changes as implementation evidence.
  • Verify high-risk changes through an exercise, control test, later incident, or another suitable measure.
Citations
Question 3

Who should own and approve lessons learned?

The incident coordinator and should assemble the evidence and propose improvements. The owner who controls the affected system, process, supplier, control, budget, or policy should accept the action; the relevant risk or management authority should approve rejection, deferral, or residual risk.

Include affected responders and business owners when validating the finding. Legal, privacy, human resources, communications, safety, continuity, or supplier owners should join only when the lesson falls within their responsibility.

  • Assign one owner for each action even when several teams contribute.
  • Escalate overdue or disputed high-risk actions to the forum that can fund work or accept risk.
  • Keep approval and closure evidence with the action record.
Citations
Question 4

When should lessons be identified and verified?

Begin after the incident is resolved and enough evidence is stable for useful analysis. Do not wait for one large incident: ISO/IEC 27035 also supports learning from multiple incidents, reported vulnerabilities, exercises, and performance data.

Review open actions at planned intervals and when their assumptions, risk, owner, dependency, or target system changes. Close an action only after checking the agreed acceptance criteria and recording the result.

  • Aggregate recurring weak signals that do not justify separate major reviews.
  • Feed unresolved material items into risk management or management review.
  • Reopen a closed lesson when later evidence shows that the change did not work.
Citations
Question 5

What is the scope and cadence of the ISO/IEC 27035 phase?

ISO/IEC 27035-1:2023 makes learning lessons part of the generic incident-management process for organizations of any type, size, or nature. ISO/IEC 27035-2:2023 provides the detailed improvement activities: review the plan, evaluate team performance, improve control implementation, update risk assessment and management-review inputs, strengthen awareness and training, and improve relationships, tools, and metrics. ISO/IEC 27035-3:2020 supplies operational evidence from ICT response.

The standards do not prescribe a universal meeting deadline, review period, action due date, or closure threshold. The organization should set a cadence proportional to incident risk and capability needs. A severe or novel incident can justify an immediate review; recurring low-impact events can be aggregated; urgent containment and control fixes should proceed without waiting for the full lessons cycle.

  • Apply the edition named by the organization's policy, adoption decision, contract, or management-system scope.
  • Trigger an out-of-cycle review after a material incident, failed exercise, repeated classification error, supplier failure, or significant change to services, risks, law, or authority.
  • Keep an action open until implementation and effectiveness are evidenced, or the authorized owner records rejection, deferral, or accepted residual risk with a review trigger.
Citations
Primary sources

References and citations

iso.org
Referenced sections
  • ISO identifies Part 1:2023 as the generic incident-management foundation and includes applying lessons learned in the process.
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 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 Post Incident Review FAQ
Run an ISO/IEC 27035 post-incident review after stabilization and recovery, then assign measurable improvements without losing accountability.
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.