FAQGlobalISO/IEC 27035

ISO/IEC 27035 FAQ

Plain-language ISO/IEC 27035 answers on events, incidents, roles, severity, escalation, evidence, notification, retention, review, and lessons learned.

ISO/IEC 27035 is voluntary guidance, not a law or standalone certification scheme. Validate legal, contractual, regulatory, and certification claims against the controlling source.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
FAQ modules
8

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

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

ISO/IEC 27035 treats an as something that indicates a possible breach or control failure, then calls for assessment before it is declared an incident. It organizes incident management into five phases: plan and prepare, detect and report, assess and decide, respond, and learn lessons. The series is voluntary guidance; it does not create legal notification deadlines, prescribe one team design, or provide standalone certification.

Browse sub-FAQs

Choose the question set you need

These focused FAQ modules break this artifact into narrower answer sets so teams can move straight to the right source-backed guidance.

Browse all FAQ items39
Focused FAQ modules
8
Showing 8 of 8
FAQ module

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.

4 items
FAQ module

ISO/IEC 27035 Escalation FAQ

Define ISO/IEC 27035 escalation and elevation triggers, authorities, handoff evidence, and reassessment rules before incidents occur.

5 items
FAQ module

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.

5 items
FAQ module

ISO/IEC 27035 Lessons Learned FAQ

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

5 items
FAQ module

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.

5 items
FAQ module

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.

5 items
FAQ module

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.

5 items
FAQ module

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.

5 items
Question 1

What should teams understand before using the ISO/IEC 27035 FAQs?

Use ISO/IEC 27035-1:2023 for the principles and five-phase process, ISO/IEC 27035-2:2023 for policy, plans, classification, teams, relationships, training, exercises, capability monitoring, and learning, and ISO/IEC 27035-3:2020 for ICT response operations.

Scale the guidance to the organization's size, structure, critical assets, risks, and business goals. Map separate laws, contracts, sector rules, privacy duties, evidence rules, continuity arrangements, and any ISO/IEC 27001 requirements explicitly.

Is ISO/IEC 27035 a law or a certification standard?

ISO/IEC 27035 is voluntary incident-management guidance. It does not create a legal duty, a universal notification deadline, or a standalone certification called "ISO/IEC 27035 certification." ISO/IEC 27001:2022 is the requirements standard for an information security management system, and ISO/IEC 27035 can support its incident-management controls. An organization should assess applicable laws, regulatory instructions, contracts, insurance terms, and continuity obligations separately.

Which edition and part of ISO/IEC 27035 should an organization use?

Use ISO/IEC 27035-1:2023 for the principles and five-phase management process, ISO/IEC 27035-2:2023 for policy, planning, teams, relationships, training, exercises, capability monitoring, and lessons learned, and ISO/IEC 27035-3:2020 for ICT response operations. Parts 1 and 2 are second editions published in February 2023. Part 3 is the first edition, published in September 2020, and ISO currently lists it at the close-of-review stage. Check the current ISO listing and any contract or management-system scope that specifies an edition before revising controlled procedures.

What is the difference between an and an incident?

An indicates a possible security breach or control failure. An information security incident is one or more related, identified events that can harm the organization's assets or compromise its operations. The incident coordinator applies criteria prepared in advance and records whether the event is a possible or confirmed incident or a false alarm. A failed login alert, for example, remains an event until assessment shows whether it is benign, a false positive, or part of harmful activity.

Does ISO/IEC 27035 cover non-ICT incidents?

ISO/IEC 27035-1:2023 provides a generic management process for ICT and non-ICT information security incidents, and ISO/IEC 27035-2:2023 provides generic preparation and learning guidance. ISO/IEC 27035-3:2020 is limited to ICT response operations. A lost paper document or theft of physical records can still be an information security incident, but Part 3 does not provide the operational response procedure for that case.

  • Start with event versus incident, then classify severity and assign the incident coordinator and response team.
  • Use the notification and retained-log answers only after identifying the controlling legal, contractual, or policy source.
  • Finish with post-incident review and lessons learned so findings change the plan and capability.
Question 2

What evidence shows that the incident process operates?

Keep the approved incident policy and plan, IMT and IRT assignments, classification scale, event-report forms, incident register, contact routes, training and exercise records, and capability measures. For completed cases, preserve the event report, assessment, classification, response log, decisions, communications, recovery and closure evidence, incident report, and lessons-learned actions.

The record should show what was known at each decision point, who acted or approved, which authority applied, how evidence was protected, and what follow-up remains. A document that describes the process without a completed case or exercise does not show that the process works.

What is the minimum evidence for one reported event?

Keep the event identifier, detection and reporting times, reporting source, affected asset or service, relevant circumstances and facts, validation work, criteria applied, incident or non-incident decision, decision owner, rationale, and disposition. If the event becomes an incident, link the event report to the incident log, register entry, response records, evidence items, communications, recovery checks, final incident report, and improvement actions.

How do the event report, incident log, incident report, and incident register differ?

The event report contains enough facts to assess whether an event is an incident. The incident management log preserves the dated chronology of actions and decisions for the case. The incident report synthesizes the information gathered across the incident lifecycle for evaluation and improvement. The centrally managed incident register gives the incident management team an organization-wide view of incidents, current status, follow-up, trends, and themes. Link the records with stable identifiers instead of collapsing them into one overwritten narrative.

Does ISO/IEC 27035 set an incident-record retention period?

ISO/IEC 27035 does not set one universal retention period. The organization should set retention and disposition from applicable law, regulatory rules, contracts, litigation or investigation holds, privacy requirements, evidentiary needs, and its records policy. Keep the applicable source, retention decision, owner, hold status, access restrictions, and authorized disposition with the record.

Does a hash prove chain of custody?

