IM Incident ManagementClose in Operations
Detect security incidents through logging and analysis, and respond to them through a defined, staffed and exercised process. Streams: Incident Detection; Incident Response.
Partly covered — 56%. The controls beneath it are covered in some of the places your profile required them and not in others.
No single control answers this requirement outright, so the 3 partial mappings your profile required are averaged.
Closing the 13 scopes listed here would move your overall coverage by 6.0 percentage points — exactly, over the same denominator the headline uses.
Counted toward this requirement These produced the number above.
Security Log Centralization ◐ 2 of 3 scopes
Partial mapping · high confidence
What it is Security-relevant logs from applications, platforms and security tools are collected centrally and retained. Why it matters Logs that stay on the machine are lost when it is replaced, and can be edited by whoever compromised it. Why it maps IM-A begins with logs that exist, are retained and are in one place.
What would close it
The required scopes nothing covers today:
Environment Technology Phase Control point Development any Monitor / Respond SIEM
In place looks like Security-relevant logs from applications, platforms and security tools are shipped to a central store outside the systems that produce them, and kept for a defined period.
Runtime Threat Detection ○ 0 of 12 scopes
Partial mapping · high confidence
What it is Suspicious behaviour of a running workload is detected and raised as a security event. Why it matters Preventive controls are a filter rather than a wall, and an application compromised through an unknown flaw looks normal to everything that ran before deployment. Why it maps Supplies the workload-level signal IM-A detection depends on.
What would close it
The required scopes nothing covers today:
Environment Technology Phase Control point Development Docker Operate Runtime Development Docker Monitor / Respond SIEM Development Kubernetes Operate Runtime
Incident Response Plan ● 1 of 1 scopes
Partial mapping · high confidence
What it is A documented plan names roles, escalation paths and communication duties before an incident happens. Why it matters Decisions about isolation, disclosure and escalation are made badly at three in the morning if they have not been made in advance. Why it maps IM-B asks for a documented process with defined roles; the plan is that document, not the staffing behind it.
Covered everywhere your profile required it.
Your profile never required these The catalog maps them to this requirement; your baseline did not ask for them. They are listed, not scored — nothing was demanded of them, so nothing about them has failed.
Security Event Correlation not required
Partial mapping · high confidence
Why it maps IM-A at higher maturity: analysis that turns events into a detected incident.
Security Incident Handling not required
Partial mapping · high confidence
Why it maps IM-B in practice: the plan is executed, recorded and reviewed afterwards.
Supporting only, never counted A control that merely helps cannot be the reason something is called satisfied. Listed so you can see the whole picture, never counted.
Detection Rule Management not required
Supporting · medium confidence
Why it maps Detection quality is a maintained asset, not a one-time configuration.
Detection Coverage Review not required
Supporting · medium confidence
Why it maps Answers what IM-A cannot see, which is the question a detection programme lives on.
Runtime Response Enforcement not required
Supporting · medium confidence
Why it maps Automated containment shortens the response IM-B measures.
Attack Simulation Exercise not required
Supporting · medium confidence
Why it maps IM-B at higher maturity expects the response process to be exercised rather than assumed to work.