03.06.05: Incident Response Plan

To meet the 03.06.05: incident response plan requirement, you need a written, approved incident response plan that fits your CUI environment, assigns roles and escalation paths, and is exercised and updated based on lessons learned. Operationalize it by defining incident criteria, communications and reporting workflows, evidence handling, and retaining proof the plan is current and used in practice (NIST SP 800-171 Rev. 3).

Key takeaways:

• A plan is not a policy; auditors expect an actionable runbook tied to your CUI systems and real responders (NIST SP 800-171 Rev. 3).
• “Evidence of use” matters: exercises, incident tickets, after-action items, and revisions prove the plan operates (NIST SP 800-171 Rev. 3).
• Scope must include third parties and cloud/service providers that touch CUI, with clear notification duties and contact paths (NIST SP 800-171 Rev. 3).

03.06.05 sits in the Incident Response family of NIST SP 800-171 Rev. 3 and is routinely treated as an assessment-readiness control: you either have an incident response plan that can be executed, or you don’t. A “plan” here is not a high-level statement that you will respond to incidents. It is a document your team can follow under pressure, aligned to the reality of your CUI architecture, your outsourced stack, and your contractual reporting duties.

For most federal contractors, the fastest path is to produce a plan that is (1) scoped to the CUI boundary, (2) role-based, (3) integrated with IT/SecOps tooling and ticketing, (4) explicit about communications and decision rights, and (5) backed by recurring tests and updates. If your environment relies on managed service providers, SaaS platforms, or cloud hosting, your plan must treat those third parties as part of response execution, not as an afterthought.

This page gives requirement-level implementation guidance you can assign to an owner and stand up quickly, with a focus on what assessors ask for and what evidence you need to retain (NIST SP 800-171 Rev. 3).

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.06.05 (Incident Response Plan).” (NIST SP 800-171 Rev. 3)

What the operator must do: Maintain an incident response plan that is appropriate for your organization and the nonfederal system(s) handling CUI, and be able to produce it during an assessment. The plan must be actionable (roles, steps, communications) and treated as a living operational document, updated as your environment changes and as you learn from tests or real incidents (NIST SP 800-171 Rev. 3).

Plain-English interpretation (what 03.06.05 really expects)

You need a written plan that tells your responders exactly how you detect, triage, contain, eradicate, recover from, and learn from incidents that could impact CUI. The plan must be tailored to your CUI boundary: the systems, identities, networks, endpoints, and third parties that store, process, or transmit CUI (NIST SP 800-171 Rev. 3).

Assessors typically look for three things:

1. Document quality: It reads like a runbook, not a brochure.
2. Governance: It’s approved, versioned, and reviewed on a defined cadence.
3. Operational reality: Tickets, exercises, and after-action items show people actually follow it (NIST SP 800-171 Rev. 3).

Who it applies to (entity and operational context)

Applies to:

• Federal contractors and subcontractors operating nonfederal systems handling CUI (NIST SP 800-171 Rev. 3).
• Any business unit operating within the CUI boundary, including IT, security, legal, HR (for insider scenarios), and communications, if they have incident roles (NIST SP 800-171 Rev. 3).

Operational contexts where 03.06.05 becomes urgent:

• Hybrid environments (on-prem plus cloud) where incident data and actions span multiple consoles.
• Heavy third-party dependency (MSP, MDR, SaaS, IaaS) where notification, access, and forensics require contractual clarity.
• Multiple CUI programs (different customers/program offices) requiring consistent response with program-specific reporting paths (NIST SP 800-171 Rev. 3).

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

1) Define scope and incident criteria for the CUI environment

• Identify the CUI boundary: systems, networks, users, and data flows in scope for NIST SP 800-171 Rev. 3.
• Define what counts as an “incident” for your organization (e.g., suspected CUI exposure, unauthorized access, malware on a CUI endpoint, lost device with CUI access tokens).
• Create severity levels that drive response intensity and escalation. Keep it simple enough that analysts can classify quickly (NIST SP 800-171 Rev. 3).