No. A hash can help show whether a digital item changed between two measurements, but it does not by itself prove lawful collection, authenticity, relevance, complete custody, or admissibility. A defensible evidence record also identifies the item and source, collector, method and tool, time, integrity value, storage, access, every transfer, analysis copies, and final disposition. ISO/IEC 27037 provides more detailed guidance for potential digital evidence.

  • Preparation: policy, plan, roles, delegated authority, contacts, classification criteria, communication rules, training, exercises, and monitoring.
  • Case handling: source facts, timestamps, assessment, severity, owners, actions, evidence, escalation, notifications, recovery, closure, and incident report.
  • Improvement: review findings, accepted actions, residual-risk decisions, owners, due dates, implementation evidence, and effectiveness checks.
Question 3

How should teams apply ISO/IEC 27035 in a repeatable workflow?

Capture an event report, assess it against prepared criteria, and decide whether it is a false alarm, an event for normal handling, or an information security incident. If it is an incident, assign the incident coordinator and required IRTs, set the response timer, classify and prioritize it, and activate the applicable response and communication procedures.

During response, reassess severity and scope as facts change, preserve decisions and evidence, escalate incidents that are not under control or exceed authority, and validate recovery with affected services. Close according to the policy, notify interested parties as required, then feed the incident report into lessons learned.

Who decides whether an event is an incident?

Under ISO/IEC 27035-1:2023, the incident coordinator evaluates the event report against criteria defined during planning and declares whether it is a possible or confirmed information security incident or a false alarm. The organization may use another title for the role, but it should define the person's authority, alternates, quality-review route, and handover requirements before an event occurs.

Does ISO/IEC 27035 prescribe severity levels or response times?

ISO/IEC 27035 calls for prepared criteria and a classification scale based on actual or projected adverse consequences, but it does not prescribe universal labels such as low, high, or critical, a mandatory scoring formula, or universal response times. The organization sets and tests its own criteria, target resolution times, authority limits, and reassessment intervals. Legal, regulatory, contractual, privacy, safety, and continuity triggers remain separate.

When should incident severity be reassessed?

Reassess severity whenever new information changes the incident's scope, business or technical impact, affected people or services, threat activity, recoverability, evidence risk, or possible external-reporting duties. Also reassess at the next time set in the incident record. Preserve the earlier rating and record the new facts, decision owner, rationale, actions, affected notifications, and next checkpoint.

When must an incident be reported outside the organization?

ISO/IEC 27035 does not create a universal external-reporting threshold or deadline. External reporting depends on the law, regulator, contract, insurer term, customer commitment, law-enforcement basis, or other rule that applies to the organization and incident. Record each possible duty separately with its source, scope test, trigger, clock start, recipient, required content, decision owner, approval, submission time, and update obligations.

Can technical recovery close an incident?

Technical recovery alone should not close an incident. The authorized owner should accept the restored service, system, or data against prepared recovery criteria, while the incident record assigns continuing monitoring, notifications, evidence preservation, investigation, residual risk, final reporting, and improvement work. The active response may conclude while controlled follow-up remains open, but the owner and status of that work must remain traceable.

  • Detect and report: collect source, time, affected assets or services, observations, and available supporting data.
  • Assess and decide: validate the event, apply prepared incident criteria, record the decision, and establish the required response teams.
  • Respond and learn: contain, eradicate, recover, communicate, close, review performance, and track approved improvements.
Question 4

How should teams review and improve ISO/IEC 27035 over time?

Reassess each live incident as additional information becomes available. After recovery, use post-incident activity suited to the incident's nature and severity, then review patterns across incidents, vulnerabilities, exercises, and capability measures.

Approved lessons should update the relevant policy, plan, classification criteria, controls, risk assessment, training, external relationships, resources, or management-review input. Track the change to implementation and check whether it worked.

When should the incident-management capability be reviewed?

Review the policy, plan, contacts, classification criteria, procedures, tools, team capability, and external relationships on the organization's planned cycle and sooner after an incident or exercise exposes a gap. Also review after material changes to services, technology, suppliers, threats, organizational structure, law, contracts, insurance, or continuity arrangements. Update contacts and authority limits as soon as roles change.

What should a lessons-learned review produce?

A lessons-learned review should produce documented findings about the incident and the response, justified changes to the plan, controls, risk assessment, training, tools, relationships, or team capability, and an owner, due date, acceptance criteria, and verification method for each accepted action. Test material process changes before they go live and use later exercises, control checks, or incidents to confirm that the change works.

Is closing a corrective-action ticket enough to show improvement?

No. Ticket closure shows that someone marked work complete; it does not show that the revised control or procedure works. Retain the implemented change, approval where required, test or exercise result, acceptance criteria, reviewer, remaining exception or residual risk, and the date of the next check. Feed repeated event and incident patterns from the incident register into risk assessment and management review.

  • Keep initial and revised decisions instead of overwriting history.
  • Assign an owner, due date, acceptance criteria, and closure authority to each improvement.
  • Use exercises and later incidents to verify important changes.
Primary sources

References and citations

iso.org
Referenced sections
  • Primary ISO listing for incident management principles and process.
"preparing for, detecting, reporting, assessing, and responding to incidents"
iso.org
Referenced sections
  • Primary ISO listing for planning, preparing, and lessons-learned guidance.
"plan and prepare for incident response and to learn lessons"
iso.org
Referenced sections
  • Primary ISO listing for ICT incident response operations guidance.
"information security incident response in ICT security operations"
iso.org
Referenced sections
  • Official ISO guidance for identifying, collecting, acquiring, and preserving potential digital evidence.
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 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 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 Threshold Mapping Guide
Map ISO/IEC 27035 incident reporting routes to separate legal, contractual, customer, supplier, insurer, and internal notification thresholds.
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.