Incident Management and Case Workflows
This domain tests how incidents and cases are shaped, routed, and closed: incident types, fields, layouts, classification and mapping, and the lifecycle rules the exam expects you to configure rather than code.
Core rules
- An incident type is the anchor: it selects the default playbook, the layout, and often the fields shown to the analyst. Customizations belong in a duplicated type, not the built-in one.
- Custom fields have a type, an internal name, and a display label. A field only appears on an incident if the layout includes it.
- Classification runs first and decides the incident type; mapping then fills fields from the raw ingested data. Reversing that order is a common design error.
- Pre-processing rules can drop, merge, or retype incidents before they are created.
- Closing an incident records a close reason and notes, and the War Room keeps the audit trail of every command and task.
Worked example
A mailbox integration must create Phishing incidents. Reasoning: the classifier matches sender domain or subject keywords and assigns the Phishing type; the mapper copies sender to the reporter email field and subject to the subject field; the Phishing type's layout shows those fields; its default playbook extracts indicators. A test fetch confirms the mapper output before the playbook runs.
Traps
Expecting a layout change to show up on open incidents without a refresh, confusing a field's display label with its internal name inside mapper expressions, and assuming incident-type edits apply retroactively to existing incidents.