RS.MI-01: Incidents are contained

RS.MI-01 (“Incidents are contained”) requires you to prove that, once an incident is detected, you can rapidly limit its spread and impact through predefined containment actions, clear decision rights, and repeatable technical playbooks. Operationalize it by defining containment objectives, mapping them to systems and roles, and retaining evidence from real events and exercises. ¹

Key takeaways:

• Containment is a measurable operational outcome: stop propagation, isolate affected assets, and prevent re-compromise. ¹
• You need pre-approved containment playbooks with decision authority, not ad hoc heroics during a crisis.
• Audit readiness hinges on evidence: tickets, timelines, commands/runbooks executed, and post-incident reviews tied to containment actions.

RS.MI-01 is easy to agree with and easy to fail in practice because it sits at the boundary between policy and real-time operations. A written incident response plan does not meet the requirement if your teams cannot execute containment under pressure, across hybrid environments, and with third parties in the loop. The exam question you should anticipate is simple: “Show me how you contained your last incident.” If your answer is a narrative without hard artifacts, the control will be scored as weak even if your team did the right thing.

For a CCO, GRC lead, or security risk owner, the fastest way to make RS.MI-01 defensible is to (1) define what “contained” means for your organization, (2) pre-stage the technical controls and access needed to isolate systems, accounts, and network segments, and (3) prove repeatability with logs, tickets, and after-action documentation. NIST CSF 2.0 is outcome-driven, so focus your implementation on outcomes, decision rights, and evidence rather than perfect prose. ¹

Requirement: rs.mi-01: incidents are contained requirement

What the requirement expects: once you confirm or strongly suspect a cybersecurity incident, you must be able to limit its spread and reduce impact through timely isolation and control actions that are planned, authorized, and executable across your environment. ¹

Containment is distinct from:

• Eradication (removing the adversary and root cause)
• Recovery (restoring systems and business operations)

RS.MI-01 cares about the “stop the bleeding” phase: isolate affected endpoints, restrict credentials, block indicators, segment networks, suspend risky integrations, and prevent lateral movement.

Regulatory text

Excerpt: “Incidents are contained.” ¹

Operator interpretation: you must have a defined containment approach and be able to demonstrate that it is executed during incidents. In practice, that means:

• A containment decision path (who can approve isolation, account disables, blocking traffic, and taking systems offline).
• Technical playbooks aligned to common incident types (ransomware, BEC, cloud credential compromise, third-party compromise, data exfiltration).
• Evidence that actions were performed and were effective at limiting propagation/impact. ¹

NIST CSF 2.0 is designed to be mapped into governance and operating routines. Treat RS.MI-01 as a control with a named owner, procedures, and recurring evidence collection, not a one-time policy statement. ²

Who it applies to

Entities: any organization that operates a cybersecurity program and uses NIST CSF 2.0 as its framework baseline, whether voluntarily or as part of customer/third-party expectations. ¹

Operational context (where containment breaks down):

• Hybrid identity (on-prem AD plus cloud IdP) where disabling access in one plane does not stop access in another.
• Distributed endpoints (remote workforce) where isolation requires EDR reachability and pre-authorized actions.
• Cloud-native workloads where containment depends on security groups, IAM, keys, tokens, and workload isolation.
• Third parties (managed services, SaaS, incident response firms) where containment requires contractual rights, escalation channels, and shared runbooks.

Plain-English interpretation

If an attacker gets in, you must be able to box the incident in fast enough that it doesn’t become an enterprise-wide event. “Fast enough” is not a universal number; your program needs to define containment targets based on business impact, system criticality, and plausible attacker paths, then show that teams can meet those targets in real events or simulations. ¹

What you actually need to do (step-by-step)

1) Define “containment” outcomes for your environment

Create a one-page Containment Objectives document that answers:

• What does “contained” mean for endpoint malware, credential compromise, data exfiltration, and service disruption?
• What systems are in scope (crown jewels, regulated data stores, critical SaaS)?
• What are the acceptable containment actions (isolation, block, disable, shutdown), and what are the business constraints?

