ISO 27035 LIM cheat sheet

Information security incident: a single or series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security (ISO/IEC 27035-1).

Information security event: an identified occurrence of a system, service or network state indicating a possible breach of policy or control, or a previously unknown situation relevant to security. Not every event is an incident; escalation depends on assessed impact.

Information security incident management is the exercise of a consistent and effective approach to handling incidents, comprising policy, detection, reporting, assessment, response, and lessons learned.

ISO/IEC 27035 is structured in parts: 27035-1 (principles and concepts), 27035-2 (planning and preparing incident response), 27035-3 (guidelines for ICT incident response operations).

Core roles: information security incident management team (ISIMT), incident manager, incident responders, and business/asset owners; the ISIMT coordinates response but accountability for risk stays with management.

Incident vs. weakness vs. vulnerability: a vulnerability is a weakness that can be exploited; exploitation produces events; an event with significant probability of harm becomes an incident.

Incident management supports the ISO/IEC 27001 clauses on nonconformity and corrective action and on information security incident management (Clause 5.24-5.28 in ISO/IEC 27001:2022).

Benefit objectives: reduce impact and likelihood of incidents, improve detection, satisfy legal and regulatory reporting duties, and feed lessons learned into continual improvement.

The ISO/IEC 27035 process has five main phases: (1) Plan and Prepare, (2) Detect and Report, (3) Assess and Decide, (4) Respond, and (5) Learn Lessons; each phase has inputs, activities, and outputs.

Plan and Prepare establishes policy, the ISIMT, reporting channels, classification scheme, and awareness, and produces the incident response plan and supporting procedures.

Detect and Report covers detection via monitoring, automated alerts, and human reporting; every report enters a single point of contact (incident reporting desk or hotline) to avoid lost reports.

Assess and Decide evaluates the event against classification criteria to confirm whether it is an incident, assign severity, and determine the response level and escalation path.

Respond includes containment, eradication, recovery, and communication; containment strategy balances business continuity against evidence preservation.

Learn Lessons produces post-incident analysis, root cause identification, and improvement actions that are tracked to closure and fed back to Plan and Prepare.

Each phase should define entry and exit criteria, responsible roles, records produced, and time targets; the process is iterative, not strictly linear, when new information emerges.

Communication and evidence handling run across all phases; evidence must be collected in a forensically sound, admissible way, with chain of custody documented.

Scope the process using the organizational context and interested parties: identify legal, regulatory, contractual, and sector-specific incident reporting obligations before designing procedures.

Obtain top management commitment: an approved incident management policy defines objectives, roles, authority, and the mandate of the ISIMT.

Define an incident classification scheme with severity levels based on impact (confidentiality, integrity, availability) and scale; classification drives escalation and notification thresholds.

Establish reporting channels that are simple, known to all staff and third parties, and monitored 24/7 where required; include an alternative channel if primary systems are compromised.

Define interfaces with related processes: business continuity, crisis management, IT service management (incident and problem management), legal, HR, communications, and law enforcement.

Build the ISIMT with named roles, deputies, and contact details; ensure competence through training and exercises, and document succession and out-of-hours coverage.

Document the incident response plan with procedures, playbooks, contact lists, and decision trees; keep it version-controlled and accessible when primary systems fail.

Design metrics and reporting (time to detect, time to respond, time to contain, recurrence) so the process can be measured and improved.

The incident response plan should define triggers, activation authority, escalation matrix, communication plans (internal, external, media), and criteria for declaring a crisis.

Prepare an incident response toolkit: forensic tools, secure communication channels, offline copies of contacts and plans, logging capability, and evidence-handling materials.

Test the plan through tabletop exercises, simulations, and technical drills; record findings and update the plan and training accordingly.

Execution sequence: confirm and classify the incident, activate the ISIMT, contain, eradicate, recover, and then conduct post-incident review.

Containment options include isolating hosts, disabling accounts, blocking network segments, and applying temporary controls; choose based on impact and evidence needs.

Notification duties: inform management, affected parties, regulators, and law enforcement per legal and contractual requirements, using predefined templates and approval authority.

Preserve evidence with documented chain of custody: record who collected what, when, where, and how, using hashing and write-blocking where feasible.

Declare incident closure only when recovery is verified, root cause is understood, and improvement actions are assigned with owners and dates.

Operate a single incident register or ticketing system that logs all reports, classification, actions, decisions, and evidence references with timestamps.

Triage consistently: apply the classification scheme, record rationale for severity, and reassess as facts change; document escalation and de-escalation decisions.

Maintain situational awareness through logging, monitoring, and threat intelligence; correlate alerts to reduce false positives and improve detection.

Coordinate response across technical teams and business owners; the incident manager owns the process and communications, not necessarily the technical fix.

Manage communications using predefined templates, single spokespersons, and approval chains for external statements to avoid inconsistent or premature disclosure.

Track incidents against SLAs and KPIs; record time stamps at each phase to enable measurement and later analysis.

Handle insider and third-party incidents with additional care: involve HR, legal, and procurement, and preserve confidentiality and evidence integrity.

Keep records sufficient for audit and regulatory reporting, including decisions taken, their justification, and the individuals responsible.

Conduct post-incident reviews for all significant incidents and periodically for lower-severity ones; output root cause analysis and corrective actions.

Feed lessons learned into Plan and Prepare: update policy, classification criteria, playbooks, contact lists, and training based on observed gaps.

Use metrics and trend analysis (incident volume by type, detection time, containment time, recurrence) to identify systemic weaknesses and prioritize improvements.

Perform regular exercises and audits of the incident management process; compare results with objectives and record findings for management review.

Track corrective and preventive actions to closure with owners and due dates, verifying effectiveness rather than only completion.

Link improvements to the broader ISMS continual improvement cycle (ISO/IEC 27001 Clause 10) so incident findings inform risk assessment and control selection.

Benchmark against good practice and standards updates, and review the process at planned intervals or after major incidents or organizational change.

Capture quantitative and qualitative feedback from responders and business stakeholders to improve usability and response speed.