RS.MI-01 Incident containment: requirements and evidence

What RS.MI-01 incident containment asks your organization to show

A security lead who must show that incidents are stopped from spreading needs to know that RS.MI-01 is a Subcategory of the Incident Mitigation (RS.MI) Category in the RESPOND Function of NIST CSF 2.0, with the outcome that incidents are contained. The risk it addresses is simple to describe and hard to close: an intrusion keeps moving laterally while people debate what to do next. The Subcategory is met when the organization can show that containment happens through four routes: automatic containment by security tools, containment by responders who choose actions, containment by an ISP or managed security service provider acting for the organization, and moving compromised endpoints to a remediation VLAN. Organizations that used CSF 1.1 will recognize the same item, since RS.MI-1 continues at the same identifier in the transition from 1.1 to 2.0.

The difficulty is that containment is judged by what happened and when, not by what the policy says. An assessor will want to see alert timestamps, the time between detection and the containment action, who authorized the action, and whether the endpoint was actually isolated or only flagged. A containment playbook that nobody has run recently proves little. Start by choosing which of the four routes apply to your environment, then pull examples from recent alerts or exercises that show each route working end to end. Confirm with your managed provider, if you use one, exactly which containment actions it may take alone and which need your approval, and keep that agreement in writing.

NIST does not certify CSF implementations or issue conformity assessments, so no body will stamp this Subcategory as met. Your organization owns the judgment, and an independent assessor, if you engage one, forms an opinion from the evidence you present. Ask any assessor how they will sample containment records and what period they will cover. Your own internal review should answer the same questions before an outside party asks them. Where you want a starting point for the wider framework, the NIST Cybersecurity Framework 2.0 publication sets out the Core and how its Subcategories are organized.

Which systems, teams and providers fall under RS.MI-01 containment

RS.MI-01 asks that incidents are contained, but containment only works where the organization has decided what can be isolated, who may act and who acts on its behalf. The cards below set out the scoping decisions that determine whether containment is quick, authorized and testable before an incident starts.

Endpoints and servers that can be isolated

Start with an inventory of workstations, laptops and servers that the responder team can isolate without breaking a critical process. For each class, record who owns the device, whether it can be taken off the network through an EDR or management agent, and what the business owner must approve first. Systems that cannot be isolated, such as some production controllers or clinical devices, need a documented alternative such as traffic blocking at the network edge. Confirm isolation works on each platform in a test before an incident relies on it.

Network devices and enforced segments

Containment at the network layer depends on which firewalls, switches and segments can block or restrict a host, and whether those devices are reachable by the responders during an incident. Map each segment to the device that enforces its boundary, and check whether changes are made through a change process or by an emergency procedure. Segments managed by a third party need access arrangements agreed in advance so that a block can be applied at any hour.

Security tools that act automatically

Antivirus, EDR and operating system features can contain a host without a person in the loop. These automatic actions should be listed with their triggers, such as a malware verdict or a high-severity detection, and with the exceptions that stop them firing on critical systems. Automatic containment that cannot be reversed quickly can disrupt operations, so the organization should decide which triggers may isolate a host on their own and which only raise an alert for a responder.

Responder team and its isolation authority

Name the people who may contain a system, the conditions under which they act and whether they need approval from the system owner or an incident commander first. Authority should be written into the incident response plan and tested in an exercise, not assumed. Check that responders have the access and tooling to act outside business hours and that a backup responder exists for each shift. Gaps here usually appear as delays, not as technical failures.

Third parties containing for the organization

An ISP or MSSP may block traffic or isolate a host on the organization's behalf. This only works if the contract or runbook grants that authority in writing, names the actions the provider may take, sets who is notified and states the hours when the provider acts without waiting for approval. Confirm the provider can reach your tools and networks, and rehearse the handoff. Ask any provider to show how it records containment actions in your case record.

The remediation VLAN itself

A remediation VLAN holds compromised endpoints in a restricted network while they are investigated or cleaned. Decide which devices are moved, who may move them, how access in and out is limited and how a device returns to production after validation. The VLAN must be configured and tested before it is needed, since an untested quarantine network can fail or leak traffic. Record each move and its approval so that the containment step can be shown to an assessor.

How an assessor tests RS.MI-01 containment

This table compares five things an independent assessor is likely to test for RS.MI-01, the test approach, the evidence requested and the findings that commonly appear. Read each row as a question the organization should be able to answer with records before the assessment starts. The assessor, not DeployOpen, forms and issues the conclusion on whether containment is operating.

