03.06.05 Incident response plan: requirements and evidence

What the 03.06.05 incident response plan requirement asks for

A contracting officer, prime contractor or assessor who asks for NIST SP 800-171 evidence under requirement 03.06.05 wants proof that a written incident response plan exists, is current and is protected. The requirement, new in Rev. 3, asks the organization to maintain a plan that gives a roadmap for its incident response capability, describes how that capability is structured and how it fits the organization, defines which events count as reportable incidents, addresses how incident information is shared, and assigns responsibilities. The plan must reach the people who need it, change when the organization learns from incidents or tests, and be kept from unauthorized disclosure, because an attacker who reads the plan learns how the response will unfold.

The risk behind the requirement is slow, uncoordinated response. When no one has written down who declares an incident, who talks to the contracting agency, or what counts as reportable, the first hours of an event go to debate rather than containment. Rev. 2 had no matching requirement, so organizations that already assess against Rev. 2 for DoD work should not expect an existing control ID to cover it. Confirm with your contracting officer which revision applies to your contract, because the revision determines whether this requirement is assessed at all.

The hard part is making the plan operational rather than decorative. A plan can exist as a document that names roles nobody holds, lists a reporting contact who has left, or was last reviewed before the most recent tabletop exercise. Assessors check the plan against interviews with incident response planning staff and information security staff, and against records of plan reviews and approvals. Before an assessment, confirm that each named role has a current holder, that the reporting paths match the contract's notification obligations, and that the lessons from your last test appear as dated revisions with an approver. The plan also has to be stored where access is controlled and version history is kept, so you can show what changed and when.

Which systems, teams and third parties the plan must cover

The incident response plan is only as wide as its scope statement. Four decisions set that scope: which systems fall inside it, which teams hold response roles, how third parties are covered, and where the plan boundary sits relative to the system security plan. Settle each one in writing before the plan is drafted, because every later step (distribution, updates, testing) depends on it.

Systems that store, process or transmit CUI

Start from the system security plan boundary and list every system that stores, processes or transmits CUI, including backups, logging platforms, collaboration tools and administrative workstations. The plan must name these systems or the classes they belong to, because 03.06.05 expects a roadmap for responding to incidents affecting them. Check whether the list matches the asset inventory your configuration management records actually show, and flag systems that appear in one list but not the other.

Systems that support CUI systems

Identity providers, directory services, DNS, patch servers and security tooling often sit outside the CUI enclave yet can be the path an attacker uses to reach it. Decide whether these supporting systems fall inside the plan's scope or are covered by a linked plan. Document the decision and the reason, so an assessor can see that the boundary was chosen deliberately rather than by omission.

Response roles across internal teams

Map each responsibility the plan assigns to a named role, such as incident commander, legal counsel, communications lead, system owner and the person who makes reporting decisions. Include teams outside security, such as facilities, human resources and executive leadership, if they have decisions to make during an incident. Confirm that each role has a named primary and alternate, since an assessor interviewing personnel with incident response planning responsibilities will test whether they know their part.

Third-party providers in the plan

Decide whether managed service providers, cloud hosts, outsourced security monitoring and incident response retainers are named in the plan, and what each must do and when. Write down which party notifies whom, how quickly, and who holds the authority to preserve evidence on a provider's platform. Obtain the contract terms that support these steps before the plan relies on them, because a plan that assumes a provider's cooperation without a contractual basis is hard to defend.

Reportable incident definitions by team

The plan defines which incidents are reportable, and each team that receives reports needs the same definition. Decide whether reporting thresholds differ for the prime contractor, subcontractors and the parties you exchange CUI with, and record how those thresholds reach the teams that must act on them. Test the definitions against two or three realistic scenarios drawn from your own environment, labeled as illustrative in the plan's test notes, so that responders apply the same threshold.

Aligning the plan with the SSP boundary

The system security plan describes the CUI boundary, and the incident response plan should point to the same systems, roles and interfaces. When the boundary changes, both documents need an update, so assign one owner to keep them aligned. Compare the two documents line by line before an assessment, checking that every system named in one appears in the other or is explicitly excluded with a reason.

How an assessor tests the incident response plan

