Introduction: ISO/IEC 27035 and the Discipline of Incident Management
Security incidents are not a question of if but when. The most mature security programme in the world will, at some point, face a phishing compromise, a ransomware attempt, an insider abuse, a misconfigured cloud bucket exposing data, or a supply-chain intrusion. What separates a resilient organisation from a headline-generating breach is rarely the sophistication of its defences alone; it is the speed, discipline and repeatability with which it detects, responds to, contains and learns from incidents. ISO/IEC 27035 is the international standard that codifies exactly this discipline. It provides a structured, phased and evidence-based approach to information security incident management that any organisation, regardless of size, sector or geography, can adopt.
ISO/IEC 27035 sits within the broader ISO/IEC 27000 family of information security standards. Where ISO/IEC 27001 defines the requirements for an Information Security Management System (ISMS) and mandates that incident management be addressed, ISO/IEC 27035 is the detailed 'how-to' companion that expands the single high-level control on incident management into a complete operating model. It is not a certifiable standard in its own right in the way ISO 27001 is; rather, it is guidance that organisations use to build, operate and mature an incident management capability that in turn helps them satisfy ISO 27001 (particularly Annex A control 5.24 through 5.28 in the 2022 revision) and demonstrate operational competence to regulators, customers and auditors.
This guide is written for two audiences at once. For the auditor or assessor, it enumerates every phase, activity, requirement and expected output of the standard so that a rigorous gap assessment can be performed against real evidence. For the implementer, incident response lead, SOC manager or product security team, it lays out a phased path to build the capability from scratch, the roles required, the artefacts to produce, and the metrics that prove the capability is working. Throughout, we use the terminology of the standard precisely: events, incidents, vulnerabilities, the plan-detect-assess-respond-learn lifecycle, the Point of Contact (PoC), the Incident Response Team (IRT) or Information Security Incident Response Team (ISIRT), and the concept of continual improvement.
What is ISO/IEC 27035
ISO/IEC 27035 is a multi-part international standard that provides guidance on managing information security incidents through a defined, repeatable lifecycle. Its central premise is that effective incident management is a continuous, planned process, not an ad-hoc reaction. The standard establishes a common vocabulary, a phased process model, and a set of activities, controls and outputs for each phase, together with guidance on the coordination of incident response, on preparing to respond to incidents specifically, and on operations of a coordinated response involving multiple parties.
The standard is structured as a series of parts, each addressing a distinct aspect of incident management:
- ISO/IEC 27035-1 — Principles and process. Part 1 sets out the core concepts, the phased incident management process model, the benefits, and the key principles. It is the foundation on which the other parts build. The current revision defines the lifecycle phases of Plan and Prepare, Detection and Reporting, Assessment and Decision, Responses, and Lessons Learnt.
- ISO/IEC 27035-2 — Guidelines to plan and prepare for incident response. Part 2 provides detailed guidance on establishing the incident management policy, forming the ISIRT/IRT, defining an incident response plan, and preparing the people, process, and technology needed before an incident occurs. It is the operational readiness companion to Part 1.
- ISO/IEC 27035-3 — Guidelines for ICT incident response operations. Part 3 addresses the practical, technical operations of detecting, triaging, analysing and responding to incidents, including the use of detection sources, the operation of the response team, and the handling of specific incident categories.
- ISO/IEC 27035-4 — Coordination. Later parts address coordination of incident response across organisational boundaries, including with external parties such as CERTs, CSIRTs, law enforcement, customers and suppliers.
The relationship between an information security event, an incident and a vulnerability is fundamental to the standard and to any assessment against it. An event is an identified occurrence of a system, service or network state indicating a possible breach of policy or failure of controls, or a previously unknown situation that may be security-relevant. An incident is a single or a series of unwanted or unexpected events that have a significant probability of compromising business operations and threatening information security. A vulnerability is a weakness that can be exploited. The lifecycle exists precisely to triage the very large volume of events down to the smaller number of genuine incidents that warrant a coordinated response, and to feed identified vulnerabilities back into the wider ISMS for remediation.
ISO/IEC 27035 aligns tightly with ISO/IEC 27001 and ISO/IEC 27002. Where ISO 27001 requires the organisation to plan and prepare for the management of information security incidents, and ISO 27002 provides the control guidance (assessment and decision on events, response to incidents, learning from incidents, and collection of evidence), ISO 27035 supplies the full operational methodology. It also complements sector and national schemes such as CERT-In directions in India, the NIST Computer Security Incident Handling Guide (SP 800-61), and regulatory breach-notification regimes such as GDPR, the DPDP Act, and PCI DSS incident response requirements.
Who Must Comply With ISO/IEC 27035
ISO/IEC 27035 is a guidance standard, so strictly speaking no organisation is legally compelled to 'comply' with it in the way one complies with a law. However, a very wide range of organisations are effectively required to demonstrate a competent incident management capability that maps directly to ISO 27035, whether through certification, contract, regulation or good practice. The table below summarises the principal categories.
| Organisation type | Why ISO 27035 applies | Driver |
|---|---|---|
| ISO 27001-certified organisations | ISO 27001 Annex A controls 5.24-5.28 mandate incident planning, assessment, response, learning and evidence collection; ISO 27035 is the reference methodology | Certification / audit |
| Financial institutions, banks, payment providers | Regulators (RBI, SEBI, IRDAI, PCI SSC) require documented, tested incident response and breach reporting | Regulatory |
| Critical information infrastructure & CERT-In regulated entities (India) | CERT-In directions mandate incident reporting within defined timelines and a documented response process | Regulatory / national |
| Data controllers and processors under GDPR / DPDP Act | Breach detection, assessment and notification duties align with the 27035 detect-assess-respond phases | Legal / privacy |
| Managed Security Service Providers (MSSPs) and SOCs | Customers demand a formal, auditable incident handling process as a contractual deliverable | Contractual |
| Cloud, SaaS and technology vendors | Enterprise procurement and security questionnaires require evidence of an incident response programme | Commercial / trust |
| Healthcare, telecom, energy and public sector | Sector regulations and national cyber-resilience frameworks require incident readiness | Sector regulation |
| Any organisation handling sensitive or regulated data | Duty of care, cyber-insurance conditions, and board-level risk oversight | Risk / insurance |
In practice, the strongest driver is ISO 27001 certification. An organisation cannot achieve or maintain ISO 27001 without a working incident management process, and certification auditors routinely test that process against the phases and expectations described in ISO 27035. Cyber-insurance underwriters and enterprise customers increasingly ask for the same evidence.
Structure of ISO/IEC 27035: Phases, Parts and Key Activities
The heart of ISO/IEC 27035 is its five-phase process model. Each phase has defined objectives, activities, inputs and outputs, and each is supported by guidance across the parts of the standard. The table below maps the phases to their purpose, the key activities within them, and the primary outputs an assessor should expect to find. This structure is the backbone against which the master assessment checklist that follows is organised.
| Phase / family | Purpose | Key activities | Primary outputs |
|---|---|---|---|
| Plan and Prepare | Establish the capability, policy, team and infrastructure before incidents occur | Define policy, form ISIRT/IRT, create plans, provision tooling, train, run awareness | Incident management policy, IR plan, team charter, playbooks |
| Detection and Reporting | Identify and report events and vulnerabilities from all sources | Monitor, detect, collect, report events and vulnerabilities via the PoC | Event reports, detection logs, reporting channels |
| Assessment and Decision | Triage events, confirm which are incidents, classify and prioritise | Assess events, categorise, prioritise, escalate, decide on response | Incident classification, severity/priority ratings, decisions |
| Responses | Contain, eradicate, recover and, where appropriate, conduct forensics | Contain, collect evidence, eradicate, recover, communicate, escalate to crisis | Response records, forensic evidence, recovery confirmation |
| Lessons Learnt | Improve controls, process and the capability itself from each incident | Post-incident review, root-cause analysis, update controls and plans | Post-incident report, improvement actions, updated playbooks |
| Coordination (27035-3/-4) | Coordinate response across internal and external parties | Liaise with CERTs, law enforcement, suppliers, customers; manage disclosure | Coordination records, external reports, MoUs |
How the parts support the phases
| Part | Title (paraphrased) | Phases primarily supported |
|---|---|---|
| 27035-1 | Principles and process | All five phases — the master model and principles |
| 27035-2 | Plan and prepare for incident response | Plan and Prepare; readiness for all downstream phases |
| 27035-3 | ICT incident response operations | Detection, Assessment, Responses (operational/technical) |
| 27035-4 | Coordination | Coordination across the response, especially Responses and Lessons Learnt |
Master Assessment Checklist
This is the core section of the guide. It enumerates every phase, activity and requirement of ISO/IEC 27035 and, for each, sets out what an auditor must verify and the typical evidence that demonstrates conformity. An organisation seeking to align with the standard should be able to produce evidence for every row. The checklist is organised by the five lifecycle phases plus cross-cutting governance and coordination groups. Do not skip any group; a gap in any phase breaks the lifecycle.
Group 1 — Incident Management Governance and Policy
| What to verify | Typical evidence |
|---|---|
| A documented information security incident management policy exists, is approved by management, and is communicated | Signed policy document, approval record, distribution/acknowledgement log |
| The policy defines scope, objectives, definitions (event/incident/vulnerability) and management commitment | Policy content review, scope statement |
| Roles, responsibilities and authorities for incident management are formally assigned | RACI matrix, ISIRT charter, job descriptions |
| The incident management scheme is integrated with the wider ISMS and risk management | ISMS documentation cross-references, risk register linkage |
| A schedule for review and update of the policy and scheme is defined and followed | Review calendar, version history, change log |
| Legal, regulatory and contractual reporting obligations are identified and documented | Compliance obligations register, notification matrix |
Group 2 — Plan and Prepare Phase
| What to verify | Typical evidence |
|---|---|
| An Information Security Incident Response Team (ISIRT/IRT) is established with defined membership | Team charter, member list, contact roster |
| A designated Point of Contact (PoC) is defined and reachable 24x7 as appropriate to risk | PoC procedure, on-call rota, contact details |
| A documented incident response plan / playbooks cover common incident categories | IR plan, category-specific playbooks (malware, phishing, data breach, DoS, insider) |
| Classification and severity/priority scales are defined in advance | Classification matrix, severity definitions |
| Detection and reporting tooling and channels are provisioned (SIEM, ticketing, reporting form) | Tool inventory, screenshots, configuration records |
| Secure evidence-handling and forensic-readiness procedures are established | Forensic-readiness policy, chain-of-custody template, tool list |
| Training, exercises and awareness for staff and the ISIRT are planned and delivered | Training records, tabletop/exercise reports, awareness material |
| Internal and external communication and escalation procedures are documented | Escalation matrix, communication plan, contact lists for CERT/regulators |
| Necessary resources, budget and management support are provisioned | Resource plan, budget approval, tooling licences |
Group 3 — Detection and Reporting Phase
| What to verify | Typical evidence |
|---|---|
| Events are detected from multiple sources (automated monitoring, users, third parties) | Detection source inventory, SIEM alerts, user reports |
| A simple, well-publicised mechanism exists for anyone to report events and vulnerabilities | Reporting form/portal, hotline, awareness comms |
| Reported events are captured with sufficient detail (who, what, when, where, impact) | Event report records, ticket fields |
| Vulnerabilities are reported and routed for assessment separately from events | Vulnerability reports, coordinated disclosure procedure |
| Detection and reporting timelines meet policy and regulatory expectations | Timestamps in tickets, SLA metrics, CERT-In reporting evidence |
| All events and reports are logged in a central register | Incident register / case management system extract |
Group 4 — Assessment and Decision Phase
| What to verify | Typical evidence |
|---|---|
| Each reported event is assessed to determine whether it is an information security incident | Triage records, assessment notes, decision log |
| Confirmed incidents are categorised using the predefined classification scheme | Categorised tickets, classification field values |
| Incidents are prioritised by severity/impact and urgency | Severity ratings, prioritisation rationale |
| Decisions on whether and how to respond are made and recorded by authorised roles | Decision records with approver, escalation entries |
| Escalation criteria (to crisis management, executives, external parties) are applied | Escalation records, notifications |
| False positives and non-incidents are documented and closed with rationale | Closed-not-incident tickets with justification |
Group 5 — Responses Phase (Containment, Eradication, Recovery)
| What to verify | Typical evidence |
|---|---|
| Containment actions are taken promptly to limit impact and spread | Containment action logs, timestamps, isolation records |
| Evidence is collected and preserved with maintained chain of custody | Forensic images, chain-of-custody forms, evidence log |
| Eradication removes the root cause (malware, unauthorised access, misconfiguration) | Remediation records, patch/config change tickets |
| Recovery restores affected systems and validates their integrity before return to service | Recovery checklist, integrity verification, sign-off |
| Communications to internal stakeholders and external parties are managed and timely | Communication log, notification records, holding statements |
| Regulatory and customer breach notifications are made within required timelines | Notification letters, CERT-In/regulator submissions, timestamps |
| Major incidents are escalated to crisis management / business continuity as needed | Crisis activation records, BCP/DR invocation evidence |
| Response actions and decisions are fully documented throughout the incident timeline | Incident timeline, action log, decision record |
Group 6 — Lessons Learnt and Continual Improvement Phase
| What to verify | Typical evidence |
|---|---|
| A post-incident review is conducted for significant incidents | Post-incident review reports, meeting minutes |
| Root-cause analysis identifies underlying causes, not just symptoms | RCA documentation, 5-whys / fishbone analysis |
| Improvement actions to controls, process and plans are identified and tracked to closure | Action tracker, closed CAPA records |
| Playbooks, policy and the incident scheme are updated based on findings | Updated document versions, change history |
| Incident metrics and trends are analysed to inform risk treatment | Trend reports, metrics dashboards, risk register updates |
| Knowledge is shared with relevant teams and, where appropriate, externally | Knowledge base entries, threat-intel sharing records |
Group 7 — Evidence Collection and Forensic Readiness
| What to verify | Typical evidence |
|---|---|
| Procedures ensure evidence is collected in a legally admissible manner | Forensic procedure, admissibility guidance |
| Chain of custody is maintained from collection to disposal | Chain-of-custody records, evidence storage log |
| Time synchronisation across systems supports reliable timelines | NTP configuration, log timestamp accuracy checks |
| Log sources are retained for sufficient duration to support investigations | Log retention policy, retention configuration |
| Personnel handling evidence are trained and authorised | Training records, authorisation list |
Group 8 — Coordination and External Relationships (27035-3 / -4)
| What to verify | Typical evidence |
|---|---|
| Relationships with external parties (CERT/CSIRT, law enforcement, suppliers) are established | Contact register, MoUs, engagement records |
| Coordination procedures for multi-party incidents are documented | Coordination playbook, shared-responsibility matrix |
| Information-sharing agreements and confidentiality controls are in place | NDAs, TLP handling procedure, sharing agreements |
| Roles and interfaces with a coordinating CSIRT are defined | Coordination charter, escalation-to-CERT procedure |
| Cross-border and supply-chain incident handling is addressed | Supplier incident clauses, cross-border data-handling notes |
Scoping the Incident Management Capability
Scoping determines which parts of the organisation, which assets, and which incident types the incident management capability covers. A well-defined scope prevents both under-coverage (critical systems left without a response plan) and wasteful over-engineering. Scoping should be driven by the risk assessment and by the boundaries of the ISMS where one exists.
- Organisational scope: which business units, subsidiaries, geographies and legal entities are covered by the incident scheme.
- Asset and information scope: which systems, applications, networks, cloud environments, OT/ICS and data classifications are in scope, prioritised by criticality.
- Incident-type scope: which categories are addressed (malware/ransomware, phishing, unauthorised access, data breach, denial of service, insider misuse, physical, third-party/supply-chain, cloud misconfiguration).
- Stakeholder scope: internal teams (SOC, IT, legal, HR, communications, executive) and external parties (CERTs, regulators, customers, suppliers, forensic partners).
- Regulatory and contractual scope: jurisdictions and obligations that trigger mandatory reporting (CERT-In, GDPR, DPDP, PCI DSS, sector regulators).
- Interfaces and exclusions: dependencies on outsourced/MSSP services and any explicitly excluded areas, with documented justification.
Implementation Approach: A Phased Programme
Building an ISO 27035-aligned capability is best done in defined phases. Each phase below lists its core activities and the deliverables an assessor would expect. The phasing mirrors the standard's own logic: prepare first, then operationalise detection and response, then embed learning and coordination.
Phase 1 — Establish Governance and Policy (Weeks 1-4)
- Activities: secure executive sponsorship; define the incident management policy, objectives and scope; establish definitions and the classification scheme; identify legal and regulatory obligations.
- Deliverables: approved incident management policy, scope statement, classification and severity matrices, obligations register.
Phase 2 — Plan and Prepare (Weeks 3-10)
- Activities: form and charter the ISIRT/IRT; assign roles and the PoC; develop the incident response plan and category playbooks; provision tooling (SIEM, case management, forensic kit); establish evidence-handling and forensic-readiness procedures; build communication and escalation matrices.
- Deliverables: ISIRT charter and roster, IR plan, playbooks, tooling in place, forensic-readiness procedure, escalation/communication matrices.
Phase 3 — Detection and Reporting Operationalisation (Weeks 8-14)
- Activities: integrate detection sources; deploy an easy reporting mechanism for staff and third parties; configure the central incident register; define reporting timelines and SLAs.
- Deliverables: detection source inventory, reporting portal/form, incident register, SLA definitions.
Phase 4 — Response Operations and Testing (Weeks 12-18)
- Activities: operationalise triage, assessment and prioritisation; run the response workflow end-to-end; conduct tabletop exercises and at least one simulated incident; validate breach-notification workflows.
- Deliverables: exercise reports, tested workflows, validated notification templates, first response records.
Phase 5 — Lessons Learnt and Continual Improvement (Weeks 16+, ongoing)
- Activities: institute post-incident reviews and RCA; establish a metrics/KPI dashboard; feed improvements back into controls, playbooks and the risk register; schedule periodic reassessment and re-exercising.
- Deliverables: post-incident review template, KPI dashboard, improvement tracker, review calendar.
Phase 6 — Coordination and External Integration (ongoing)
- Activities: establish relationships with CERTs/CSIRTs, law enforcement and suppliers; put information-sharing and confidentiality agreements in place; define multi-party coordination procedures.
- Deliverables: external contact register, MoUs/NDAs, coordination playbook.
Maturity and Capability Model
While ISO/IEC 27035 does not itself prescribe a formal maturity scoring model, it is standard assessment practice to rate the capability against a five-level maturity scale so that progress can be measured and gaps prioritised. The table below defines a practical maturity model for incident management, drawing on capability-maturity conventions widely used by assessors.
| Level | Name | Characteristics | Typical indicators |
|---|---|---|---|
| 0 | Non-existent | No defined incident capability; incidents handled ad hoc if at all | No policy, no team, no records |
| 1 | Initial | Reactive handling; some individuals respond but no documented process | Informal responses, inconsistent outcomes |
| 2 | Repeatable | Basic policy and team exist; playbooks used for common incidents | Documented policy, IR plan, some records |
| 3 | Defined | Full lifecycle documented and consistently applied across scope | Complete phases, classification, training, exercises |
| 4 | Managed | Metrics-driven; SLAs measured; post-incident reviews standard | KPI dashboards, trend analysis, tested plans |
| 5 | Optimising | Continual improvement embedded; threat-informed; coordinated externally | Automation, threat-intel integration, CERT coordination |
Most organisations target Level 3 (Defined) for initial ISO 27001 certification support and progress towards Levels 4 and 5 as the programme matures. An assessor should score each of the eight checklist groups independently and identify the lowest-scoring groups as improvement priorities.
Assessment and Audit Approach
A rigorous ISO 27035 assessment follows a structured, evidence-based methodology. The steps below describe the recommended sequence for an auditor conducting a gap assessment or readiness review.
- Define the assessment scope and objectives with the sponsor, confirming which entities, assets and incident types are in scope.
- Review documentation: policy, IR plan, playbooks, classification scheme, charters, procedures and prior incident records.
- Map the organisation's process against the five lifecycle phases and the eight checklist groups.
- Conduct interviews with the ISIRT, SOC analysts, IT operations, legal, communications and executive sponsors.
- Sample and test evidence: pull a representative set of past incident cases and trace each through detection, assessment, response and lessons learnt.
- Observe or facilitate a tabletop exercise or walkthrough to test the plan in practice.
- Assess forensic readiness, evidence handling and chain-of-custody controls.
- Verify regulatory and contractual notification workflows against real or simulated timelines.
- Score each checklist group against the maturity model and identify gaps and root causes.
- Produce a findings report with prioritised, risk-based recommendations and a remediation roadmap.
- Agree corrective actions and a re-assessment date to confirm closure.
Evidence Request List
The following categorised list is what an assessor typically requests ahead of and during an ISO 27035 review. Implementers can use it as a pre-audit readiness pack.
- Governance: incident management policy, scope statement, management approval records, RACI/roles matrix, obligations register.
- Planning: ISIRT charter and roster, PoC procedure and on-call rota, incident response plan, category playbooks, classification and severity matrices.
- Detection & reporting: detection source inventory, SIEM/alerting configuration, reporting form/portal, awareness communications, incident register extract.
- Assessment & decision: triage records, classification examples, prioritisation rationale, escalation and decision logs.
- Response: incident timelines, containment/eradication/recovery records, communication logs, breach-notification submissions, crisis/BCP activation evidence.
- Forensics & evidence: forensic-readiness procedure, chain-of-custody templates and completed forms, evidence storage and retention records.
- Lessons learnt: post-incident review reports, RCA documents, improvement action tracker, updated document versions.
- Testing & training: tabletop/simulation exercise reports, training records, awareness metrics.
- Coordination: external contact register, MoUs/NDAs, information-sharing agreements, CERT/regulator engagement records.
- Metrics: KPI dashboards, trend reports, SLA compliance data.
Roles and Responsibilities
| Role | Key responsibilities | Phase focus |
|---|---|---|
| Executive sponsor / CISO | Owns the policy, provides resources and authority, makes crisis decisions | Governance, escalation |
| Incident Manager / ISIRT lead | Coordinates the response, chairs reviews, owns the IR plan | All phases |
| Point of Contact (PoC) | Single reporting channel; receives, logs and routes events | Detection & Reporting |
| SOC analysts / detection team | Monitor, detect, triage and escalate events | Detection, Assessment |
| Incident responders / forensics | Contain, collect evidence, eradicate, recover | Responses |
| IT / infrastructure operations | Execute isolation, patching, restoration under IRT direction | Responses |
| Legal & compliance | Advise on obligations, manage regulatory notifications | Response, Coordination |
| Communications / PR | Manage internal and external messaging | Response, Coordination |
| HR | Handle insider and personnel-related aspects | Response |
| Business continuity / crisis team | Invoked for major incidents; run BCP/DR | Response (major) |
| External CERT/CSIRT & partners | Provide coordination, threat intel and specialist support | Coordination |
KPIs to Track
- Mean Time to Detect (MTTD) — average time from occurrence to detection.
- Mean Time to Acknowledge / Triage — time from report to assessment start.
- Mean Time to Respond / Contain (MTTR) — time from detection to containment.
- Mean Time to Recover — time from containment to full restoration.
- Number of events reported vs. confirmed incidents (triage effectiveness).
- Percentage of incidents detected internally vs. by third parties.
- Percentage of incidents with completed post-incident reviews and RCA.
- Percentage of improvement actions closed within target timeframe.
- Breach notifications made within regulatory deadlines (e.g. CERT-In 6-hour window).
- Recurrence rate — incidents from previously identified but unremediated causes.
- Exercise cadence and pass rate for tabletop/simulation tests.
- Staff awareness reporting rate — proportion of incidents reported by employees.
Readiness Checklist
- Incident management policy approved, communicated and version-controlled.
- ISIRT/IRT chartered with named members and a 24x7-capable PoC.
- Incident response plan and category playbooks documented and accessible.
- Classification, severity and prioritisation scales defined in advance.
- Detection sources integrated and an easy reporting mechanism published.
- Central incident register / case management system in operation.
- Forensic-readiness and chain-of-custody procedures established.
- Escalation, communication and breach-notification matrices in place.
- Regulatory and contractual reporting obligations mapped with timelines.
- Training delivered and at least one tabletop/simulation exercise completed.
- Post-incident review and RCA process defined and used.
- KPI dashboard operational and reviewed by management.
- External CERT/CSIRT and partner relationships established.
- Periodic review and re-exercise schedule agreed and calendared.
Common Gaps
- Policy exists on paper but the IR plan and playbooks are never tested through exercises.
- No single, well-publicised Point of Contact, so events go unreported or to the wrong place.
- Classification and severity scales are undefined, leading to inconsistent prioritisation.
- Detection is over-reliant on tooling with no easy way for staff to report suspicious activity.
- Weak forensic readiness — evidence collected without chain of custody, undermining admissibility.
- Recovery declared complete without integrity verification, allowing reinfection.
- Post-incident reviews skipped or superficial, so the same incidents recur.
- Breach-notification timelines (e.g. CERT-In 6 hours) not built into the response workflow.
- No coordination arrangements with CERTs, suppliers or law enforcement before an incident.
- Metrics not captured, so management cannot see whether the capability is improving.
- Shared-responsibility boundary with MSSP/cloud provider undocumented, leaving lifecycle gaps.
- Lessons-learnt actions raised but never tracked to closure or fed into the risk register.
ISO/IEC 27035 Mapped to Other Frameworks
| ISO 27035 phase / concept | ISO 27001:2022 Annex A | NIST SP 800-61 / CSF | CERT-In / regulatory |
|---|---|---|---|
| Plan and Prepare | 5.24 Incident management planning & preparation | Preparation phase; CSF Govern/Identify | Documented IR process, designated PoC |
| Detection and Reporting | 5.25 Assessment & decision on events; 6.8 reporting | Detection & Analysis; CSF Detect | Event detection and logging |
| Assessment and Decision | 5.25 Assessment & decision on security events | Detection & Analysis (triage) | Incident classification |
| Responses | 5.26 Response to incidents | Containment, Eradication & Recovery; CSF Respond | Mandatory reporting within 6 hours (CERT-In) |
| Lessons Learnt | 5.27 Learning from incidents | Post-Incident Activity; CSF Recover/Improve | Continual improvement obligations |
| Evidence collection | 5.28 Collection of evidence | Forensic guidance in 800-61 | Admissible evidence for investigations |
| Coordination | Supported by 27035-4 | Coordination guidance; information sharing | Coordination with CERT-In / national CSIRT |
Frequently asked questions
Need help with ISO 27035?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.