ISO/IEC 27035
incident management standard for security operations and GRC teams
ISO/IEC 27035 (Information technology, Security techniques, Information security incident management) is the international standard for the discipline of security incident management as operated inside an information security management system. It is published in three parts: Part 1 names the principles and the five-phase cycle, Part 2 covers planning and preparation, and Part 3 covers ICT incident response operations once an incident is in flight. The standard pairs with ISO/IEC 30111 (vulnerability handling) and ISO/IEC 29147 (vulnerability disclosure) to form the international incident-and-disclosure trio, and it is the operating reference behind the policy and control discipline that ISO/IEC 27001 Annex A 5.24 through 5.30 names. This page covers the five-phase cycle, the operating-record artefact set, the failure modes the standard surfaces, the relationship with NIS2, DORA, SOC 2, PCI DSS, HIPAA, the SEC rule, and NIST SP 800-61, and the audit-grade evidence pack the programme produces.
No credit card required. Free plan available forever.
ISO/IEC 27035 explained for security operations and GRC teams
ISO/IEC 27035 (Information technology, Security techniques, Information security incident management) is the international standard for the discipline of information security incident management as operated inside an information security management system. It is published in three parts: Part 1 names the principles and the five-phase cycle, Part 2 covers planning and preparation, and Part 3 covers ICT incident response operations once an incident is in flight. The standard is the operational reference behind the policy and control discipline that ISO/IEC 27001 names in Annex A 5.24 through 5.30, and it pairs with the vulnerability-handling and disclosure standards ISO/IEC 30111 and ISO/IEC 29147 to form the international incident-and-disclosure trio.
For internal security teams running the live response, security operations leaders accountable for incident outcomes, GRC and compliance teams producing the audit pack, and CISOs at organisations read against by ISO 27001 certification bodies, NIS2 competent authorities, DORA financial-sector regulators, the SEC, sector regulators, customers, and cyber insurance carriers, ISO/IEC 27035 is the operating reference the discipline reads against. The standard is the international anchor that NIS2 Article 21 and 23, DORA Articles 19 and 20, the SEC cybersecurity disclosure rule, PCI DSS Requirement 12.10, HIPAA 45 CFR 164.308(a)(6), SOC 2 CC7.3 through CC7.5 and CC9.1, and NIST SP 800-61 all read against on the operating-discipline side, even where the named regulator or framework does not cite ISO/IEC 27035 by number.
This page walks through the scope of the standard, the five phases of the incident management cycle, the operating-record artefacts the standard expects, the failure modes the standard surfaces, the relationship with adjacent regimes, the audit-grade evidence pack the programme produces, and where ISO/IEC 27035 sits alongside the incident response operating workflow, the breach notification and regulator readiness workflow, the incident response plan guide, the incident response tabletop exercise guide, and the ransomware readiness programme guide. Programmes that adopt ISO/IEC 27035 as the incident management reference, ISO/IEC 30111 as the vulnerability handling reference, and ISO/IEC 29147 as the disclosure reference produce a coherent operating posture that holds up under ISO 27001, NIS2, DORA, SOC 2, PCI DSS, HIPAA, SEC, and audit-committee scrutiny on one record.
What ISO/IEC 27035 covers
The standard is the international anchor for the operating discipline of security incident management. It is broader than a single response procedure and narrower than the full ISMS; the boundary is the incident lifecycle, from planning and preparation through detection, assessment, response, and lessons learned. Read sequentially across the three parts, the standard answers the question of how an organisation operates incident management as a programme rather than as a one-off plan.
A multi-part standard
ISO/IEC 27035 is published in three parts. Part 1 (Principles and process) names the principles and the five-phase incident management cycle the rest of the parts read against. Part 2 (Guidelines to plan and prepare for incident response) covers the planning, the policy, the team structures, the communication plan, and the exercising discipline. Part 3 (Guidelines for ICT incident response operations) covers the operational handling once an incident is in flight. Programmes that adopt ISO/IEC 27035 work all three parts together rather than treating Part 1 as a freestanding doctrine.
Information security incident management as a programme
The standard treats incident response as a programme with a documented policy, named roles, exercised plans, a structured operational record, and a closure cycle that feeds the next planning iteration. It is the operational counterpart to the policy-and-control discipline ISO/IEC 27001 names in Annex A 5.24 through 5.30 (incident management policy, roles and responsibilities, knowledge gain, evidence collection, response procedures, learning from incidents, and preparation of ICT readiness for business continuity).
Distinct from vulnerability handling and disclosure
ISO/IEC 27035 is the international anchor for security-incident management as a discipline. The vulnerability-handling counterpart for vendors who ship products is ISO/IEC 30111, and the external disclosure interface is ISO/IEC 29147. The three standards form an ISO incident-and-disclosure trio: 27035 for incidents inside an information security management system, 30111 for product vulnerability handling inside an engineering organisation, and 29147 for the external disclosure interface. Programmes that ship products and operate ISMS-grade incident response work all three.
The five phases of the incident management cycle
ISO/IEC 27035 names a five-phase incident management cycle. The phases are not separate processes; they are stages on the same incident record, each with named outputs the next phase reads against. Plan and prepare produces the policy and the readiness; detection and reporting produces the structured intake; assessment and decision produces the classification and severity; response produces the technical, communications, evidence, and operational tracks; and lessons learned produces the post-incident review and the policy update that feeds the next planning iteration.
- 1
Phase 1: Plan and prepare
The programme produces the documented incident management policy, the named team and role assignments, the communication plan (internal stakeholders, regulators, customers, partners, law enforcement, public communications), the response procedures the team will follow under pressure, the training and exercise schedule, the technical readiness (logging, asset inventory, evidence collection capability, forensic tooling), and the agreements with external parties (counsel, forensic providers, communications support, cyber insurance carrier). Plan and prepare is the phase the rest of the cycle depends on; programmes that skip it operate the next four phases by improvisation.
- 2
Phase 2: Detection and reporting
The programme detects the security event from monitoring, scanner output, user report, third-party notification, partner advisory, or supplier disclosure, and opens the structured incident record. Detection and reporting names the source, captures the initial signals, opens the named handling owner, starts the policy clock, and routes the case according to severity. The discipline expects a structured intake record rather than an email thread or a chat channel.
- 3
Phase 3: Assessment and decision
The handler assesses whether the reported event is an incident, classifies the type (malware, unauthorised access, data exposure, denial of service, supply-chain compromise, insider abuse, social engineering, physical breach), calibrates the severity against the documented criteria, and records the decision to escalate, contain, monitor, or close. Assessment is the gate that turns a reported event into a tracked incident the rest of the cycle reads against; the decision is captured on the record with the named decider, the timestamp, and the rationale.
- 4
Phase 4: Response
The team operates the technical response (containment, eradication, recovery), the communications response (internal updates, regulator notifications under GDPR Article 33, NIS2 Article 23, SEC Item 1.05, HIPAA Breach Notification Rule, DORA Articles 19-20, sector-specific clocks, contractual customer obligations), the evidence response (forensic preservation, chain of custody, log capture, system imaging where the policy expects it), and the operational response (asset isolation, credential rotation, configuration rollback, supplier coordination). Response is the most visible phase of the cycle; the standard expects the technical, communications, evidence, and operational tracks to run in parallel against one record.
- 5
Phase 5: Lessons learned
The programme closes the case, captures the post-incident review (what happened, what worked, what failed, what the programme will change), updates the policy and the procedures where the incident exposed gaps, schedules the follow-on testing and exercising the gaps require, and feeds the metric pack reporting to leadership. Lessons learned is the phase that turns the response into the next planning iteration; programmes that skip the structured review repeat the same incidents at lower frequencies but the same root causes.
The operating-record artefact set
The standard expects a defined artefact set rather than a single document. The pack below is the minimum durable set most programmes maintain when they adopt ISO/IEC 27035 as the operating baseline. Each artefact has a named owner, a refresh cadence, and a version history so reconstruction at audit time is replaced with a continuous operating trail.
- A documented incident management policy that names the scope (which systems, services, business units, and information classifications are in scope), the named accountable owner, the policy clocks (acknowledgement, assessment decision, regulator notification windows, customer notification windows, post-incident review window), the decision authority (who declares an incident, who escalates, who notifies a regulator, who notifies a customer, who closes), and the integration points with crisis management, business continuity, and the wider ISMS. The policy is version-controlled and dated and refreshed on the cadence the standard expects.
- An incident register with one record per handled event, walking from detection through assessment, response, recovery, and the post-incident review. Each record carries the timestamps that prove the policy clocks were held against rather than reconstructed at audit time, the named handling owner per phase, the severity history, the affected-asset reference, the regulator notification artefacts where applicable, and the closure summary.
- A communication log per case that captures the internal stakeholder updates (executive briefings, board updates, business unit notifications), the external stakeholder communications (customer notifications, partner advisories, supplier coordination, public statements), the regulator notifications (GDPR Article 33, NIS2 Article 23, SEC Item 1.05, HIPAA, DORA, sector-specific clocks), and the law enforcement engagement where applicable. The communications log is the artefact a regulator inquiry reads alongside the technical chronology.
- An evidence custody record per case with the captured logs, system images, packet captures, malware samples, configuration snapshots, and the chain-of-custody trail per artefact (who captured it, when, what hash, where it is stored, who has touched it). The evidence record is the artefact a forensic provider, a regulator, an insurer, or a litigator reads when the incident moves into the post-response phase.
- A response action ledger per case with the technical actions (containment steps, isolation decisions, eradication actions, recovery steps), the operational actions (credential rotation, configuration rollback, asset rebuild), the supplier coordination, and the third-party engagement (forensic provider, counsel, communications support, cyber insurance carrier). Each action is timestamped, attributed to a named actor, and references the artefact the action produced.
- A post-incident review record per case that captures the timeline reconstruction, the root-cause analysis, the contributing-factor analysis, the impact assessment (operational downtime, data exposure scope, financial impact, regulatory consequence, reputational consequence), the lessons learned, the policy and procedure changes the review recommends, the follow-on action items with named owners and due dates, and the metric pack contribution.
- An exercising and training record that demonstrates the programme is exercised on the cadence the standard expects (annual full-scope exercise, semi-annual mid-scope exercises, monthly focused drills, trigger-driven rehearsals after material change). The record carries the exercise charter, the scenario, the participation roster, the observation rubric, the decisions captured, the after-action report, and the action item ledger so the exercise produces durable evidence rather than a one-off slide deck.
- A metric pack the programme reports against the policy: incidents detected by source, incidents by severity tier, time-to-detection, time-to-assessment-decision, time-to-containment, time-to-eradication, time-to-recovery, regulator-notification timeliness against the documented clock, post-incident review completion rate, lessons-learned action item closure rate, and exercise cadence achievement. The metric pack is the residue of the operating record rather than a separate reporting artefact compiled at board time.
Failure modes the standard surfaces
The standard is forgiving on the choice of tooling, the wording of the policy, and the exact phase boundaries. It is unforgiving about a small number of patterns that turn the incident management programme cosmetic rather than operational. The patterns below recur across incident management adoptions and are the ones that erode response confidence and audit defensibility most reliably.
- Treating incident response as a plan rather than a programme. Programmes that publish a written plan but never exercise it, never refresh it after material change, and never feed the lessons-learned record into the next planning iteration produce a document that reads well at audit time and fails when an incident is in flight. The standard expects exercising on a documented cadence, refresh after material change, and a closed loop from response to lessons learned to plan update.
- No documented assessment decision. Programmes that move from detection straight to response without a recorded assessment decision lose the prioritisation rationale, the severity classification, and the audit trail of why the case was treated the way it was. The standard expects the assessment decision on the record with the named decider, the timestamp, and the rationale.
- Communications track that lags the technical track. Programmes that operate the technical response on one channel and the communications response on another (counsel email, marketing tools, regulator portals, customer support replies) lose the parallel-clock discipline regulator notifications expect. The standard expects the communications log on the same record as the technical chronology, with the regulator-clock timestamps captured on the record.
- Evidence collection in chat or shared drives. Programmes that capture forensic evidence on a shared drive, in a chat channel, or in personal mailboxes lose the chain of custody the standard expects. The evidence record lives on the case with named custody, hash references, and the platform-side activity log capturing every artefact transition.
- No post-incident review. Programmes that close the case at recovery without a structured post-incident review miss the timeline reconstruction, the root-cause analysis, the lessons learned, and the policy update. The standard expects a documented review per case with named owners and follow-on action items captured against the next planning iteration.
- Lessons-learned action items that never close. Programmes that produce post-incident review reports with named action items but never track closure produce a credibility gap that auditors, regulators, and insurers all read. The standard expects the action item ledger to live on the same record as the review and to close out as the policy and procedure changes are implemented.
- Parallel records for security incidents and product vulnerabilities. Programmes that operate ISO/IEC 27035 for incidents but route vulnerability cases through a separate ticketing system without referencing the unified ISMS evidence pack produce two operating standards instead of one. The standard does not require the incident and vulnerability records to be the same record, but it does expect cross-reference where a vulnerability is the trigger for an incident or where an incident exposes a vulnerability that needs handling under ISO/IEC 30111 or another standard.
How ISO/IEC 27035 relates to adjacent regimes
ISO/IEC 27035 sits in a busy regulatory and assurance neighbourhood. The relationships below are the ones programmes encounter most often when they read 27035 against the rest of the operating regime. Programmes operating across regions and sectors use 27035 as the incident management spine and read ISO/IEC 27001, NIS2, DORA, SOC 2, PCI DSS, HIPAA, SEC Item 1.05, NIST SP 800-61, ISO/IEC 30111, and ISO/IEC 29147 as the contextual layers around it.
ISO/IEC 27035 vs ISO/IEC 27001 Annex A
ISO/IEC 27001 Annex A controls 5.24 (information security incident management planning and preparation), 5.25 (assessment and decision on information security events), 5.26 (response to information security incidents), 5.27 (learning from information security incidents), 5.28 (collection of evidence), 5.29 (information security during disruption), and 5.30 (ICT readiness for business continuity) all read against the same operating discipline ISO/IEC 27035 names. Programmes that adopt 27035 as the incident management reference produce the evidence Annex A 5.24 through 5.30 expect, and the incident register feeds the wider ISMS audit cycle. The two standards are designed to read together: 27001 names the controls, 27035 names the operating discipline behind them.
ISO/IEC 27035 vs NIST SP 800-61
NIST SP 800-61 (Computer Security Incident Handling Guide, Revision 2 and the Revision 3 update) is the US federal counterpart. The two standards are deeply compatible. NIST 800-61 uses a four-phase cycle (preparation, detection and analysis, containment-eradication-recovery, post-incident activity) where ISO/IEC 27035 uses a five-phase cycle (plan and prepare, detection and reporting, assessment and decision, response, lessons learned). The substantive operating discipline is the same; the boundary between phases differs slightly. Programmes operating NIST 800-61 as the working reference often adopt ISO/IEC 27035 as the international anchor for ISO 27001 audit reads, and vice versa, with one operating record satisfying both standards.
ISO/IEC 27035 vs ISO/IEC 30111 and ISO/IEC 29147
ISO/IEC 27035 is the international standard for information security incident management as a discipline operated inside an ISMS. ISO/IEC 30111 is the product-vulnerability-handling counterpart for vendors who ship software, hardware, or services; 30111 sits inside the engineering organisation rather than the ISMS. ISO/IEC 29147 is the external vulnerability disclosure interface that pairs with 30111. Programmes that both ship products and operate an ISMS run all three: 27035 for security incidents touching the operating environment, 30111 for vulnerabilities surfaced in shipped products, and 29147 for the disclosure interface. The three are complementary rather than competing.
ISO/IEC 27035 vs NIS2 and DORA
NIS2 Article 21 (security risk management measures) and Article 23 (reporting obligations on significant incidents) name the EU operating expectation for in-scope entities. DORA Articles 19 and 20 (ICT-related incident management process and reporting of major ICT-related incidents) name the financial-sector operating expectation for in-scope entities. Both regulations describe the operating discipline ISO/IEC 27035 already names, with regulator notification clocks layered on. Programmes operating against NIS2 and DORA use 27035 as the operating reference and the documented incident register as the evidence the regulatory expectations are met.
ISO/IEC 27035 vs SOC 2
SOC 2 trust services criteria CC7.3 (incident detection), CC7.4 (incident response), CC7.5 (security event evaluation), and CC9.1 (risk identification including incidents) all read against the same operating discipline ISO/IEC 27035 names. Service organisations operating SOC 2 as the audit reference often adopt ISO/IEC 27035 as the international anchor to make the discipline cross-readable for ISO 27001 reads, with one incident register and one post-incident review record carrying the evidence both audits read.
ISO/IEC 27035 vs PCI DSS, HIPAA, and SEC
PCI DSS Requirement 12.10 (incident response plan, training, monitoring, exercising), HIPAA 45 CFR 164.308(a)(6) (security incident procedures), and the SEC cybersecurity disclosure rule (Item 1.05 incident materiality determination, Item 106(b) and (c) processes and oversight in the annual report) all read against subsets of the same operating discipline. ISO/IEC 27035 is broader than any single regulator expectation; programmes that adopt 27035 as the operating spine produce one register, one communication log, one evidence trail, and one post-incident review that satisfies the operating-discipline read across PCI DSS, HIPAA, the SEC rule, and the ISO 27001 audit.
The audit-grade evidence pack
Internal auditors, ISO/IEC 27001 certification bodies reading Annex A 5.24 through 5.30, NIS2 competent authorities, DORA financial-sector regulators, SOC 2 service auditors reading CC7.3 through CC7.5 and CC9.1, PCI DSS QSAs reading Requirement 12.10, HIPAA regulators reading 164.308(a)(6), the SEC reading Item 1.05 disclosures, and cyber insurance carriers reading post-claim documentation all read incident management evidence in similar shapes. The minimum durable pack is the residue of the operating work rather than a separate compilation produced at reading time.
- An incident register with one record per handled event, walking from detection through assessment, response, recovery, and the post-incident review. Each record carries the timestamps that prove the policy clocks were held against rather than reconstructed at audit time, the named handling owner per phase, the severity history, the affected-asset reference, the regulator notification artefacts where applicable, and the closure summary.
- A communication log per case that captures the internal stakeholder updates (executive briefings, board updates, business unit notifications), the external stakeholder communications (customer notifications, partner advisories, supplier coordination, public statements), the regulator notifications (GDPR Article 33, NIS2 Article 23, SEC Item 1.05, HIPAA, DORA, sector-specific clocks), and the law enforcement engagement where applicable. The communications log is the artefact a regulator inquiry reads alongside the technical chronology.
- An evidence custody record per case with the captured logs, system images, packet captures, malware samples, configuration snapshots, and the chain-of-custody trail per artefact (who captured it, when, what hash, where it is stored, who has touched it). The evidence record is the artefact a forensic provider, a regulator, an insurer, or a litigator reads when the incident moves into the post-response phase.
- A response action ledger per case with the technical actions (containment steps, isolation decisions, eradication actions, recovery steps), the operational actions (credential rotation, configuration rollback, asset rebuild), the supplier coordination, and the third-party engagement (forensic provider, counsel, communications support, cyber insurance carrier). Each action is timestamped, attributed to a named actor, and references the artefact the action produced.
- A post-incident review record per case that captures the timeline reconstruction, the root-cause analysis, the contributing-factor analysis, the impact assessment (operational downtime, data exposure scope, financial impact, regulatory consequence, reputational consequence), the lessons learned, the policy and procedure changes the review recommends, the follow-on action items with named owners and due dates, and the metric pack contribution.
- An exercising and training record that demonstrates the programme is exercised on the cadence the standard expects (annual full-scope exercise, semi-annual mid-scope exercises, monthly focused drills, trigger-driven rehearsals after material change). The record carries the exercise charter, the scenario, the participation roster, the observation rubric, the decisions captured, the after-action report, and the action item ledger so the exercise produces durable evidence rather than a one-off slide deck.
- A metric pack the programme reports against the policy: incidents detected by source, incidents by severity tier, time-to-detection, time-to-assessment-decision, time-to-containment, time-to-eradication, time-to-recovery, regulator-notification timeliness against the documented clock, post-incident review completion rate, lessons-learned action item closure rate, and exercise cadence achievement. The metric pack is the residue of the operating record rather than a separate reporting artefact compiled at board time.
Where SecPortal fits in an ISO/IEC 27035 programme
SecPortal is the operating layer for the incident management case lifecycle, not a replacement for the policy hierarchy, the executive crisis management discipline, the forensic provider relationships, or the legal counsel and communications partnerships that the standard expects. The platform handles the case-side workstreams (detection intake, assessment decision, response actions, communications log, evidence custody, post-incident review, lessons-learned action items, exercising trail) so the artefacts the policy commits to are produced as structured records rather than reconstructed across email threads, ticketing systems, and document drives at audit time. The same workspace that hosts the incident record hosts the SAST, dependency analysis, authenticated DAST, external scanning, and continuous monitoring evidence the response and post-incident verification phases depend on.
- Engagement management dedicated to the incident response programme, with one engagement record per handled incident so the detection signal, the assessment decision, the response actions, the communications log, the evidence trail, and the post-incident review sit on one record rather than being stitched together at audit time across email threads, ticketing systems, and document drives.
- Findings management with CVSS 3.1 scoring, CWE tagging, and 300+ structured templates so the technical findings inside an incident (the exploited vulnerability, the misconfiguration that enabled the lateral movement, the missing control that would have detected the access) are captured against the case record alongside the broader incident chronology.
- Document management for the published incident management policy, the response procedures, the communication plan, the regulator notification artefacts, the customer notifications, the post-incident review reports, and the exercise after-action reports, with version history per artefact so the policy refresh and the lessons-learned updates produce a defensible audit trail.
- AI report generation that turns the structured incident record into the executive briefing, the regulator notification draft, the customer notification draft, the board update, and the post-incident review summary, working against the structured timeline rather than against unstructured email content. The reports inherit the calibrated severity, the affected-asset references, the timestamps, and the response action ledger from the case record.
- Activity log with CSV export that captures every state change on the incident record (intake, assessment decision, severity adjustment, owner reassignment, response action attached, evidence artefact attached, communication sent, regulator notification dispatched, customer notification dispatched, post-incident review attached, action item closed), so an internal auditor, an external auditor, a regulator, an insurer, or counsel can reconstruct the incident timeline without a multi-team excavation.
- Team management with role-based access (owner, admin, member, viewer, billing) that keeps the incident response team, the security operations team, the GRC team, the communications team, the legal team, and the product engineering teams on the same workspace with appropriate scoping per role, plus MFA enforcement (TOTP) on accounts that touch the incident record so the audit trail is identity-grounded.
- Notifications and alerts that fire on case state changes (assessment decision pending, response action overdue, regulator notification window approaching, post-incident review due, action item due), so the programme operates against the policy clocks rather than relying on inbox vigilance during a live incident.
- Compliance tracking that reads the same evidence pack across ISO/IEC 27035, ISO/IEC 27001 Annex A 5.24 through 5.30, NIS2 Article 21 and 23, DORA Articles 19 and 20, SOC 2 CC7.3 through CC7.5 and CC9.1, PCI DSS Requirement 12.10, HIPAA 164.308(a)(6), the SEC cybersecurity disclosure rule, and NIST SP 800-61, so the cross-regime read is reconcilable rather than reconciled per audit.
- External scanning, authenticated DAST (cookie, bearer, basic, form), and code scanning (Semgrep SAST plus dependency analysis) on the same workspace as the incident record, so the verification evidence (was the exploited vulnerability actually present, did the same path appear elsewhere, did the fix close the path) is produced against the case rather than across separate tools.
- Continuous monitoring schedules (daily, weekly, biweekly, monthly) so the post-incident hardening is verified against the same workspace the original incident record lives in, rather than fading from view once the case closes.
- Encrypted credential storage (AES-256-GCM) for any privileged credentials needed during forensic capture, eradication, or post-incident verification, so the evidence collection and the recovery activities are reproducible without leaving credentials in shared documents or chat channels.
- Client portal with subdomain rewrite and branded delivery for incident notifications to enterprise customers, supplier coordination on cross-organisation incidents, and partner advisories, so the cross-organisation communications track lives on the same operating record as the technical track rather than running through a separate marketing or support tool.
The incident management evidence (planning, detection, assessment, response, communications, evidence custody, post-incident review, exercising) reads against operational workflows that already exist as named use cases. The incident response operating workflow carries the live-incident handling discipline the case record reads against. The breach notification and regulator readiness workflow carries the parallel notification queue model the communications track operates against when a case crosses regulator-clock thresholds. The PSIRT product security incident response workflow carries the case-management discipline for product-vulnerability incidents that pair with ISO/IEC 30111 and ISO/IEC 29147.
For internal security teams operating ISO/IEC 27035 as part of the wider security operating baseline, the internal security teams workspace bundles the platform with the engagement structure the response cadence reads against. For GRC and compliance teams reading the incident evidence against ISO 27001, SOC 2, NIS2, DORA, PCI DSS, HIPAA, and the SEC rule, the GRC and compliance teams workspace covers the policy hierarchy, the evidence pack, and the audit cadence the standard expects. For CISOs and security leaders carrying the programme-level reporting on the incident management posture and the post-incident accountability narrative, the CISOs and security leaders workspace covers the executive-layer reporting model that sits on top of the case operating record.
For deeper reading on the disciplines this standard reads against, the ISO/IEC 30111 framework page covers the product-vulnerability handling counterpart that pairs with 27035 for organisations that ship products. The ISO/IEC 29147 framework page covers the external disclosure interface that closes the trio. The NIS2 framework page covers the EU operating expectation Article 21 and Article 23 read against. The SEC cybersecurity disclosure framework page covers the public-company disclosure rule the materiality determination feeds into. The incident response plan guide covers the practical IR plan structure that operationalises the standard. The incident response tabletop exercise guide covers the exercising cadence Phase 1 (plan and prepare) commits to. The ransomware readiness programme guide covers the ransomware-specific operating model that runs the standard against the most common live-incident scenario. The SEC cybersecurity incident materiality guide covers the disclosure-decision discipline US public companies operate alongside the broader ISO/IEC 27035 cycle.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Phase 1: Plan and prepare
The programme produces the documented incident management policy, the named team and role assignments, the communication plan, the response procedures the team will follow under pressure, the training and exercise schedule, the technical readiness (logging, asset inventory, evidence collection capability, forensic tooling), and the agreements with external parties. Plan and prepare is the phase the rest of the cycle depends on; programmes that skip it operate the next four phases by improvisation.
Phase 2: Detection and reporting
The programme detects the security event from monitoring, scanner output, user report, third-party notification, partner advisory, or supplier disclosure, and opens the structured incident record. Detection and reporting names the source, captures the initial signals, opens the named handling owner, starts the policy clock, and routes the case according to severity. The discipline expects a structured intake record rather than an email thread or a chat channel.
Phase 3: Assessment and decision
The handler assesses whether the reported event is an incident, classifies the type, calibrates the severity against the documented criteria, and records the decision to escalate, contain, monitor, or close. Assessment is the gate that turns a reported event into a tracked incident the rest of the cycle reads against; the decision is captured on the record with the named decider, the timestamp, and the rationale.
Phase 4: Response
The team operates the technical response (containment, eradication, recovery), the communications response (regulator notifications under GDPR Article 33, NIS2 Article 23, SEC Item 1.05, HIPAA, DORA, sector-specific clocks), the evidence response (forensic preservation, chain of custody, log capture), and the operational response (asset isolation, credential rotation, supplier coordination). The standard expects all four tracks to run in parallel against one record.
Phase 5: Lessons learned
The programme closes the case, captures the post-incident review (what happened, what worked, what failed, what the programme will change), updates the policy and the procedures where the incident exposed gaps, schedules the follow-on testing and exercising the gaps require, and feeds the metric pack reporting to leadership. Lessons learned is the phase that turns the response into the next planning iteration.
Pairing with ISO/IEC 30111 and 29147
ISO/IEC 27035 covers information security incidents inside an ISMS. ISO/IEC 30111 covers product vulnerability handling inside an engineering organisation. ISO/IEC 29147 covers the external disclosure interface. The three are complementary; programmes that ship products and operate ISMS-grade incident response work all three. The same case identifier can walk across the records when an incident is the trigger for a vulnerability handling case or vice versa.
Alignment with ISO/IEC 27001 Annex A
Annex A controls 5.24 (incident management planning and preparation), 5.25 (assessment and decision on information security events), 5.26 (response to information security incidents), 5.27 (learning from information security incidents), 5.28 (collection of evidence), 5.29 (information security during disruption), and 5.30 (ICT readiness for business continuity) all read against the operating discipline ISO/IEC 27035 names. Programmes that adopt 27035 produce the evidence Annex A 5.24 through 5.30 expects, and the incident register feeds the wider ISMS audit cycle.
Audit evidence the programme produces
The minimum durable pack is the published incident management policy with version history, the incident register with one record per handled event, the communication log per case, the evidence custody record per case, the response action ledger, the post-incident review record, the exercising and training record, and the metric pack reporting against the policy clocks. The pack is the residue of the operating work rather than a separate compilation produced at audit time.
Related features
Orchestrate every security engagement from start to finish
Vulnerability management software that tracks every finding
Document management for every security engagement
AI-powered reports in seconds, not days
Every action recorded across the workspace
Collaborate across your entire team
Compliance tracking without a full GRC platform
Monitor continuously catch regressions early
Run an ISO/IEC 27035-aligned incident programme on one record
Hold the policy, the incident register, the communications log, the evidence custody trail, the response action ledger, the post-incident review, and the exercising trail on one workspace, then read the same record across ISO/IEC 27035, ISO/IEC 27001 Annex A 5.24 through 5.30, NIS2, DORA, SOC 2, PCI DSS, HIPAA, and the SEC cybersecurity disclosure rule. Start free.
No credit card required. Free plan available forever.