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…

Question

Exhibit

Answer Area

Explanation

ISO/IEC 27001:2022 - Incident Management Process Ordering

Key Insight First

This question has a hidden challenge: only 4 of the 6 available items belong in the correct sequence. Two items ("task creation and management" and "SLA management and escalation") are distractors - they represent real concepts but are not discrete sequential stages in this incident handling model.

Why This Specific Order

The logic follows a simple principle: you cannot act on information you don't yet have. Each stage produces the input required by the next.

Step-by-Step Reasoning

1. Incident Categorisation (first)

Determine whether an incident is an event or a security incident and assign a category.

You must first establish what you are dealing with. Not every alert is a security incident - many are just events (expected or benign occurrences). Until you confirm something is a genuine incident and categorise its type, no further action is meaningful. Acting before categorising wastes resources and can misdirect the response entirely.

Common mistake: Treating this as "classification" or confusing it with prioritisation. Categorisation answers "what is it?" - prioritisation answers "how serious is it?" These are distinct questions answered in sequence.

2. Incident Assignment (second)

Identify a point of contact and assign to an incident handler.

Once you know what the incident is, you can assign the right person or team. You need a known category before you can direct the incident to the appropriate handler (e.g., a data breach goes to a different handler than a malware infection). The handler takes ownership and drives everything that follows.

Common mistake: Assigning before categorising. If you assign before you know the incident type, you risk assigning to the wrong handler and losing time.

3. Incident Prioritisation (third)

Classify the incident in terms of its impact to the business.

The assigned handler is now responsible for assessing business impact and assigning a severity level (e.g., Critical / High / Medium / Low). This requires both category context (step 1) and an accountable owner (step 2) to make a meaningful impact judgement. Priority determines urgency and the resources allocated to resolution.

Common mistake: Prioritising before assigning. Prioritisation should be the assigned handler's first act - it is their assessment to make, not a pre-assignment triage step in this model.

4. Incident Resolution (fourth)

Implement solutions to resolve the incident and restore normal operations.

Only once the incident is fully understood (categorised), owned (assigned), and scoped (prioritised) can an effective remediation be executed. The resolution approach depends directly on outputs from all prior steps.

Why the Two Remaining Items Are Excluded

Summary Mental Model

What is it?  →  Who owns it?  →  How urgent is it?  →  Fix it.
Categorise   →  Assign        →  Prioritise          →  Resolve

This sequence is consistent with ISO/IEC 27035 (the supporting standard for incident management referenced under ISO 27001:2022) and reflects the principle that each decision gate requires the output of the previous one.

No community discussion yet for this question.