This table shows how SP 800-171A Rev. 3 assesses 03.06.05 through the examine, interview and test methods, with the evidence an assessor requests and the findings that often come up for each. Read it as a checklist of what to have ready before an assessment, since the same plan must be shown in three different ways.

Assessment method	Objects the assessor reviews	Evidence to prepare	Common findings
Examine	Incident response policy, procedures addressing incident response planning, the incident response plan itself	Current signed policy, a planning procedure, the plan with version history and owner, distribution list	Plan exists but is undated, unowned or does not match the procedure it cites
Examine	Records of incident response plan reviews and approvals	Dated review records, approver names, change log showing updates after incidents or tests	No review record, or reviews show no update after a tabletop exercise or real incident
Interview	Personnel with incident response planning responsibilities	Plan owner can explain the plan structure, how it was built, and who maintains it	Owner cannot describe current version or where lessons from testing were recorded
Interview	Personnel with information security responsibilities	Staff can state what counts as a reportable incident and who receives information from the plan	Staff describe different reporting thresholds from the written definition
Test	The incident response plan and related processes	Walk-through showing a sample scenario traced through the plan, contact roster checks, access to the plan during an outage	Contacts in the plan are outdated, or the documented steps cannot be followed in practice
Test	Distribution and protection of the plan	Evidence that designated personnel hold the plan, access restrictions on the stored copy	Plan stored in a location that unauthorized staff can open, or copies are scattered without control
Determination statements	Ten statements for 03.06.05 in SP 800-171A Rev. 3	Map each statement to one document, one interviewee and one test record before the assessment	Gaps appear only when a statement has no evidence, so check each one before the assessor arrives

Writing and maintaining the plan in order

The sequence below turns the 03.06.05 requirement into a plan that is scoped, approved, protected and kept current. Each step produces a specific artifact that an assessor can examine, so the order matters: parameters come first, then structure, then the people who act on it.

Confirm the organization-defined parameters
Before drafting, confirm the organization-defined parameters that Rev. 3 leaves to the organization, starting with what counts as a reportable incident, the internal reporting timeline, and the authorities and information-sharing partners the plan must name. Ask the federal agency that holds the contract whether it has assigned any values, because NIST does not assign them and the nonfederal organization must do so if the agency does not. The output is a short parameter register signed by the owner of the incident response capability, so that every later step refers to the same values.
Draft the roadmap and structure
Write the plan's roadmap: describe how the incident response capability is organized, how it fits the wider organization, and how it connects to the incident-handling, reporting and testing processes that sit alongside it. Keep the structure readable for a responder who opens the plan during an incident, not only for an assessor. The output is a draft with a table of contents and a cross-reference to each related requirement, which lets an assessor trace the plan to its sibling requirements.
Define reportable incidents
Write the criteria that decide whether an event is a reportable incident, using the parameters from the first step and the categories that matter for your CUI and contracts. Define how an event is escalated from an alert to an incident and who makes that call. The output is a classification table with examples of each category, illustrative only, that a shift lead can apply without asking the plan's author. Review the table against the reporting duties in your contracts before you approve it.
Assign responsibilities by role
Name the role responsible for each part of the plan: incident commander, technical responders, legal and contracting contacts, communications, executive decision makers and the people who handle information sharing. Use role titles and a named deputy for each, and record how the roles interact with personnel who hold information security duties. The output is a responsibility matrix that the people in each role have acknowledged in writing, which is the evidence an interviewer will ask to see.
Approve and distribute the plan
Obtain formal approval from the accountable executive and record the approval date, version and approver in the document. Then distribute the plan to the designated personnel by a controlled method, and keep a distribution record that shows who received which version. The output is an approved version with an approval record and a distribution list that matches the responsibility matrix, so that every named role has a copy.
Protect the document
Restrict the plan to the personnel who need it and store it where unauthorized disclosure is controlled, while keeping an offline copy that responders can reach during an outage. Decide who can edit it and log changes. The plan describes your response capability, so treat it as sensitive, but do not make it so locked down that responders cannot find it during an incident. The output is an access rule and storage location documented in the plan itself, plus a check that the restricted copy can still be opened by the people named in the responsibility matrix.
Set update triggers and version control
Define the events that require a plan update: changes to systems or CUI handling, changes to personnel or contacts, changes to contract reporting duties, and lessons from incident handling or exercises. Keep every version under version control so that an assessor can see what changed, when and by whom. Document the review cycle the organization has chosen and the record each review produces. The output is a revision history and a trigger list that the owner checks after each change.
Feed lessons from testing and incidents back in
After each exercise or real incident, record what the plan got wrong or missed, assign the update, and close the item in the revision history. Link these records to the testing and handling requirements so an assessor can trace a lesson from the exercise report to the plan change. The output is a dated change record showing that lessons from implementation or testing reached the plan, which is the evidence that the plan is maintained rather than written once.

