PECB ISO/IEC 27035 Foundation Exam Practice & Certification Guide flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Information security incident

A single or series of unwanted or unexpected information security events with a significant probability of compromising business operations and threatening information security, requiring coordinated response rather than routine operational handling.

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 candidate

A suspicious event that has been reported or detected but not yet confirmed as an incident; it is assessed against defined criteria before classification and response decisions are made.

Plan-Do-Check-Act

The improvement cycle underlying ISO/IEC 27035: plan the approach and policy, do detection and response, check through review and lessons learned, act by improving controls and the process.

ISO/IEC 27035 structure

A multi-part standard: Part 1 covers principles and process, Part 2 planning and preparation, Part 3 incident management operations, and Part 4 coordination and information sharing between parties.

Incident management policy

A management-approved document stating objectives, scope, authority, commitment and governance for incident management; it sits above and directs the operational incident response plan.

Incident response plan

The documented operational plan describing how incidents are detected, reported, assessed, responded to and reviewed, including roles, resources, communication paths and escalation criteria.

Relationship to ISO/IEC 27001

ISO/IEC 27035 provides incident management guidance that supports ISO/IEC 27001 requirements; ISMS certification is against 27001, while 27035 is guidance and not a certifiable management system standard.

Roles and responsibilities

Clearly assigned duties for incident handling, such as incident manager, technical analysts, communications, legal and business owners, documented and understood before an incident occurs.

Continual improvement link

Incident findings, root causes and lessons learned feed risk assessment, control updates and corrective actions, supporting the improvement requirements of an ISO/IEC 27001 ISMS.

Incident management awareness

Ensuring staff and relevant parties know what constitutes an incident, how to report it, and their role in response, established during planning and refreshed through training and exercises.

Terminology sequence

Events are observed first; suspicious ones become incident candidates; assessment confirms whether they are incidents, after which classification, prioritisation and response follow in that order.

Plan and prepare phase

The first ISO/IEC 27035 phase: establish policy, form the response team, define the process, prepare resources and tools, set communication channels and train participants before incidents occur.

Detect and report phase

The phase in which events are identified through monitoring, user reports or third parties and reported through defined channels to the responsible incident handling function.

Assess and decide phase

The phase that determines whether a reported event is an incident, classifies it by type and severity, assigns priority, and decides on escalation and the response approach.

Respond phase

The phase covering containment, eradication and recovery, together with internal and external communication, to limit impact and restore normal service operation.

Lessons learned phase

The post-incident phase that reviews what happened, identifies root causes, evaluates response effectiveness, and produces improvements to controls, procedures and the incident management plan.

Incident classification

Assigning an incident to defined categories such as malware, unauthorized access, denial of service, data breach or phishing, so that appropriate procedures and expertise are applied.

Severity and priority

Severity expresses the assessed impact and scale of an incident; priority translates severity plus urgency and business context into an ordering that drives escalation and resource allocation.

Incident response team

A defined group with assigned roles and contact details, authorised to handle incidents, coordinate technical analysis, manage communication and escalate to management when thresholds are met.

Escalation path

A documented route and trigger criteria for raising an incident to higher authority, additional specialists or management when severity, scope or risk exceeds defined thresholds.

Containment

Short-term and long-term measures that limit the spread and impact of an incident, such as isolating systems, blocking traffic, revoking credentials or applying temporary compensating controls.

Eradication

Removing the root cause of an incident, for example deleting malware, closing the exploited vulnerability or eliminating unauthorised access, before recovery begins.

Recovery

Restoring affected systems and services to normal operation, verifying integrity and security, and monitoring closely for recurrence before formally closing the incident.

Chain of custody

A documented record of who handled evidence, when, where and why, preserving integrity so that findings remain defensible in disciplinary, legal or regulatory proceedings.

Forensic readiness

Planning ahead so that logs, network data and system images can be collected and preserved with integrity, enabling investigation without disrupting business or destroying evidence.

Reporting channel

A known, easy-to-use route such as a service desk, hotline or mailbox through which staff and third parties report suspected incidents to the incident handling function.

Detection sources

Inputs that reveal incidents, including SIEM and IDS alerts, antivirus, log monitoring, user reports, third-party notifications, and audit or vulnerability findings.

Stakeholder communication

Planned, approved messaging to internal parties and external parties such as customers, regulators and law enforcement, using predefined templates and defined approval authority.

Notification obligations

Legal, regulatory and contractual duties to inform authorities or affected parties within set timeframes, identified during planning and triggered when an incident meets defined criteria.

Incident closure

The formal step confirming that response and recovery are complete, evidence and records are retained, and the incident is documented before lessons learned are conducted.

Testing and exercises

Simulations, tabletop exercises or technical drills that validate the incident response plan, contacts and tools, revealing gaps that are corrected during the plan-and-prepare phase.