Test area	Test approach and evidence requested	Common findings
Containment procedure and triggers	Assessor reviews the documented containment procedure, the conditions that start it, and who may authorize each containment action. Evidence includes the approved procedure, version history and the escalation criteria.	Procedure exists but does not define triggers, or it names roles that no longer exist.
Sampling of real incidents	Assessor selects a sample of recent incidents and checks the tickets, timestamps and actions taken. Evidence includes case records showing detection time, containment decision and the containment action performed.	Containment actions are missing from tickets, or timestamps are absent so timing cannot be verified.
Automatic containment rules	Assessor triggers a controlled test event, such as a benign test file or simulated alert, and observes whether the security tool contains the endpoint as configured. Evidence includes rule exports, test records and the resulting tool logs.	Rules are configured but never tested, or the test shows the tool logs the event without acting on it.
Remediation VLAN configuration and access	Assessor reviews the VLAN design, firewall rules for the remediation segment, and the list of accounts that can move endpoints in or out. Evidence includes network configuration exports, change records and access reviews.	Quarantined hosts retain access to file shares or the internet, or there is no record of who released an endpoint.
Third-party containment terms and logs	Assessor reads the contract or service terms with the ISP or MSSP that contain for the organization, then checks the provider's logs against the organization's own incident records. Evidence includes the agreed response times, escalation paths and provider action logs.	Terms define no containment authority, or provider logs cannot be matched to the organization's incidents.

How to implement containment so the evidence exists

This sequence turns RS.MI-01 from a policy statement into working containment that leaves records an assessor can trace. Each step produces an artifact, so the organization can show what was decided in advance, what the tools did, what responders did and that the actions were tested.

Define containment triggers and allowed actions
The security or incident response lead, with input from operations and system owners, writes a trigger matrix. It lists the alert types, asset classes and conditions that call for containment, and for each trigger it states whether the response is automatic or chosen by a responder, along with the actions permitted (isolate the endpoint, block an address, disable an account, suspend a session). Business owners approve any action that could interrupt a critical service. The step is done when the matrix is approved and every trigger has exactly one owner and one permitted action set. Ask the auditor which level of detail they expect before you finalize it.
Configure automatic containment in existing tools
Engineers translate the automatic rows of the trigger matrix into rules in the tools you already run, such as endpoint protection, the EDR platform, the firewall or the identity provider. Where open-source options fit, osquery can supply host state used to scope a rule, and Shuffle can run an automated workflow that calls a firewall or ticketing API. Each rule is tested against a known benign and a known malicious sample in a non-production group. The step is done when each rule has a version-controlled configuration, a test result and a log entry that shows it fired.
Build the remediation VLAN and movement rules
Network engineers create a remediation VLAN with restricted routing so that a moved endpoint can reach only the services needed for triage and reimaging, such as the EDR console and the forensic collection server. They write rules that define which endpoints may be moved, who authorizes the move and how the move is logged. A VLAN runbook records the steps to enter and leave the segment and the criteria for release. The step is done when the runbook is approved, a test endpoint has been moved and released, and the switch or firewall logs show both events.
Document manual approval and third-party instructions
The incident response lead names who may approve manual containment for each asset class and the backup approver for out-of-hours cases, then records those names in the incident response plan. For any ISP or MSSP that may contain on your behalf, the contract or a signed operating addendum states the trigger conditions, the permitted actions, the contact path, the time within which they must report back and the evidence they must return. Ask providers for their own containment logs as a condition of the agreement. The step is done when the approver list is current and each third party has signed terms that cover containment.
Run a controlled exercise and retain the records
The response team runs a planned exercise that triggers one automatic rule, one responder-chosen containment and one remediation VLAN move, using a test endpoint in a scoped group. Velociraptor or DFIR-IRIS can record the case, artifacts and actions taken, so each step has a timestamp and an owner. Reviewers compare the logs with the trigger matrix and note any gaps. The step is done when an exercise record shows that every action left a record, and every gap has a tracked fix. Confirm with your assessor how often they expect exercises to repeat and what they will sample.

Which containment records pass an assessment

An assessor testing RS.MI-01 Incident containment looks for records that show containment happened, who decided it, how fast it followed detection, and whether it was reviewed. The six cards below cover the artifacts that usually carry that proof, and each one needs a routine refresh so the evidence is current when the assessor asks.

Containment procedure with approved triggers

The written procedure defines which conditions allow automatic containment, which need a responder decision, and who approves each class of action. Assessors check that the version in force matches what responders actually did during the sampled incidents. Between audits, store each revision in one controlled folder, record the approver and date, and pull a quarterly copy into the evidence folder using the same file name pattern so the version history is easy to follow.