Filling in the organization-defined parameters for the plan

Rev. 3 leaves several values for the organization to fill in. These organization-defined parameters (ODPs) are blanks inside requirements, and the incident response plan carries some of them. NIST does not assign ODP values. If the federal agency that holds your contract or agreement does not specify them, the nonfederal organization must assign them to complete the requirement. Before you finalize the plan, ask the contracting agency in writing which values apply to 03.06.05 and to the requirements around it, and file the answer with the plan. Do not assume that a value you choose will be accepted until the agency confirms it.

The regulatory picture is still moving, so confirm which path governs your contract. A FAR overhaul proposed rule published 23 June 2026 would require contractors handling CUI to comply with SP 800-171 Rev. 3 using ODP values published by the DoW CIO. Comments closed 23 July 2026, and the rule was not final as of October 2026. Meanwhile, the DoW class deviation names Revision 2 explicitly. Ask the contracting officer which revision and which parameter values your contract uses, and record the answer, the date and the name of the person who gave it. If the answer changes later, you will have a traceable reason for updating the plan.

Once values are confirmed or assigned, write them into the plan itself rather than leaving them in a separate memo. For each parameter, record the value, its source (agency direction or your own assignment), the owner who maintains it and the date of the last review. Assessors will check that the plan is distributed, updated and protected as the requirement asks, and a parameter value that exists only in an email thread is hard to show. A versioned document repository makes this easier to evidence. Confirm with your assessor how they expect to see the value history and the approval record for each change.

Evidence that passes an 03.06.05 assessment

An assessor testing 03.06.05 checks that a written plan exists, that people know about it, and that it changes when the organization learns from incidents and tests. The cards below cover the artifacts that prove each of those points, and how to keep them current between assessments.

Approved plan with version history

The plan itself is the primary artifact. It should name the incident response capability it describes, define reportable incidents, cover information sharing and assign responsibilities. Keep a version history that shows each revision, its date, its author and the approver who signed off. Assessors compare the current version against the approval record, so a plan with no approval trail is hard to defend even if its content is good. Confirm the approval step is written into your document process before the next assessment.

Distribution records for designated personnel

The requirement expects the plan to reach the people who must act on it. Keep a list of designated personnel, the plan version each person received, and the date they acknowledged it. Interviews are part of the assessment, so assessors often ask staff with incident planning or security duties what the plan says and where they find it. Re-issue the distribution record whenever the plan changes, and remove departed staff from the list promptly.

Role assignments and responsibility matrix

Section 03.06.05 requires the plan to assign responsibilities. A current matrix should name a role or person for each incident response task, including declaring an incident, coordinating technical work, deciding on external reporting and communicating with leadership. Each assignment needs a named backup. Confirm that the matrix matches the access and on-call records, because an assessor will notice when a named owner no longer works in the role.

Records of plan reviews and approvals

The plan has to be reviewed and approved on a schedule that you define, and the review itself is evidence. Keep dated review records showing who reviewed the plan, what they checked, what changed and who approved the result. A review that finds no changes still needs a record. Ask your assessor early which review interval they consider defensible, and set that interval in the plan itself so the record can be measured against it.

Change log tied to test and incident lessons

The requirement asks that the plan be updated for changes and for lessons learned from implementation or testing. Assessors look for a link between a finding and a plan change. Record each lesson from an exercise or real incident, the plan section it affected and the revision that carried the fix. A change log that shows cause and effect is stronger than a list of edits with no reason attached. Coordinate this with the incident response testing and post-incident records so the trail is complete.

