A practical operating model for incident management based on the ISO/IEC 27035 series.
Built for security leaders, incident managers, SOC teams, CSIRTs, and ISMS owners who need a usable and auditable response capability.
Structured answer sets in this page tree.
Cited legal and guidance references.
ISO/IEC 27035 is not a one page incident response policy. It is a full capability model. Part 1 defines the process and required documentation. Part 2 defines the planning and preparation work that makes response repeatable. Part 3 provides ICT response operations for detection, notification, triage, analysis, containment, eradication, and recovery. A compliant operating model proves that those pieces work together.
The grounded series here is ISO/IEC 27035-1:2023 second edition, ISO/IEC 27035-2:2023 second edition, and ISO/IEC 27035-3:2020 first edition. The 2023 revisions matter because they formalize the incident management team and incident coordinator roles and strengthen the planning and lessons learned structure.
If your program still reflects only the older 2016 framing, your team structure and documentation model are probably too thin.
Part 2 expects an information security incident management policy and an incident management plan that cover the process flow, classification and severity documents, post-resolution activities, external support, and information sharing rules.
The plan should be a document set, not a single PDF. It should include forms, procedures, organizational elements, and the support tools needed for all phases.
Part 2 expects formal establishment of the incident management team, the incident response team, and the incident coordinator role. It also recognizes that the response capability often depends on specialists outside the core team, such as legal, forensics, facilities, cloud providers, or media relations.
That means you need a living capability register, not just an org chart.
The standard does not treat event reporting as a vague mailbox function. It expects event reports to be completed immediately when a suspected incident may cause substantial loss or damage, and it expects defined criteria for accepting an event report based on its completeness.
Poor intake quality is a root cause of poor triage.
Annex C in Part 2 focuses on categorization, evaluation, and prioritization. It expects organizations to document incidents consistently so evaluation, reporting, and severity handling are comparable across cases.
The scoring model should align with your information classification policy and should support decisions on priority and escalation level.
Part 3 goes beyond generic incident response advice. It covers detection operations, notification operations, triage, analysis, evidence handling, and response operations for containment, eradication, and recovery.
That means response should not only be fast. It should preserve analysis quality and evidence quality.
Part 2 makes lessons learned a structured phase, not an optional meeting. It expects improvement of the plan, evaluation of the IMT, improvement of control implementation, and review of risk assessment and management review results when incidents show reality differs from assumptions.
This is where many programs fail. They close tickets but never update policy, plan, control design, or risk ratings.
A defensible ISO 27035 capability produces a repeatable evidence set. That evidence should prove process design, team readiness, incident execution, and improvement follow-through.
If your evidence stops at an incident policy and a few tickets, the program is not mature.
Assessment Autopilot can take ISO 27035 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27035 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.
Start from ISO 27035 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints.
Review your current process, evidence gaps, and next steps for ISO 27035 Compliance.