PECB ISO/IEC 27035 Foundation Exam Practice & Certification Guide 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 vocabulary).

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 that may be security relevant; not every event is an incident.

Incident management is built on the Plan-Do-Check-Act cycle: Plan = policy and approach, Do = detect, report, assess, respond, Check = review and learn, Act = improve controls and process.

ISO/IEC 27035 is a multi-part standard: Part 1 principles and process, Part 2 guidelines for planning and preparing incident response, Part 3 guidelines for incident management operations, and Part 4 coordination and information sharing.

ISO/IEC 27035 is guidance that complements ISO/IEC 27001 and ISO/IEC 27002; certification of an ISMS is against 27001, not against 27035.

Core principles include establishing an incident management policy, a management-approved incident response plan, clear roles and responsibilities, and a documented, repeatable process.

An incident management policy is a management-approved document stating objectives, scope, authority, commitment and how the process is governed; it is distinct from the operational response plan.

Incident management is a subset of broader information security management; its outputs (lessons learned, control gaps) feed risk assessment and continual improvement under ISO/IEC 27001 Clause 10.

Terminology order matters: event -> incident candidate (suspicious event) -> incident; classification and prioritisation occur after detection and before response.

ISO/IEC 27035 process phases: (1) plan and prepare, (2) detect and report, (3) assess and decide, (4) respond, (5) learn lessons; each phase has defined inputs, activities and outputs.

Detection sources include automated monitoring (IDS/IPS, SIEM, antivirus, log correlation), user reports, third-party notifications, and vulnerability or audit findings; reporting channels must be known and easy to use.

Assessment and decision determines whether an event is an incident, then classifies it by type and severity/impact using defined criteria, and assigns a priority that drives escalation and resource allocation.

Response activities include containment (short-term and long-term), eradication of root cause, recovery of affected services, and communication with internal and external stakeholders.

Incident classification schemes typically use dimensions such as incident type (malware, unauthorized access, DoS, data breach, phishing) and impact level (low, medium, high, critical) mapped to response times.

The incident response team (IRT) has defined roles: incident manager/coordinator, technical analysts, communications/PR, legal and compliance, HR, and business owners; contact lists and escalation paths are maintained and tested.

Evidence handling follows forensic readiness principles: preserve integrity with chain of custody, hashing, write-blocking and secure storage, so evidence remains admissible and defensible.

Communication and information sharing are governed by predefined templates and approval rules; regulatory and contractual notification obligations (for example breach notification timelines) are identified during planning.

Lessons learned (post-incident review) is performed after closure, producing root-cause findings, updated risk assessments, control improvements and updated procedures, feeding back into the plan-and-prepare phase.