Keep it operational. This becomes the standard your incident commander will use.

2) Assign decision rights and escalation paths

Containment often requires disruptive actions. Pre-authorize them:

• Name the Incident Commander role and backups.
• Define who can approve:
  • Endpoint isolation
  • Account disable / token revocation
  • Network segmentation changes
  • Email tenant restrictions (forwarding rules, external sharing)
  • Taking a production service offline
• Define the business approver for high-impact actions (e.g., app owner, operations lead), and a “break-glass” path for emergencies.

Auditors look for clarity on who can act without waiting for a committee.

3) Build containment playbooks by incident type

Write short, executable playbooks. Each playbook should include:

• Trigger conditions (what evidence starts containment)
• Immediate containment actions (first actions the team takes)
• Secondary containment (hardening to prevent re-entry)
• Verification steps (how you confirm the spread stopped)
• Rollback guidance (how to restore access safely)

Minimum playbooks most programs need:

• Ransomware or destructive malware
• Suspected credential theft (cloud or VPN)
• Business email compromise
• Third-party compromise affecting your environment
• Suspected data exfiltration from cloud storage

Tie each playbook to the tools you actually run (EDR, SIEM, IAM, MDM, firewall, cloud controls).

4) Pre-stage technical capabilities (containment “muscle”)

Containment fails when teams lack access or tooling during the event. Validate you have:

• EDR capability to isolate hosts and collect triage data
• Central IAM controls to disable accounts, revoke sessions, rotate keys
• Email security controls to block rules, quarantine, and restrict external forwarding
• Network controls to block known bad IPs/domains and segment quickly
• “Break-glass” accounts with tight monitoring for emergency actions

Document where each capability lives and who can operate it.

5) Run containment tests and capture evidence

Prove the playbooks work:

• Tabletop exercises that walk through decision rights and approvals
• Technical simulations (where safe) to validate isolation, token revocation, segmentation, and verification steps
• Post-exercise improvements with owners and due dates

Evidence from exercises counts when real incidents are rare, but you still need to show the actions were tested and improved over time. ¹

6) Operationalize evidence collection (make audits easy)

For each containment event (real or simulated), collect:

• A ticket/case ID and timeline
• The containment actions executed
• Who approved disruptive actions
• Logs/screenshots/exports proving actions occurred (EDR isolation event, IAM disable event, firewall block change, SaaS admin audit logs)
• Verification results (no further spread, stopped outbound connections, reduced alert volume tied to the incident scope)
• Lessons learned and playbook updates

A practical control design pattern is to map RS.MI-01 to a policy statement, a procedure/runbook set, a named control owner, and a recurring evidence cadence. ²

Required evidence and artifacts to retain (audit-ready list)

Use this as your evidence checklist:

• Incident Response Policy with a containment section mapped to RS.MI-01 ¹
• Containment Objectives one-pager (internal standard)
• Incident severity matrix showing containment expectations by severity (internal standard)
• Playbooks/runbooks for top incident scenarios
• On-call roster and escalation matrix (including third-party contacts where applicable)
• Tooling access model for containment actions (RBAC, break-glass procedures)
• For each incident/exercise:
  • Case record/ticket
  • Chat/channel transcript or bridge notes (if used)
  • Change records for network/IAM/email containment actions
  • System audit logs evidencing the actions
  • Post-incident review with action items and owners

Retention duration should match your organization’s broader incident record retention standard.

Common exam/audit questions and hangups

Expect these questions and prepare “show me” answers:

1. “Show the last incident and how it was contained.” Provide the case timeline plus tool logs.
2. “Who can isolate a host or disable an exec’s account?” Provide decision rights and evidence of tested approvals.
3. “How do you contain a cloud credential compromise?” Provide IAM runbooks: session revocation, key rotation, conditional access changes.
4. “How do you coordinate containment with third parties?” Provide contract language or SOPs that define notification and action authority, plus escalation contacts.
5. “How do you verify containment worked?” Provide verification steps and metrics you track internally (qualitative is acceptable if consistent and documented).