Alert-to-containment timelines

A case record that shows the time an alert was triaged, the time containment was requested, and the time it was confirmed gives an assessor a verifiable sequence. DFIR-IRIS keeps each case as one record with an investigation timeline, so the sequence can be exported from the case itself rather than rebuilt from memory. Confirm that the timestamps come from the same clock source across SIEM, EDR and the case system before you rely on the gaps between them.

Automatic containment logs from security tools

Endpoint protection and network devices often contain threats without a human in the loop, and their logs are the proof of that action. Export the action, host, rule that fired and result for each automatic containment, then tie each entry to a case identifier. Confirm with each vendor which events are logged by default and how long those logs are kept in your environment, since retention is set locally and is easy to overlook.

Remediation VLAN change and access records

When a compromised endpoint is moved to a remediation VLAN, the change record should show who requested the move, the approval, the switch or firewall configuration applied, and the access list that limits what the host can reach. Assessors test whether the quarantine network stays isolated and whether it was reverted after review. Keep the configuration export and the change ticket together, and capture the access list version each time it is edited.

Third-party containment instructions and action logs

Where an ISP or MSSP contains activity for the organization, the instructions it received and the actions it reported back are both needed. The contract or runbook should name the contact, the authority to act, and the hours of coverage. Keep each instruction with the action log the provider returned, so the organization can show who authorized the containment and what the provider actually did. Ask providers to confirm log formats before the first incident.

Dated containment exercise report

An exercise shows that the procedure works before a real incident tests it. The report should state the scenario, the containment steps taken, the time each step finished, the gaps found, and the corrective actions with owners and due dates. Assessors look for a dated report and evidence that the gaps were closed in later exercises. Run the exercise on a schedule you can defend, store the report next to the procedure it tested, and confirm the expected frequency with your auditor.

What meeting RS.MI-01 containment costs

This table compares the main cost components of meeting RS.MI-01 containment, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a request for a written scope and quote, since no fixed figures are given here.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring (subscriptions), one-time (setup)	Number of endpoints, EDR and SOAR licensing tiers, and whether containment actions need a commercial add-on	Compare commercial licensing with self-hosted open-source options such as Shuffle and osquery, which carry no license fee but still need hosting and support
Engineering time for containment rules and the remediation VLAN	One-time (build), recurring (changes)	Number of containment playbooks, switch and firewall vendors, and how many network segments the remediation VLAN must reach	Start with a small set of high-impact containment actions, document them, and reuse the same VLAN design across sites
Responder time on runbooks and exercises	Recurring	Number of containment scenarios, staff turnover, and how often tabletop or live exercises are run	Keep runbooks short and tie each exercise to one containment decision, then record lessons learned for the next cycle
Evidence upkeep	Recurring	Volume of containment logs, case records and screenshots kept per incident, plus how long retention must last	Use case tools that keep one record per incident with an audit trail, so evidence is captured during the response instead of rebuilt later
External testing or review of containment design	One-time (initial), recurring (periodic)	Complexity of network design, how many automated containment paths exist, and whether tests cover containment and not only detection	Scope the review to the containment paths that can affect production, and agree the test scope in writing before work begins
Third-party contract work (ISP or MSSP containment)	Recurring (service fees), one-time (contract setup)	Service levels for containment actions, the number of contracted sites, and the responsibilities split in the contract	Confirm in writing which containment actions the provider performs, how quickly, and what the organization must still do itself
Auditor sampling	Recurring (per assessment cycle)	Number of incidents sampled, the depth of evidence requested, and the auditor's fee structure	Prepare a clear evidence index for containment records before the audit, and confirm the auditor's sample approach early

Which open-source tools produce containment evidence

Containment under RS.MI-01 is only as credible as the record that shows it happened. The four tools below each cover a different part of that record: the case, the host state, the fleet-wide collection and the automated handoffs between systems.

DFIR-IRIS case management

DFIR-IRIS (LGPL-3.0-or-later) keeps each incident as one case holding assets, IOCs, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases and builds a consolidated timeline, so a reviewer can see when each containment step was recorded. Check whether your team records containment actions as case tasks, and confirm which containment actions, if any, the platform triggers itself in your environment. The case timeline and audit trail are the evidence an assessor will ask for first.

osquery host state checks