Output: “Scope” and “Incident classification” sections in the plan.

2) Assign roles, authority, and escalation paths

Your plan should name:

• Incident Commander / Response Lead (primary and backup)
• IT operations lead
• Security lead (or MSSP/MDR point of contact)
• Legal / contracts contact for reporting obligations
• Communications owner (internal + customer-facing)
• Business owners for CUI systems and data (NIST SP 800-171 Rev. 3)

Define decision rights:

• Who can declare an incident?
• Who can take disruptive actions (isolate endpoints, disable accounts, block IP ranges, suspend integrations)?
• Who approves external notifications? (NIST SP 800-171 Rev. 3)

Tip: Keep a one-page “call tree” appendix with phone/email/alternate channels, and store it where responders can access it during an outage.

3) Document the response lifecycle as an executable runbook

Include procedures for:

• Detection & intake: monitoring sources, user reporting, third-party notifications, triage steps.
• Triage: initial scoping questions (what system, what identity, what CUI touched, what timeframe).
• Containment: isolate host, revoke sessions, rotate keys, block egress, suspend accounts.
• Eradication: remove persistence, patch vulnerable services, reset credentials, rebuild as needed.
• Recovery: restore services, validate integrity, monitor for re-compromise.
• Post-incident: root cause analysis, lessons learned, control improvements, and plan updates (NIST SP 800-171 Rev. 3).

Make it concrete:

• Name your actual tools (SIEM, EDR, ticketing system).
• Specify where logs come from and who can access them.
• Include “if-then” decision points (e.g., “If CUI repository accessed by abnormal identity, revoke access tokens and isolate workstation.”).

4) Integrate third parties into the plan (contract + operations)

For each third party that can affect CUI (cloud hosting, managed security, IT support, key SaaS):

• Identify how they report incidents to you (email address, portal, phone).
• Define your required notification timelines and what data you need from them (log exports, indicators of compromise, affected tenants).
• Confirm you can obtain forensic artifacts (or at least sufficient event records) when needed (NIST SP 800-171 Rev. 3).

Practical control: Maintain a “Third-Party Incident Contacts” appendix and validate it during exercises.

5) Add communications, reporting, and evidence handling steps

Your plan should address:

• Internal notifications (executives, IT, security, system owners).
• External notifications (customers, contracting chain, third parties) as applicable to your contracts and program requirements (NIST SP 800-171 Rev. 3).
• Evidence preservation: what you collect (logs, disk images where feasible, alerts, chat transcripts), how you maintain integrity, and where it’s stored with access controls.

Exam hangup: Plans that ignore evidence handling often fail practical scrutiny because teams cannot reconstruct what happened.

6) Establish exercising, review, and update mechanics

Define:

• Exercise types (tabletop, technical simulation, third-party notification drill).
• Who attends, what constitutes success, and how gaps are tracked to closure.
• A review trigger list (new CUI system, major network change, new MSP, incident post-mortem) (NIST SP 800-171 Rev. 3).

This is where tools like Daydream can help: map 03.06.05 to the plan document, control owners, and a recurring evidence checklist so you stop chasing screenshots the week before an assessment (NIST SP 800-171 Rev. 3).

Required evidence and artifacts to retain

Maintain an “assessment packet” that includes:

• Incident Response Plan (versioned, dated), with approvals.
• Incident role assignments (RACI or on-call roster).
• Exercise materials: agendas, scenarios, attendance, results.
• After-action reports and remediation tickets showing closure.
• Samples of incident tickets (sanitized) showing triage, containment, and closure steps.
• Third-party incident contact list and any relevant contract excerpts or SLAs describing notification and cooperation expectations.
• Change log showing plan updates tied to lessons learned or environment changes (NIST SP 800-171 Rev. 3).

Common exam/audit questions and hangups

Expect questions like:

• “Show me the incident response plan and point to the CUI boundary it covers.” (NIST SP 800-171 Rev. 3)
• “Who can declare an incident? Who can shut down access to CUI systems?”
• “Prove you tested the plan. What changed as a result?”
• “How do you handle an incident that starts at a third party?”
• “Where do you store incident evidence and who can access it?”