Access controls on the plan document

The plan describes how your organization responds to attacks, so it must be protected from unauthorized disclosure. Restrict edit rights to the plan owner and approvers, give read access to designated personnel, and log access to the repository. Role-based permissions in a wiki or document system let you set these rules at the page or book level. Confirm which accounts can view and edit the plan, and review that list on the same schedule as the plan itself.

What meeting 03.06.05 costs in money and effort

This table separates the cost components of writing and maintaining an incident response plan under 03.06.05, who is paid for each, and whether it is one-time or recurring. Use it to build a quote request, since no price is fixed here and the largest recurring cost is usually staff time tied to changes and tests.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Staff time to write and approve the plan	Internal incident response lead, security, legal, communications and business owners	One-time, then revisited	Number of business units, systems and external reporting obligations the plan must cover
Plan drafting support	Implementation partner or consultant, if engaged under a written fixed scope	One-time	Whether templates and an existing incident playbook already exist to start from
Document control tooling	Software licenses or hosting, or staff time if an open-source wiki is self-hosted	Licenses recur; self-hosted tools mainly carry hosting and admin time	Choice between commercial and self-hosted tools, and the number of editors and readers
Review and update effort	Plan owner and affected teams after organizational, system or personnel changes	Recurring	How often systems, contacts and reporting rules change, and how many lessons come from tests and real incidents
Testing-driven revisions	Incident response team and plan owner after exercises under 03.06.03	Recurring, tied to test frequency	Testing scope and frequency defined by the organization and the lessons each exercise produces
External review by a consultant	Independent consultant reviewing the plan against 03.06.05, if used	One-time or periodic, by written scope	Internal maturity, plan length and whether the reviewer also prepares evidence
Assessor time	Assessor performing examine, interview and test steps for 03.06.05	Per assessment cycle	Number of systems in scope, availability of plan records and approval history, and how quickly staff can answer interview questions
Evidence retention and version history	Plan owner, using document control records of changes and approvals	Recurring, lightweight if built into the review cycle	Whether version history and approval records are kept automatically or assembled by hand before each assessment

Open-source tools that hold the plan and its evidence

A plan only satisfies 03.06.05 if it exists, is distributed, is kept current and is protected, and each of those steps leaves records an assessor can examine. The three tools below cover the incident record, the plan document and the access rules around both. None of them satisfies the requirement on its own; the organization still owns the plan, its content and its approval.

Case records and lessons feed

DFIR-IRIS, licensed under LGPL-3.0-or-later, keeps each incident as one case with its assets, indicators of compromise, tasks and evidence, plus a full audit trail. Its consolidated timeline is the record you compare against the plan's reportable incident definitions and escalation steps after a real event or an exercise. Check that the case fields match the information sharing and reporting content your plan defines, so lessons from a case can be traced into a plan revision.

Version-controlled plan documents

XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control, recording what changed, when and by whom. Assessors reviewing the plan's update history under 03.06.05 can compare any two versions and see approvals tied to a revision. Confirm that your approval step is recorded in the page itself, because version history shows edits but does not prove that a named authority approved them.

Role-based access to the plan

BookStack, licensed under MIT, gives users abilities through assigned roles and lets you override permissions per role at the shelf, book, chapter or page level. You can keep the full plan readable to designated incident responders while restricting edit rights to the plan owner. Test that the restricted copy and any exported copies follow the same rules, since 03.06.05 also requires the plan to be protected from unauthorized disclosure.

Confirm tool fit with your assessor

Before you rely on any tool as evidence, ask your independent assessor which artifacts they expect to examine: the plan itself, records of plan reviews and approvals, and records of distribution to personnel with incident response planning responsibilities. Map each artifact to the tool that produces it, then confirm the export and retention settings with your own environment. A tool can store the record; the organization must still show that the plan was followed and updated.

Who owns the plan, who helps and who assesses it

Your organization owns the incident response plan. Its leadership must approve the plan, its named roles must be real people who can act during an incident, and its contents must reflect how your environment and contracts actually work. Assessors look for evidence that the plan was reviewed and approved by the right people, not just that a document exists. Under 03.06.05, the plan defines reportable incidents, covers information sharing and assigns responsibilities, and those decisions can only come from your organization.