osquery (Apache-2.0 OR GPL-2.0-only) exposes running processes, open network connections, loaded kernel modules and file hashes as SQL tables. Its osqueryd daemon schedules these queries across a fleet, so responders can confirm that a suspicious process has stopped or that a host no longer holds outbound connections. Confirm which of these tables your endpoint platforms support, and whether query results are retained long enough to serve as containment evidence. Record the query, the time and the host in the case.

Velociraptor fleet collection

Velociraptor (AGPL-3.0-only) collects forensic artifacts defined in VQL from endpoints. Its hunts run one or more artifacts across a group of systems, and offline machines collect when they reconnect, which matters for hosts moved to a remediation VLAN or taken off the network. Use hunts to show that every affected system was reached, and keep a notebook per hunt as the record of what was found. Confirm that your network design lets the Velociraptor server reach quarantined hosts and what containment it can apply itself.

Shuffle containment workflows

Shuffle (AGPL-3.0-only) runs event-driven workflows started by a webhook, a schedule or a manual run. App nodes connect a SIEM, a ticketing system and a firewall without custom code, so a detection can open a ticket and request isolation with a logged trail. Review each workflow step as a control: who approves it, what it changes and where its output is stored. Confirm that the firewall and EDR integrations you need exist in your version and that they can block as well as alert.

Who owns containment, who builds it and who judges it

Your organization owns RS.MI-01 in full. Containment is a decision about business operations as well as security, so the people who approve isolating a server or cutting a network path must be employees with the authority to accept that disruption. An implementation partner can draft the policy and runbooks, but the organization adopts them, assigns the roles and keeps the approval records that an assessor will sample.

Containment policy: Own the written policy that defines what counts as containment, who may trigger it and which systems need prior approval before isolation.
Manual action approval: Name the approvers for manual containment steps, such as disabling an account or blocking an address, and record who approved each step and when.
Responder roles: Assign incident handlers, a incident commander and a deputy, and confirm each person has the access needed to act without waiting for a vendor.
Third-party containment terms: If an ISP or MSSP contains incidents for you, own the contract terms that say what they may do alone and what needs your approval first.
Exercises and reviews: Schedule and sponsor tabletop exercises and post-incident reviews, and track the improvements they produce.

Before engaging anyone, confirm that each role has a named person, a backup and documented authority.

Where containment programs usually fall short

Most containment programs have the tools and the people but lack the records that prove containment happened, was authorized and worked. The gaps below are the ones an assessor for RS.MI-01 Incident containment most often asks about, paired with the fix that closes each one.

Triggers defined only in email

Containment criteria often live in a thread from a past incident, so responders decide case by case. Assessors ask for a written containment matrix that maps alert types and severities to permitted actions, such as isolating a host, disabling an account or blocking a domain, with the role allowed to approve each one. Fix it by publishing the matrix in the incident response plan, version-controlled and reviewed on a set schedule, and by linking each rule to the detection that fires it.

Actions taken without timestamps

Containment may happen quickly, but if the isolation or account lock is not logged with a time, actor and target, the organization cannot show when containment began relative to detection. Assessors check whether each containment action appears in a case record with its time and the system that executed it. Fix it by routing EDR, SIEM and firewall actions into the case management record so that every step carries a timestamp and an owner.

Remediation VLAN never tested

Many teams build a quarantine network segment during a project and never move a live endpoint into it. When an incident arrives, the VLAN may not route to the tools responders need, or it may leak traffic to production. Assessors ask for evidence of a test, such as a dated change record showing a test host moved, kept isolated and released. Fix it with a scheduled test that confirms the endpoint loses production access while forensic collection still works.

Providers without written authority

An ISP or MSSP may block traffic or disable a service on the organization's behalf, but if the contract does not state what the provider may do, how fast it must act and who it must call, the containment is hard to defend. Assessors look for the agreement, the escalation contacts and the actions the provider is authorized to take alone. Fix it by writing those authorities into the service schedule and testing the call path with a tabletop exercise.

Manual decisions made in chat

When responders agree to isolate a server over a chat channel, the decision and its rationale often disappear once the channel scrolls. Assessors need to see who authorized each manual containment, what evidence supported it and when it was executed. Fix it by requiring a case entry for each manual decision, recording the approver and reason, and exporting the channel transcript into the case as supporting evidence.

No past incident samples kept

Organizations often clean up closed tickets and lose the proof that containment worked in practice. Assessors commonly ask for a sample of recent incidents with their containment records, so a program with no retained cases cannot demonstrate operation. Fix it by setting a retention period for incident records that the legal team approves, and by keeping a sample pack of closed cases ready for review.

