LEAD-AUDITOR · Question #340
Drag and Drop Question Your organisation is currently seeking ISO/IEC27001:2022 certification. You have just qualified as an Internal ISMS auditor and the ICT Manager wants to use your newly…
The correct answer is Incident logging - Record the incident details in a centralized log or tracking system.; Incident identification - Identify the incident and confirm it is a genuine incident.; Incident prioritization - Classify the incident based on its severity and impact.; Incident containment - Contain the incident to limit further damage.; Incident eradication - Remove the cause of the incident and restore systems to normal operation.; Incident recovery - Restore systems and data from backups or alternative sources if needed.; Incident closure - Formally close the incident and document all actions taken.; Post-incident review - Analyze the incident response process for lessons learned. ISO/IEC 27001:2022 - Incident Management Process: Explained Overview ISO/IEC 27001:2022 Annex A Control 5.26 ("Response to information security incidents") and the companion standard ISO/IEC 27035 define a structured incident lifecycle. The logic is: detect → record → assess →…
Question
Drag and Drop Question Your organisation is currently seeking ISO/IEC27001:2022 certification. You have just qualified as an Internal ISMS auditor and the ICT Manager wants to use your newly acquired knowledge to assist him with the design of an information security incident management process. He identifies the following stages in his planned process and asks you to confirm which order they should appear in. Answer:
Exhibit
Answer Area
Drag items
Correct arrangement
- Incident logging - Record the incident details in a centralized log or tracking system.
- Incident identification - Identify the incident and confirm it is a genuine incident.
- Incident prioritization - Classify the incident based on its severity and impact.
- Incident containment - Contain the incident to limit further damage.
- Incident eradication - Remove the cause of the incident and restore systems to normal operation.
- Incident recovery - Restore systems and data from backups or alternative sources if needed.
- Incident closure - Formally close the incident and document all actions taken.
- Post-incident review - Analyze the incident response process for lessons learned.
Explanation
ISO/IEC 27001:2022 - Incident Management Process: Explained
Overview
ISO/IEC 27001:2022 Annex A Control 5.26 ("Response to information security incidents") and the companion standard ISO/IEC 27035 define a structured incident lifecycle. The logic is: detect → record → assess → limit damage → remove cause → restore → close → learn. Each step gates the next - you cannot safely skip ahead.
Step-by-Step Breakdown
1. Incident Logging
Record the incident details in a centralized log or tracking system.
Why first: Before any action is taken, you need an auditable record. This creates the chain of custody, timestamps the event, and satisfies legal/regulatory evidence requirements. Without logging first, later investigation and post-incident review have no baseline to work from.
Common mistake: Teams jump straight to containment and log retroactively - this risks missing details and undermines legal defensibility.
2. Incident Identification
Identify the incident and confirm it is a genuine incident.
Why second: Not every alert is a real incident. This step filters false positives and confirms you are dealing with an actual security event before mobilizing resources. It also scopes the incident (what type? what systems?).
Common mistake: Treating all alerts as confirmed incidents - wastes resources and creates alert fatigue.
3. Incident Prioritization (maps to "Risk assessment" in the available items)
Classify the incident based on severity and impact.
Why third: Once confirmed real, you must decide how urgent the response is before acting. Prioritization determines resource allocation, escalation paths, and response timelines (e.g., P1 vs P3). You cannot meaningfully contain an incident until you know its blast radius.
Common mistake: Skipping prioritization and treating all incidents with the same urgency - leads to resource misallocation and slower resolution of critical events.
Note on naming: The available items called this "Risk assessment" - same concept, different label. ISO 27035 uses the term "classification and prioritization."
4. Incident Containment
Contain the incident to limit further damage.
Why fourth: With the incident confirmed and prioritized, the immediate goal is to stop the bleeding - isolate affected systems, block malicious traffic, revoke compromised credentials. This is time-critical and must happen before eradication.
Why not first: Containment without identification and prioritization can cause collateral damage (e.g., taking down critical systems unnecessarily).
Common mistake: Jumping to eradication before containment - the attacker or malware may still be active and can re-infect cleaned systems.
5. Incident Eradication
Remove the cause of the incident and restore systems to normal operation.
Why fifth: Only after containment is the environment stable enough to safely remove the threat (malware, unauthorized access, misconfiguration). You eliminate the root cause here.
Common mistake: Confusing eradication with recovery. Eradication = removing the threat. Recovery = restoring services. Doing recovery before eradication risks restoring a still-compromised system.
6. Incident Recovery
Restore systems and data from backups or alternative sources if needed.
Why sixth: With the threat removed, you can safely restore services to normal operation. This may involve restoring from clean backups, rebuilding systems, or switching back from failover.
Common mistake: Restoring from backups before eradication - if the backup window pre-dates full eradication, you may restore infected data.
7. Incident Closure
Formally close the incident and document all actions taken.
Why seventh: Closure is a formal gate - it confirms all containment, eradication, and recovery actions are complete, stakeholders are notified, and the incident is officially resolved. It also finalizes the log record started in Step 1.
Common mistake: Closing incidents informally or not at all - creates gaps in audit trails and can mask recurring issues.
8. Post-Incident Review (PIR)
Analyze the incident response process for lessons learned.
Why last: The PIR requires the full incident to be over so you can assess the entire response lifecycle objectively. It feeds improvements back into the ISMS (ISO 27001 Clause 10 - Continual Improvement). It answers: What happened? Why? What did we do well? What must change?
Common mistake: Skipping the PIR under time pressure - this is where ISO 27001 gets its value; without it, the same incidents recur.
Key Pattern to Remember
LOG → IDENTIFY → PRIORITIZE → CONTAIN → ERADICATE → RECOVER → CLOSE → LEARN
Think of it as a fire response analogy:
- Log the fire call → Confirm it's real → Assess size → Contain spread → Extinguish → Restore the building → File the report → Review the response.
The investigation/root cause analysis (from the available items) is implicitly embedded in eradication (you must understand the cause to remove it) and formalized in the PIR - which is why it doesn't appear as a standalone step in the correct arrangement.
Topics
Community Discussion
No community discussion yet for this question.