Hangups that slow assessments:

• A plan that is generic and not tied to your actual systems/tools.
• No proof of execution (no tabletop, no tickets, no after-action tracking).
• Third-party responsibilities missing or “TBD.”

Frequent implementation mistakes (and how to avoid them)

1. Writing a plan that reads like policy. Fix: add step-by-step procedures, decision points, and tool-specific actions (NIST SP 800-171 Rev. 3).
2. No named alternates. Fix: assign backups for every critical role; incidents happen during PTO.
3. No mechanism to keep contact details current. Fix: tie the call tree review to onboarding/offboarding and third-party renewals.
4. Forgetting identity incidents. Fix: include compromised credentials, token theft, and account takeover playbooks.
5. Treating third parties as outside the plan. Fix: add notification routes, access methods, and evidence request templates (NIST SP 800-171 Rev. 3).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk shows up as (a) inability to contain CUI-related incidents quickly, (b) missed contractual reporting obligations, and (c) assessment findings due to missing “evidence of operation,” even if your technical security controls are strong (NIST SP 800-171 Rev. 3).

Practical 30/60/90-day execution plan

Use this as an operator’s rollout sequence; adjust based on your environment and staffing.

First 30 days (stand up a plan that’s executable)

• Inventory CUI boundary and list in-scope systems and third parties (NIST SP 800-171 Rev. 3).
• Draft incident classification and declare/escalation criteria.
• Assign roles (primary/backup) and publish the call tree.
• Write the core runbook sections: intake, triage, containment, eradication, recovery, evidence handling.

Days 31–60 (prove it works in your environment)

• Run a tabletop exercise using a scenario tied to CUI systems (NIST SP 800-171 Rev. 3).
• Validate third-party notification paths during the exercise.
• Create after-action report and open remediation tickets for gaps.
• Update the plan based on what failed (missing access, unclear authority, tooling gaps).

Days 61–90 (make it durable and assessment-ready)

• Add at least one technical drill (e.g., EDR isolate-host workflow, identity lockout procedure) appropriate to your tooling.
• Build an evidence binder (plan, approvals, tests, tickets, updates) and assign an owner to maintain it (NIST SP 800-171 Rev. 3).
• Implement recurring reminders for plan review and contact verification.
• If you use Daydream, map 03.06.05 to your plan, owners, and recurring evidence tasks so your packet stays current (NIST SP 800-171 Rev. 3).

Frequently Asked Questions

Do we need a separate incident response plan for CUI, or can we use our corporate IR plan?

You can use one plan if it explicitly covers the CUI boundary, names the responsible roles for CUI systems, and includes procedures that match how your CUI environment operates (NIST SP 800-171 Rev. 3).

What’s the minimum evidence an assessor will accept for 03.06.05?

Expect to provide the current plan plus proof it is used: exercise records, after-action items, and examples of incident tickets or alerts routed through the process (NIST SP 800-171 Rev. 3).

Our incident response is outsourced to an MDR/MSP. Are we still accountable?

Yes. You can outsource execution tasks, but you still need a plan that defines your decision rights, escalation, reporting, and how the third party coordinates with you during CUI-impacting incidents (NIST SP 800-171 Rev. 3).

How detailed should containment and eradication steps be?

Detailed enough that responders can act without improvising. Include the real tools and access paths your team uses, plus decision points for isolating systems or disabling accounts tied to CUI access (NIST SP 800-171 Rev. 3).

Where should the incident response plan live so it’s available during an outage?

Store it in a controlled repository with an offline or alternate-access option for responders. Document how responders access it if normal SSO or primary collaboration tools are unavailable (NIST SP 800-171 Rev. 3).

How do we incorporate third-party incidents that don’t directly hit our network but could expose CUI?

Treat third-party notifications as an intake channel, define who evaluates CUI impact, and document what evidence you require from the third party to support scoping and customer reporting (NIST SP 800-171 Rev. 3).