How much work does RS.MI-01 containment take

How much effort does meeting RS.MI-01 containment take?

The effort depends mainly on how many containment paths your organization already has and how well they are documented and tested. RS.MI-01 asks that incidents are contained, and NIST's Implementation Examples describe four ways this happens: automatic containment by security tools, manual containment by responders, containment by a third party such as an ISP or MSSP, and moving compromised endpoints to a remediation VLAN. Each path you must cover adds work. Expect the most effort where containment is undocumented, where endpoints cannot be isolated quickly, or where no one has tested the steps. Ask any provider to break its quote down by containment path so you can see which parts are new work and which parts only need review.

Can our own team meet RS.MI-01 without outside help?

Often yes, if you have engineers who run your security tooling, a written incident response plan and someone who owns network segmentation. NIST does not offer certifications, and no one outside your organization is required to implement RS.MI-01. The practical question is capacity and skill. Your team must configure containment actions, keep a remediation VLAN ready, write runbooks for responders and test them. Outside help is most useful when the team lacks time, has not tested containment in a live exercise, or needs an independent view of gaps before an assessment. An implementation partner can prepare systems and evidence, but your organization still owns the control.

What does RS.MI-01 need from our own staff?

Your staff must make and own the containment decisions, even when tools act automatically. Security engineers need to define which detections trigger automatic containment and which require a responder's approval. Network and endpoint administrators need to maintain the isolation controls, the remediation VLAN and the procedures for returning endpoints to service. Incident responders need clear authority to act, a current contact list and a way to record their actions. Managers should confirm who may authorize containment that affects production systems. Plan for these roles to be named in writing before any assessment begins.

How long does RS.MI-01 containment work take?

The duration depends on the written scope, the tooling you already run and the state of your incident response plan. No duration figure is supplied for this work, so treat any timeline you receive as an estimate that must be confirmed. Shorter efforts usually involve existing tools that only need configuration and testing. Longer efforts involve building isolation capability from scratch, integrating several platforms or running exercises across many business units. Ask providers to state the phases, the deliverables for each phase, the dependencies on your staff and the assumptions behind the schedule before work starts.

Can an MSSP handle containment for us, and what should the contract say?

An MSSP can contain incidents on your behalf, which is one of the implementation paths NIST describes for RS.MI-01. Responsibility does not transfer with the work, though. Your contract should state which containment actions the provider may take without asking you, which require your approval, the response times it commits to, how it notifies you, what access it holds to your endpoints and networks, and how it documents each action. It should also name the evidence you will receive, such as containment tickets and timestamps. Confirm these terms with the provider and your legal team, since no standard contract language is supplied here.

What does the assessor need compared with what the partner prepares?

The assessor needs independent evidence that containment works, and only an independent auditor, assessor or certification body can issue an assessment report or certificate. Typically they examine your containment procedures, tool configurations, past incident records and results of exercises, and they may sample incidents to check actions were taken and recorded. An implementation partner such as DeployOpen prepares the systems, documentation and evidence that support this review. It does not issue reports or certifications. Ask your assessor early which evidence they will accept and in what form, so the partner builds the right records.

How DeployOpen works on this

DeployOpen plans and builds the self-hosted tooling and written procedures that let your team contain incidents in your own environment, and prepares the evidence an assessor will ask for. Your organization keeps ownership of its containment decisions, and an independent auditor issues any report or certificate.

How we scope

Engagements are fixed-scope, with the containment tools, environments and responder roles agreed in writing before work starts.
The written scope names which containment paths apply: automatic tools, responder actions, third-party containment and remediation VLAN moves.
Scope also states which parts remain with your team, such as containment authority, and which parts an ISP or MSSP performs.

How we build

We deploy self-hosted case management, such as DFIR-IRIS, to hold containment actions, assets and timelines in one audit-trailed record.
We configure endpoint querying with osquery and collection with Velociraptor so responders can scope affected hosts before isolating them.
We document containment runbooks and test that a compromised endpoint can be moved to a remediation VLAN as the procedure describes.

How we hand over

Handover includes configuration records, runbooks, test results and a list of the containment actions each tool performs automatically.
We document which containment steps are logged, who approves them and where each log is kept for your assessor.
Your staff are walked through the runbooks so responders can run containment without the implementation team present.

How we support

Ongoing support, upgrades and continuous testing of containment tooling are available as a retainer.
Retainers can cover periodic re-testing of the remediation VLAN path and review of automation workflows built in Shuffle.
Ask us to confirm the support terms and response expectations in the written quote before you commit.