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 is voluntary guidance, not a law or standalone certification scheme. Validate legal, contractual, regulatory, and certification claims against the controlling source.
NIST SP 800-61 Rev. 3 superseded Rev. 2 in April 2025 and expresses its recommendations as a . This legacy route therefore compares ISO/IEC 27035 with Rev. 3, not with the older four-phase NIST model. Use Rev. 2 only for historical records or migration. Neither publication creates a universal reporting deadline or standalone certification.
Side-by-side comparison
ISO/IEC 27035 vs NIST SP 800-61: scope, duties, evidence, and decision rule
This comparison maps the ISO/IEC 27035 series to the current NIST SP 800-61 Rev. 3 ; Rev. 3 supersedes the older Rev. 2 lifecycle guidance.
ISO/IEC 27035 provides a five-phase process in Part 1, preparation and learning guidance in Part 2, ICT response operations in Part 3, and multi-organization coordination guidance in Part 4.
Second framework
NIST SP 800-61
This route describes the current NIST SP 800-61 Rev. 3, an April 2025 that supersedes Rev. 2.
ISO/IEC 27035 vs NIST SP 800-61: scope, duties, evidence, and decision rule
Choose ISO/IEC 27035 when the question is how to build and run an information security incident management process. Choose NIST SP 800-61 when the question is how to apply cybersecurity incident response recommendations inside a CSF 2.0 risk-management program.
ISO/IEC 27035 ownership should sit with incident management leadership, the Incident Management Team, Incident Response Team, security operations, risk owners, and managers who can approve lessons learned.
NIST SP 800-61 ownership should map to incident response leadership, incident handlers, technology professionals, legal, public affairs, asset owners, and contracted response providers where they support the response.
Assign the people who operate and authorize the process. Use ISO/IEC 27035 to define incident-management roles and NIST SP 800-61 Rev. 3 to map broader internal and third-party participation.
Readiness precedes an incident; reported events are assessed against organization-defined criteria and then closed or handled through the five-phase process.
Preparation and lessons learned sit across Govern, Identify, and Protect. Potentially adverse events are analyzed through Detect to determine whether they meet defined incident criteria; once an incident is declared, the response plan is executed and applicable Respond and Recover outcomes follow.
NIST SP 800-61 organizes incident response as cybersecurity risk management guidance within the , including preparation, detection, response, recovery, and lessons learned.
Use ISO/IEC 27035 for the management-system backbone: policy, roles, process, records, and review. Use NIST SP 800-61 for incident-response recommendations that fit a CSF 2.0 based risk-management model.
ISO/IEC 27035 records include policy and plan, team authority, event and incident reports, the incident register, assessment and priority decisions, response logs, evidence, communications, closure, and lessons.
Keep one chronology and evidence store where possible. Preserve the NIST revision used by historical records, then tag current ISO phases and Rev. 3 CSF outcomes without rewriting history.
ISO/IEC 27035 adoption can be evaluated through exercises, internal audits, customer assurance, management review, and governance review; the guidance itself is not a standalone certification scheme.
NIST SP 800-61 Rev. 3 is guidance, not a certification scheme or statute. Other laws, government policies, contracts, or customer requirements may separately require its use or particular incident practices.
Evaluate implementation against the chosen profile and operating evidence. Test legal and contractual compliance against the controlling sources rather than inferring it from NIST alignment.
Rev. 3 can map the same records to governance, asset and supplier context, detection, analysis, response, recovery, communications, and improvement outcomes.
Reuse the record when it represents the same event and decision. Preserve its original NIST revision and add missing current mappings instead of duplicating the incident.
Choose ISO/IEC 27035 when the question is how to build and run an information security incident management process. Choose NIST SP 800-61 when the question is how to apply cybersecurity incident response recommendations inside a CSF 2.0 risk-management program.
ISO/IEC 27035 ownership should sit with incident management leadership, the Incident Management Team, Incident Response Team, security operations, risk owners, and managers who can approve lessons learned.
NIST SP 800-61 ownership should map to incident response leadership, incident handlers, technology professionals, legal, public affairs, asset owners, and contracted response providers where they support the response.
Assign the people who operate and authorize the process. Use ISO/IEC 27035 to define incident-management roles and NIST SP 800-61 Rev. 3 to map broader internal and third-party participation.
Readiness precedes an incident; reported events are assessed against organization-defined criteria and then closed or handled through the five-phase process.
Preparation and lessons learned sit across Govern, Identify, and Protect. Potentially adverse events are analyzed through Detect to determine whether they meet defined incident criteria; once an incident is declared, the response plan is executed and applicable Respond and Recover outcomes follow.
NIST SP 800-61 organizes incident response as cybersecurity risk management guidance within the , including preparation, detection, response, recovery, and lessons learned.
Use ISO/IEC 27035 for the management-system backbone: policy, roles, process, records, and review. Use NIST SP 800-61 for incident-response recommendations that fit a CSF 2.0 based risk-management model.
ISO/IEC 27035 records include policy and plan, team authority, event and incident reports, the incident register, assessment and priority decisions, response logs, evidence, communications, closure, and lessons.
Keep one chronology and evidence store where possible. Preserve the NIST revision used by historical records, then tag current ISO phases and Rev. 3 CSF outcomes without rewriting history.
ISO/IEC 27035 adoption can be evaluated through exercises, internal audits, customer assurance, management review, and governance review; the guidance itself is not a standalone certification scheme.
NIST SP 800-61 Rev. 3 is guidance, not a certification scheme or statute. Other laws, government policies, contracts, or customer requirements may separately require its use or particular incident practices.
Evaluate implementation against the chosen profile and operating evidence. Test legal and contractual compliance against the controlling sources rather than inferring it from NIST alignment.
Rev. 3 can map the same records to governance, asset and supplier context, detection, analysis, response, recovery, communications, and improvement outcomes.
Reuse the record when it represents the same event and decision. Preserve its original NIST revision and add missing current mappings instead of duplicating the incident.
How should teams decide between ISO/IEC 27035 and NIST SP 800-61 for compliance planning?
Choose ISO/IEC 27035 when you need a management-system style incident process with documented scope, roles, records, review, and improvement.
Choose NIST SP 800-61 when you need CSF 2.0-based incident response recommendations for cybersecurity risk management, including preparation, detection, response, recovery, and lessons learned.
Use both when one source supports the governance model and the other helps operationalize incident response; do not merge them into one undifferentiated requirement set.
What changed in the ISO/IEC 27035 versus NIST SP 800-61 comparison?
Rev. 2 used preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Rev. 3 reproduces that model only as the previous lifecycle, then organizes current recommendations as a . Govern, Identify, and Protect support preparation and impact reduction; Detect, Respond, and Recover cover active incident response; Identify Improvement carries lessons across all Functions.
ISO/IEC 27035-1 uses five phases: plan and prepare; detect and report; assess and decide; respond; and learn lessons. Part 2 expands preparation and learning, while Part 3 covers ICT detection, notification, triage, analysis, evidence storage, containment, eradication, recovery, and reporting. Compare these current outcomes and decisions instead of forcing the Rev. 2 diagram onto either publication.
Use the dedicated Rev. 3 route when documenting a new crosswalk or current framework alignment.
Label records and diagrams with the NIST revision so responders can tell whether a phase name is historical or current.
Keep legal, regulatory, contractual, insurer, and customer notifications as separate overlays with their own tests, recipients, content, and clocks.
Which records should prove ISO/IEC 27035 vs NIST SP 800-61 is implemented correctly?
First identify which NIST revision each record implements. A Rev. 2 phase label can remain in historical tickets, procedures, and metrics, but a current alignment should also identify the relevant Rev. 3 CSF outcome. Do not silently relabel old evidence as if the operating process had changed.
ISO/IEC 27035 evidence should show policy, plan, team authority, tested assessment criteria, event and incident registers, response actions, evidence handling, closure, and lessons. Rev. 3 evidence should connect governance, asset and supplier context, adverse-event analysis, investigation, containment, eradication, recovery validation, communications, and improvement to the applicable CSF outcomes.
Migration evidence: inventory of Rev. 2 documents and metrics, approved Rev. 3 crosswalk, changed roles or procedures, training, exercise results, exceptions, and retirement dates.
How should teams migrate from Rev. 2 without disrupting response?
Inventory every policy, plan, playbook, role description, ticket state, metric, exercise, customer commitment, and control mapping that cites SP 800-61 Rev. 2. Decide whether each item remains valid operationally, needs only a citation update, or must change because Rev. 3 broadens incident response across cybersecurity risk management.
Choose one vocabulary for live response. Map ISO/IEC 27035 event reporting, incident assessment, response, and learning to the applicable Rev. 3 outcomes. Keep aliases for old ticket states only where responders need them during transition, and train the people who declare incidents, authorize disruptive actions, communicate externally, or validate recovery.
Test migrated playbooks through a scenario that crosses detection, legal review, supplier coordination, containment, recovery, and lessons learned.
Preserve historical revision labels so old metrics and audit samples are not misrepresented.
Retire Rev. 2-only diagrams and training after the replacement process has been exercised and approved.
What mistakes make ISO/IEC 27035 vs NIST SP 800-61 weak or hard to audit?
Do not call the Rev. 2 four-phase model the current NIST lifecycle. Rev. 3 discusses it as the previous model and explicitly allows organizations to use the lifecycle framework that suits them.
Do not perform a citation-only migration where roles, supplier participation, asset context, recovery priorities, continuous improvement, or broader risk-management integration are missing. Conversely, do not rewrite a working procedure merely to imitate the order of CSF Functions.
Do not erase Rev. 2 labels from historical evidence or claim that old incidents were handled under Rev. 3.
Do not force a one-to-one mapping between ISO phases, Rev. 2 phases, and CSF Functions.
Do not treat either guide as the source of a statutory or contractual notification deadline.
How should teams review and improve ISO/IEC 27035 vs NIST SP 800-61 over time?
Review the migration after exercises and real incidents. Look for terminology that delayed declaration, unclear authority, broken automation, metrics that no longer measure the same state, missing third parties, duplicated records, and improvements that never reached risk, protection, detection, or recovery work.
For each finding, record the evidence, owner, due date, change, acceptance test, and verification result. Update the crosswalk only after the operating process changes, and keep unresolved legacy dependencies visible until they are retired.
Review plans after material incidents, exercises, supplier changes, architecture changes, and new reporting obligations.
Re-run failed scenarios before closing migration actions.
Escalate unresolved authority, staffing, tooling, supplier, evidence, and recovery risks to leadership.