Frequent implementation mistakes (and how to avoid them)

• Mistake: One generic “containment” paragraph in the IR plan.
  Fix: Create playbooks with concrete actions per incident type and map them to tooling owners. ¹

• Mistake: Approval bottlenecks for disruptive actions.
  Fix: Pre-approve actions by severity and define emergency authority with after-the-fact review.

• Mistake: No proof actions occurred.
  Fix: Make evidence capture part of the incident workflow (ticket template fields, required attachments, change record links). ²

• Mistake: Containment limited to endpoints.
  Fix: Include identity, email, SaaS, and cloud control-plane containment steps.

• Mistake: Third-party containment is assumed, not contractually enabled.
  Fix: Ensure incident clauses include notification timing, coordination expectations, and access/support commitments for containment activities.

Enforcement context and risk implications

NIST CSF itself is a framework, not a regulator. The risk is indirect but real: if you cannot demonstrate containment capability, you increase operational loss and you may fail customer security reviews, cyber insurance underwriting expectations, or regulator-aligned examinations that look for incident response effectiveness. Treat RS.MI-01 evidence as board-level defensibility: you can show you acted promptly and in a controlled way. ¹

Practical 30/60/90-day execution plan

Day 0–30: Stabilize and define

• Assign RS.MI-01 control owner and backups.
• Publish containment decision rights and escalation matrix.
• Draft Containment Objectives and a severity-based containment action table.
• Inventory containment tools and confirm access paths (including break-glass).

Day 31–60: Build and test

• Write and approve top incident-type containment playbooks.
• Run tabletop exercises focused on disruptive decisions (isolation, shutdown, credential revocation).
• Update ticket templates to require containment evidence fields and attachments.

Day 61–90: Prove repeatability

• Execute at least one technical containment drill per major environment (endpoint, identity, cloud, email) where safe to do so.
• Perform a post-exercise review and update playbooks with tracked remediation items.
• Create an evidence binder structure for auditors (by incident/exercise) and start recurring evidence collection.

Where Daydream fits naturally: If you struggle to keep RS.MI-01 mapped to an owner, procedures, and consistent evidence packets across incidents and exercises, Daydream can centralize the control mapping and automate recurring evidence requests so audits don’t start from scratch each cycle. ²

Frequently Asked Questions

What counts as “contained” for RS.MI-01?

“Contained” means you have limited spread and reduced impact by isolating affected assets, cutting off attacker access paths, and preventing re-compromise while you investigate. Define your own containment outcomes per incident type and prove execution with logs and case records. ¹

Do we need to show containment for real incidents, or are exercises enough?

Real incidents are strongest evidence, but exercises and simulations can support the requirement when they are documented and produce corrective actions. Keep the same evidence package structure for both so auditors can review consistently. ¹

How do we handle containment when a third party runs the affected system?

Your process must include coordination steps, named contacts, and clear authority to request containment actions. Align this with third-party contract terms and escalation runbooks so containment does not stall during legal or commercial debates.

What evidence is most persuasive in an audit?

Time-ordered incident tickets plus system audit logs showing the containment actions happened (EDR isolation, IAM disables, firewall changes) and who approved them. Add a short post-incident review tying actions back to the playbook.

Can containment actions break production. How do we balance that with uptime goals?

Pre-approve containment actions by severity and system criticality, with a documented business sign-off path and emergency authority. Auditors accept disruptive actions when the decision model is documented and consistently followed.

We have playbooks, but teams don’t follow them. How do we fix adoption?

Make the playbooks the default workflow: integrate them into ticket templates, on-call procedures, and access provisioning. Then test them and track corrective actions to closure so the process improves over time. ²

Footnotes

1. NIST CSWP 29

2. NIST CSF 1.1 to 2.0 Core Transition Changes