Plan ownership: Name an accountable owner and an approver, and record both in the plan.
Reportable incident definitions: Decide what counts as reportable for your contracts, including any DFARS reporting duties if they apply.
Role assignments: Assign incident roles to named individuals or positions, with backups.
Information sharing: Decide who receives incident information internally and externally, and under what conditions.
Review records: Keep dated approvals and updates so the review history can be examined.

Before engaging anyone, confirm which decisions your leadership must sign off on and who has the authority to do so.

Where organizations fail 03.06.05 and how to close each gap

Most incident response plans exist on paper but fail the 03.06.05 test in practice: nobody can show who received them, when they were last changed, or whether they match contract reporting terms. The cards below name the gaps assessors most often find and give one fix for each, so the plan can be shown to work before an examiner asks.

Plan not distributed to named people

A plan stored on a shared drive that no one was told about does not meet the requirement to distribute it to designated personnel. Assessors interview the people who hold incident response planning and information security duties, and they check whether those people know where the current plan is and what it asks them to do. Fix: keep a named distribution list tied to roles, and record each acknowledgement with a date. Confirm that the list still matches the current org chart.

No record of plan reviews

Assessors look for records of incident response plan reviews and approvals, not only the plan itself. A plan with an undated version history cannot show that anyone with authority signed off on the current text. Without those records, an interview answer that the plan is reviewed regularly has nothing behind it. Fix: keep an approval log that records reviewer, approver, date and the version approved.

Reportable incident definitions that conflict with contracts

The plan must define which incidents are reportable, and that definition has to agree with what the organization's contracts and agreements require. A plan that sets a higher internal threshold than a customer contract, or that never mentions a contract's reporting window, will fail when an actual event falls between the two. Check the DFARS clause or other agreement that applies to your CUI and map each reporting duty to a named trigger in the plan. Fix: build a table from each contract reporting obligation to a plan trigger.

Plan not updated after tests or incidents

The requirement expects the plan to change when systems change and when lessons come out of testing or real incidents. Many organizations run a tabletop exercise, write findings in a separate report, and never amend the plan. An assessor who reads the exercise report and then the plan will see the gap immediately. Fix: give each test or incident a closing step that opens a tracked change to the plan, with an owner and a closure date. Confirm the link between your testing records and your plan history.

Unprotected copies of the plan

The plan describes how to respond to attacks, so an unrestricted copy can help an attacker or leak details of reporting paths. The requirement expects protection from unauthorized disclosure, which means access limits on every copy, including printed copies, exported PDFs and offline backups. Many teams forget the copies held by responders on personal devices or by outside providers. Fix: restrict the plan to named roles, control edits through version history, and inventory every copy. A wiki with per-page permissions and version history can help here, provided the access rules are configured and tested.

Questions buyers ask about the incident response plan requirement

What does it cost to write and maintain an incident response plan for NIST SP 800-171?

No supplied fact gives a price for this work, so the number depends on your environment and scope. Costs fall into two groups. One-time costs cover drafting the plan, mapping roles, defining reportable incidents, setting up information-sharing paths and running the first review. Recurring costs cover annual or event-driven updates, plan testing under 03.06.03, and training under 03.06.04. The main cost drivers are the number of systems that handle CUI, how many internal teams and external parties the plan touches, and whether legal or contract reporting obligations need counsel. When you request a quote, ask for the scope in writing, the deliverables (plan, role matrix, distribution record, update procedure), and whether ongoing review is included or sold as a retainer.

How long does it take to write an incident response plan that meets 03.06.05?

The timeline depends on how much of the plan already exists. If you have an incident response policy, an escalation path and a contact list, the work is mainly mapping them to the requirement and closing gaps. If you have none of these, drafting, stakeholder review and approval take longer, especially where legal, communications and executive sign-off are needed. No supplied fact gives a duration, so ask any provider for a phased schedule tied to a written scope rather than a fixed number of weeks. Plan the calendar around the assessment date, because the examine and interview steps in SP 800-171A Rev. 3 will look for approval records and evidence that the plan was reviewed.

Can our in-house team write and run this plan without outside help?

Yes, many organizations do this internally, provided the right people are involved. The requirement assigns responsibilities, so the people who own incident handling, information security, legal and senior management must agree on their roles. Internal teams often struggle with three things: defining reportable incidents consistently with contract and regulatory deadlines, protecting the plan from unauthorized disclosure, and producing dated evidence of distribution and updates. Confirm internally who will sign off, who keeps the version history, and how lessons from exercises feed back into the plan. An outside partner can prepare documentation and evidence, but the organization owns the plan and its controls, and only an independent assessor issues a compliance result.

What does our staff need to contribute to the incident response plan?

Your staff supply the facts the plan depends on. Expect requests for an accurate inventory of systems that hold CUI, current contact details for incident responders and executives, the contract and agency reporting obligations that set reporting clocks, and the names of any external parties you would share incident information with. Staff in information security and the teams that run the affected systems will review drafts and test the plan. Legal or contracts staff should confirm which external reporting duties apply. Keep a record of who reviewed and approved each version, because assessors examine that record.

Can a partner write the incident response plan for us?

A partner can draft the plan, build the role assignments and prepare the distribution and update records, as part of a fixed-scope engagement with deliverables agreed in writing before work starts. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports or certifications. The plan must also reflect your actual operations, so your own incident responders and leaders need to review, approve and adopt it. Ask any partner to show how the plan connects to incident handling (03.06.01), reporting (03.06.02), testing (03.06.03) and training (03.06.04), and confirm who holds ownership after handover.

Does NIST SP 800-171 Rev. 2 require the same incident response plan?

No. Rev. 2 has no matching requirement for 03.06.05. NIST's change analysis lists it as one of 19 requirements new in Rev. 3, and NIST maps no Rev. 2 requirement to it. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID for this control. However, DoD contracts currently name Rev. 2: DoW Class Deviation 2026-O0025, Revision 3 has contracting officers use a revised DFARS 252.204-7012 that cites SP 800-171 Revision 2, and a proposed FAR rule would require Rev. 3 with ODP values published by the DoW CIO. Confirm with your contracting officer which revision applies to your contract, and plan for 03.06.05 if Rev. 3 is named.

What evidence should we keep to show the incident response plan is in force?

Keep the plan itself, the incident response policy and procedures that address planning, records of approvals and reviews, and proof of distribution to designated personnel. Keep change history that shows updates after incidents, exercises and implementation changes. Tools such as XWiki keep version history with what changed, when and by whom, and BookStack assigns access through roles, which helps control who can read or edit the plan. Case tools such as DFIR-IRIS can hold incident records that show the plan was used. Confirm with your assessor which formats they accept before you set up the evidence store.

How DeployOpen prepares the plan and its evidence

DeployOpen plans, implements and documents the incident response plan inside your own infrastructure, so the plan you hand to assessors matches the systems your people actually use. Scope, build and handover are agreed in writing before work starts, and the organization owns the plan, its roles and its approvals.

How we scope

Confirm which systems hold CUI and which incident sources feed the response, such as SIEM, EDR and ticketing tools.
Agree in writing the reportable incident definitions, internal reporting timelines and external authorities the plan must name.
Identify the named roles and approvers the organization will assign, so responsibilities are settled before drafting begins.

How we build

Draft the plan structure, roadmap and incident response capability description to match the organization's documented procedures.
Configure the case management and documentation tools that will hold the plan, its versions and review records.
Set up access so only designated personnel can read and edit the plan, with restrictions on distribution outside the team.

How we hand over

Deliver the written plan, review and approval records, distribution list and change log as evidence for assessors.
Walk designated personnel through their responsibilities and where to find the current version of the plan.
Document the update process, including triggers from system changes and lessons learned from testing or real incidents.

How we support

Offer ongoing support and periodic plan reviews as a retainer, with updates recorded against the plan's version history.
Help prepare the evidence package for the independent assessor, which the organization commissions and which issues any report.
Confirm with the organization's contracting officer or sponsor which parameter values and reporting windows apply to its contracts.