What 03.06.03 incident response testing asks for and why assessors check it
03.06.03 requires you to test the effectiveness of your incident response capability at a defined frequency. If you are the compliance lead or engineer who must show this is met, the work is not writing a plan and filing it. You need a set of tests that run on a schedule you chose, that exercise the capability itself, and that leave records an assessor can read. The requirement sits in the Rev. 3 incident response family alongside the handling, reporting, training and plan requirements, and NIST traces its source control to the incident response testing control (IR-3) in SP 800-53 Rev. 5. The risk behind the requirement is familiar: a plan that has never been exercised tends to fail at the first real incident, when contact lists are out of date, nobody knows who can approve a containment step, and logs needed for analysis were never retained. The frequency is an organization-defined parameter, so NIST does not supply a number. Your organization must assign it for the system in scope, and an assessor will check that the value is defined and that your testing follows it. Where a federal contract or agreement supplies the value, use that, and confirm it with the contracting officer before you set your own. Expect difficulty in three places: agreeing who owns the test, choosing a format that matches your environment (checklist review, walk-through, tabletop or simulation, as NIST describes), and keeping after-action findings tied to plan updates. For readers coming from CMMC or earlier guidance, this is the same requirement as Rev. 2 practice 3.6.3, which NIST classifies as a minor change in its change analysis. The substance carries over, so existing test records can often be reused if they show the frequency, the scenario and the follow-up actions. Confirm with your assessor which Revision governs your contract before you rewrite evidence.
Which systems, teams and exercises fall under incident response testing
Scope decides how much work 03.06.03 creates. Before any exercise is planned, the organization needs to settle which systems sit inside the incident response capability, who takes part, and how the defined testing frequency is applied across the environment.
CUI systems inside the capability
Start with the system security plan and the boundary around every system that stores, processes or transmits CUI. Each of those systems needs to be covered by the incident response capability, so exercises have to reach them. Systems that only touch the boundary, such as identity services or logging collectors, often matter as much as the enclave itself, because an exercise scenario frequently starts there. Confirm the inventory matches the current boundary diagram before scheduling anything.
Internal teams and roles
An exercise tests whether the people named in the incident response plan can act on it. Include security operations, system administrators, IT leadership, legal, human resources and the staff who notify the contracting agency. Record who is expected to attend and who is only consulted. Gaps usually appear in handoffs between these roles, so a tabletop that skips a role tells the assessor less than it appears to.
Managed SOC and third-party participants
A managed security provider, cloud provider or subcontractor may detect, contain or report incidents on the organization's behalf. Their responsibilities in the plan need to be exercised, not assumed. Confirm contact paths, escalation timing and access to logs during the test. Where a provider cannot take part, record that limit and how the organization covers it. The organization stays responsible for its own testing even when a provider runs the day-to-day monitoring.
Per-system or per-enclave frequency
The frequency in 03.06.03 is defined by the organization, so it must state whether it applies to each system or to the enclave as a whole. A single enclave-wide exercise is simpler to schedule but may leave individual systems with different recovery paths untested. A per-system schedule gives more coverage at higher effort. Document the choice in the plan and explain it in the assessment narrative, since the assessor will ask how it was set.
Exercise types and their evidence
NIST's discussion for this requirement names checklists, walk-through or tabletop exercises, and simulations. Each type produces different evidence: a checklist review shows the procedures were read, a walk-through shows steps were traced, and a simulation shows people acted under time pressure. Choose the mix that matches the systems in scope, and keep the scenario, attendees, findings and follow-up actions for each one.
Shared responsibility with the contracting agency
NIST says the federal agency holding the contract is responsible for how SP 800-171 is applied and for any compliance issues. Ask the agency whether it expects to take part in exercises, receive results, or set a specific testing frequency through its own ODP values. Some agencies assign values that override an organization's internal choice. Confirm these expectations in writing before the first exercise, because a value set after testing begins can force a repeat.
How an assessor tests incident response testing under SP 800-171A
An assessor testing 03.06.03 checks two things: that you defined how often you test the incident response capability, and that your tests happened at that frequency. SP 800-171A Rev. 3 gives the requirement one determination statement, plus a second statement that confirms the organization-defined parameter (ODP) has a value. Neither statement uses the test method. The assessor works through examine and interview only, which means the evidence is your documents and your people's accounts, supported by records of what was actually done. Because NIST does not assign the frequency, the value you write into your plan is the standard the assessor will measure you against, so set it deliberately and keep it realistic for the team you have.
On the examine side, expect the assessor to read your incident response policy and procedures, your contingency planning policy and procedures, your procedures for incident response testing and contingency plan testing, and the testing material itself, such as checklists, tabletop scenarios and simulation scripts. They will compare the frequency written in those documents with the ODP value you set. A mismatch, such as a plan that says quarterly while the procedure says annually, is a finding even when testing happened. Confirm that each document names the test type used (checklist, walk-through or tabletop exercise, or simulation), who runs it, and where results are recorded.
On the interview side, the assessor will ask personnel with incident response testing responsibilities and personnel with information security responsibilities how the tests are scheduled, who approves the scenarios, and what changed after the last exercise. Their answers should match the documents and the records. Before the assessment, confirm with your own staff which exercises were run, when, what gaps were found, and how those gaps were tracked to closure. Inconsistent answers are often where a finding starts, so brief the people who will be interviewed and collect the test reports, attendance lists and remediation tickets in one place.
What assessors request and where findings usually land
This table lists the items an assessor asks for under 03.06.03, what each item should show, and where findings most often appear. Read each row as a request you should be able to answer with a dated, named document or record before the assessment starts.
| Assessment area | Evidence the assessor requests | Where findings usually land |
|---|---|---|
| ODP definition | Documented test frequency for the incident response capability for each in-scope system, approved by the responsible official and traceable to the system security plan | Frequency is missing, differs between the plan and the system security plan, or is stated as 'as needed' with no defined interval |
| Testing procedure | Written procedure or plan naming the exercise types used (checklist, walk-through or tabletop, simulation), scenarios, participants and success criteria | Procedure exists only in a general policy, or does not say which exercise types are used for which systems |
| Exercise records | Dated exercise reports listing scenario, attendees, objectives, observed results and who signed off, for each test in the last cycle | Records are undated, cover only a subset of in-scope systems, or show attendance without recorded results |
| Post-exercise corrections | Action items from each exercise with owner, due date and closure evidence, such as updated runbooks, tickets or plan revisions | Gaps identified in an exercise have no tracked action, or actions remain open with no revised plan or closure record |
| Interview of testing staff | Walk-through by the people who plan and run tests explaining the frequency, the scenarios chosen and how results change the capability | Staff describe a test that the records do not show, or cannot name who owns the testing schedule |
| Linkage to incident response plan | Evidence that the test scenarios match the reportable incident types and roles in the current incident response plan | Exercises test an outdated plan version or a role that no longer exists |
How to set up incident response testing that produces evidence
This sequence turns the 03.06.03 requirement into a recurring, documented testing cycle, where each exercise leaves records an assessor can examine and where findings feed back into the incident response plan.
Set and document the test frequency
Start by deciding how often the incident response capability will be tested for each system in scope. 03.06.03 has one organization-defined parameter, the testing frequency, and NIST does not assign a value, so the organization must set it, and if a federal customer has specified one, that value applies. Record the frequency in the incident response policy or test procedure, name the owner who approves it, and state which systems it covers. The output is a written, approved frequency that an assessor can compare against the test records you produce later.
Map exercise types to each system
Decide which exercise type fits each system in scope. NIST's discussion of the requirement names checklists, walk-through or tabletop exercises, and simulations. Checklist reviews suit low-complexity procedure checks, tabletop or walk-through sessions suit decision-making and communication across roles, and simulations suit technical response in a realistic environment. Record the chosen type and reason for each system in a test matrix. The output is a matrix showing that every in-scope system has an assigned exercise type and a test schedule that matches the frequency from the previous step.
Write scenarios from the incident response plan
Build each test scenario from the incident response plan so the exercise checks the plan as written. Use the plan's reportable incident definitions, roles, escalation paths and information-sharing steps as the basis, and describe a realistic, hypothetical event for each exercise. Include the expected actions, the people who should act and the decision points. Have the scenario reviewed by the system owner and the incident response lead before the test date. The output is a dated scenario document with expected outcomes that serves as the test script.
Run the exercise and record results
Run each exercise according to its scenario and capture what actually happened. Assign a facilitator to track timing, decisions, communication and gaps, and a scribe to record attendance, participating roles and any deviations from the plan. For simulations, keep the technical outputs such as logs, ticket records and case entries generated during the exercise. Store the record with the scenario so the test can be examined later. The output is a completed test record that shows who took part, what was tested, and what the team did.
Log findings and track corrections
Convert each gap observed during the exercise into a logged finding with an owner, a severity and a corrective action. Typical findings include unclear escalation contacts, missing playbook steps or tools that were unavailable. Track each correction to closure and record the date it was verified, either by a re-test of the affected step or by a documented review. Case management or ticketing tools can keep this trail, and the findings log should link back to the test record. The output is a findings register where every item shows an owner, a status and evidence of closure.
Feed results back into the plan
Review the findings with the incident response team and update the incident response plan, procedures, contact lists and training content where the exercise showed they were unclear or wrong. Record each plan change with its version, date and approver so the revision history explains why it changed. Confirm that the next test scenario reflects the updated plan. The output is a revised plan with a change log that links back to specific test findings, showing that testing improves the capability rather than only producing a report.
Keep the evidence set current
Store the frequency decision, test matrix, scenarios, test records, findings register and plan revisions together, and keep each version traceable. A wiki with version history or a document repository with access controls can hold this record, and the assessor should be able to see what changed, when and by whom. Before an assessment, confirm with the assessor which evidence formats they accept. The output is a complete, dated evidence trail that an independent assessor can examine for 03.06.03.
Choosing between checklists, walk-throughs, tabletops and simulations
A checklist test compares the incident response plan and its procedures against a defined list of expected steps, roles, contacts and tools. The reviewer checks whether each item exists, is current and is reachable, for example whether the on-call roster names real people, whether the evidence-handling steps match the tooling in use, and whether the reporting contacts still work. It proves that the documented capability is complete on paper and reachable in practice, but it does not show that people can execute the steps under pressure.
- Effort: Low. A reviewer or security lead can work through a checklist in a single sitting, and the effort recurs only when the plan or the team changes.
- Evidence: A dated, signed checklist with each item marked, the reviewer's name and the corrective actions raised.
- Scope of proof: Document accuracy and contact validity, not team performance.
- Maturity fit: Useful early, when the plan is new and the main risk is missing or outdated content.
- Limit: A passed checklist should not be presented as a test of effectiveness on its own.
Before relying on checklists, confirm with your assessor whether they accept a checklist alone as evidence for the defined frequency, or whether they expect a higher-fidelity exercise in the same period.
A walk-through or tabletop exercise gathers the people who would respond and talks through a scenario step by step, without touching live systems. A facilitator presents an injected event, such as a suspected credential compromise on a CUI system, and participants state what they would do, who they would notify and which records they would preserve. The exercise tests decision-making, role clarity and the sequence of the plan, and it surfaces gaps such as unclear escalation authority or reporting deadlines that nobody owns.
- Effort: Moderate. Preparation includes writing a scenario, scheduling participants and agreeing the objectives, and the session itself usually takes a few hours.
- Evidence: The scenario, attendance list, facilitator notes, decisions recorded and an after-action list of improvements with owners.
- Scope of proof: Roles, decisions and plan logic, but not whether tools and access actually work.
- Maturity fit: A common next step once checklists are clean and roles are assigned.
- Cost driver: Participant time from legal, communications and executive staff, which is often the largest hidden cost.
Ask your internal team or any outside facilitator to show the scenario and after-action record before the session, since those documents are what an assessor will request.
A simulation runs the response against a realistic but controlled event, so responders use the actual detection, case management and communication tools. The exercise can be a functional drill in a test environment or a controlled injection into a production-like system, with the scope and safety rules agreed beforehand. It shows whether alerts reach the right queue, whether evidence is captured with integrity records and whether the team meets its own internal timings, which tabletop discussions cannot demonstrate.
- Effort: Higher. Teams need a test environment or controlled inject, rules of engagement, a control group or observer and time to debrief.
- Evidence: Timestamped logs from detection and case tools, the exercise plan with approvals, observer notes and a findings report.
- Scope of proof: Tool readiness, handoffs and response timing under realistic conditions.
- Maturity fit: Suited to organizations that already run tabletops well and have stable monitoring and ticketing.
- Risk: A poorly bounded simulation can disrupt CUI systems, so confirm approvals and rollback steps in writing.
Before scheduling, confirm with your assessor whether they expect a simulation in the defined testing period, and whether your evidence will cover the tools that are in scope for the system.
Evidence that passes incident response testing and how to keep it current
An assessor testing 03.06.03 looks for proof that testing happened at the frequency the organization defined, that it exercised the real incident response capability, and that findings led to changes. The cards below cover the artifacts that carry that proof and the habits that keep them current between assessments.
Documented test frequency
The organization must define how often it tests the incident response capability, because 03.06.03 leaves that value to the organization. The assessor checks that the value is written down, that it is defined for the system in scope, and that it appears in the incident response policy or procedures. A frequency that exists only in someone's memory will fail the ODP check. Confirm the value with your assessor before the first exercise, and record who approved it and when.
Exercise plans and scenarios
Each test needs a written plan that states its type, which of the checklist, walk-through or tabletop, or simulation methods it uses, its objectives, and the scenario. Scenarios should reflect threats the system faces, such as ransomware on a CUI file server or a compromised administrator account. Keep the plan, the injects and the success criteria together, so an assessor can see what the team was expected to do before the exercise began.
Attendance and assigned roles
Examine records should show who took part and what role each person played in the response, including incident response leads, system owners, legal, communications and personnel with information security responsibilities. Interviews are part of the assessment, so the people named on attendance records should be able to explain their duties in their own words. Note absences and any role gaps, because a gap found in an exercise is a finding to track, not a reason to remove the name.
Exercise reports with timestamps
A post-exercise report records what was tested, what happened, when each decision was made and where the response slowed down. Timestamps should be specific enough to compare against the incident response plan's timelines, including the 72-hour DFARS reporting window if the contract applies it. Store the report in a system that keeps its history, so the record cannot be quietly edited after an assessment is scheduled.
Action items with owners and closure dates
Every finding from an exercise should become a tracked action with a named owner, a due date and a closure note that points to evidence, such as an updated runbook or a configured alert. Assessors often sample these items to see whether lessons were acted on. Open items older than the defined test frequency suggest the testing program is not feeding improvements. Review the tracker before each assessment and close or re-plan anything overdue.
Revised plan versions
When an exercise shows that the incident response plan or procedures are wrong, the revised version should be dated, approved and compared with the prior version. Version history shows the assessor that the plan changed in response to testing, rather than being written once for the audit. Keep superseded versions available so the team can show which version was in force during any given test.
Keeping test records in tools that show who changed what and when
For 03.06.03, the assessor will not accept a statement that testing happened. The assessor will ask for the exercise plan, the findings, the corrective actions and proof that none of these records were quietly edited after the fact. Test records need an audit trail that shows what changed, when and by whom. Without one, an assessor has no way to confirm that the findings in a tabletop report match the version that was reviewed and approved.
A case management tool can hold exercise findings as cases. DFIR-IRIS keeps each case as a single record of assets, indicators of compromise, tasks and evidence, with a full audit trail. A simulation run can be opened as a case, its injects and responses logged as tasks, and its findings attached as evidence. Confirm that the audit trail captures the changes your assessor will ask about, that exercise cases can be kept separate from live incidents in your reporting, and that your retention rules for exercise records match the period your contract or assessment requires.
Plans, checklists and procedures are better kept in a versioned wiki. XWiki keeps every change to a page under version control, so you can compare any two versions and roll back to an earlier one. BookStack assigns abilities through roles and lets you override permissions per role at the shelf, book, chapter or page level, which helps limit who can edit the testing procedure itself. Both are supporting tools. Your organization must confirm that either one fits its environment, its data handling rules and its evidence requirements, and that the assessor accepts exported version history as evidence.
What meeting 03.06.03 costs in money and effort
This table lists the cost components of testing incident response for 03.06.03, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no price is stated here and the figures depend on your system scope and exercise schedule.
| Cost component | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Tooling for exercise records | One-time setup, then recurring licenses or hosting | Use of existing ticketing or case tools versus a new platform; number of systems in scope; whether open-source tools are self-hosted in your environment | Itemized list of software, hosting and support charges, and which items you already own |
| Engineering time to design scenarios | One-time per scenario set, with periodic updates | Number of system types in the boundary; how often architecture changes; reuse of scenarios across exercises | Named deliverables such as scenario scripts, injects and success criteria, with a revision allowance |
| Staff time to run exercises | Recurring at each exercise | Number of participants by role; length of checklist reviews, walk-throughs, tabletop sessions and simulations; frequency you set for the ODP | Participant hours by role for each exercise type, and what facilitation time is included |
| Evidence upkeep | Recurring after each exercise | Volume of after-action notes, lessons learned and corrective action tracking; how well the incident response plan is kept under version control | Who maintains evidence, in which system, and how exercise records are retained and produced for an assessor |
| External facilitation or review | Optional, usually per engagement or retainer | Whether your staff can run exercises without outside facilitation; need for an independent reviewer of scenarios; retainer scope for continuous testing | Fixed-scope deliverables with dates, or retainer terms with included hours and what is excluded |
| Assessor time | Recurring at each assessment, paid to the independent assessor | Depth of examination of policies, procedures and exercise records; interview count; number of systems in the assessment scope | Assessor's scope statement, the evidence list they will request, and the basis for their fee |
| Internal management time | Recurring, usually unbudgeted | Approvals for the ODP frequency; coordination with legal, communications and senior management during exercises | Named owner for the exercise program and an agreed review cadence for the ODP value |
Who owns, who prepares and who assesses incident response testing
The organization that handles CUI owns requirement 03.06.03 and remains accountable for it, whatever help it buys. Its job is to decide how often the incident response capability is tested, to run or sponsor the exercises, and to act on what they reveal. The defined frequency is an organization-defined parameter, so NIST does not supply the value. The contracting federal agency may specify it, and if it does not, the organization must assign it. The owner also keeps the records that show the test happened.
- Frequency decision: Set and document the testing interval, and record who approved it and why it fits the system's risk.
- Ownership of results: Assign named staff to track findings from each exercise to closure.
- Plan updates: Feed lessons learned back into the incident response plan and procedures.
- Evidence custody: Keep exercise scripts, attendance, outcomes and corrective actions in a system the organization controls.
- Federal agency coordination: Confirm with the contracting agency whether it sets the frequency value.
Confirm that a named executive can explain the chosen frequency and show the last completed exercise without outside help.
An implementation partner helps prepare the systems, procedures and evidence that the organization will later present. For testing, that usually means designing scenarios, drafting checklists and tabletop scripts, building simulation environments, and organizing evidence folders that match what an assessor will examine. Facilitation and simulation design are common outsourced tasks, since they demand specialist skill and time. The partner works for the organization and does not decide whether the requirement is met, and it should not sign off its own work as proof of conformance.
- Scenario design: Draft realistic incident scenarios tied to the organization's CUI systems and incident response plan.
- Facilitation support: Run or co-run walk-through and tabletop sessions, with the organization's staff in the decision roles.
- Simulation build: Prepare test environments or simulated events where the organization wants hands-on exercises.
- Evidence preparation: Structure exercise reports, timelines and action logs so an assessor can trace each step.
- Gap reporting: Flag where exercises have not covered the defined frequency or the incident response roles.
Check the written scope to see which of these tasks are included, who holds the exercise records after delivery, and whether the partner's staff will be named in the evidence.
Only an independent assessor judges conformance. Under SP 800-171A Rev. 3, the assessment for 03.06.03 uses examine and interview methods, and it checks that the testing frequency is defined and that testing happens at that frequency. The assessor examines incident response policy and procedures, testing procedures and testing material, and interviews the people who run testing and hold information security responsibilities. The assessor is the party that gives the verdict, and an assessment for a federal contract may also involve the agency itself.
- Independence: The assessor must not have designed the scenarios or run the exercises it later judges.
- Examine objects: Expect to produce the incident response policy, procedures, exercise checklists and test records.
- Interview objects: Expect the staff who plan and run tests to explain the process in their own words.
- Frequency check: The assessor compares the defined frequency with the dates of completed exercises.
- Scope boundary: Ask whether the assessor will accept partner-prepared evidence and how it will verify it.
Before engaging anyone, confirm which assessor the contract or program recognizes, because the assessment body that counts for your obligation is set by the contract, not by the consultant.
Common gaps that fail incident response testing and how to close them
Most organizations that fail 03.06.03 do not lack an incident response plan. They lack a defined testing frequency, a record that tests happened, and a trail from findings to fixes. The cards below cover the gaps assessors most often find and the action that closes each one.
No defined testing frequency
03.06.03 requires testing at a frequency the organization defines, and that value is an organization-defined parameter. If no frequency is written down, the requirement cannot be shown as met, because the examine method checks that the value is defined. Set the frequency in the incident response policy or procedures, approve it with the system owner, and name the person accountable for scheduling each exercise. Confirm the value matches the frequency stated in the system security plan.
Tests that never happen
A frequency on paper is not evidence. Assessors ask for the dates of past exercises and the personnel who ran them, and a gap between the defined frequency and the calendar will stand out. Keep a testing schedule tied to a ticket or calendar entry, and treat a missed exercise as a tracked deviation rather than a silent slip. Where a test is delayed, record the reason and the rescheduled date.
Exercises with no written findings
A tabletop or simulation that leaves no record cannot show effectiveness. For each exercise, keep the scenario, the checklist or walk-through script used, the attendees, and a list of what worked and what did not. Notes taken in a meeting and discarded afterward are the most common reason an examine objective comes back empty. Store the write-up with the test material so an assessor can trace one exercise from start to finish.
Findings never closed
Testing finds gaps in contact lists, escalation paths, logging access and decision authority. If those findings stay open, the next exercise repeats the same failure, and the organization cannot show that the capability improved. Log each finding as a task with an owner and a due date, and review open items at the next exercise. Ticketing or case tools that keep tasks and their audit trail in one place make this easier to demonstrate.
Plan not updated after tests
When an exercise shows that a role has changed, a system was added, or an escalation step is wrong, the incident response plan has to change with it. Assessors compare test findings against the plan version in force at the time, so an unchanged plan after a failed exercise signals that testing does not feed back into the program. Record the plan revision, the date it changed, and which finding prompted it. Version history in a wiki or document system can show that trail.
No evidence for the ODP
Assessors check that the testing frequency is defined and that the organization follows it, so the frequency needs supporting records. Keep a register that lists each exercise, its date, its type (checklist, walk-through, tabletop or simulation), and the systems covered. Confirm with your assessor which artifacts they expect to see for the frequency, and retain them for the period they will sample.
How much effort, time and outside help does incident response testing need?
Can we run incident response tests ourselves, or do we need outside help?
Yes, most organizations can run checklist reviews, walk-throughs and tabletop exercises with their own staff, and SP 800-171 does not require an outside party to run them. The organization owns the capability and the evidence. Outside help is most useful when internal staff cannot play neutral roles, when the scenarios need technical depth such as a realistic simulation of a compromised system, or when no one has run a documented exercise before. Whatever the source, the test records must show what was tested, who took part, what failed and how the plan was updated.
What effort drives the cost of incident response testing?
Effort rises with the number of systems in scope, the number of teams that must take part (legal, communications, IT, executive leadership, and any external providers), the complexity of the scenarios, and how much technical simulation is involved. A tabletop for one application is a different job from a simulation across an enclave that holds CUI. Recurring cost comes from running the test at the frequency the organization sets, fixing the gaps each exercise finds, and rewriting the plan and training material afterward. Ask any provider to break its quote into design, facilitation, technical simulation, reporting and retest effort.
How does Rev. 2 requirement 3.6.3 relate to Rev. 3 requirement 03.06.03?
NIST's Rev. 2 to Rev. 3 change analysis traces Rev. 3 requirement 03.06.03 to Rev. 2 requirement 3.6.3 and classifies the change as minor. The core intent is the same: test the incident response capability at a defined frequency. CMMC Level 2 still uses the Rev. 2 requirements, so the same practice appears there as IR.L2-3.6.3, worth 1 point under the 32 CFR 170.24 scoring methodology. Organizations working toward a CMMC assessment should map their evidence to the Rev. 2 wording, while Rev. 3 contracts should use the Rev. 3 determination statements. Confirm which version your contract names before you plan the work.
Does the contract have to set how often we test incident response?
The requirement itself does not fix a number of tests per year. Rev. 3 requires testing at an organization-defined frequency, which NIST treats as an organization-defined parameter. If a federal agency does not specify the value, the nonfederal organization must assign it to complete the requirement. Check the contract, the agency's requirements and any CUI agreement first. Where the contract is silent, document a frequency with a reason, approve it through your governance process, and make sure the assessor can see that the frequency was followed.
What should we ask a partner to include in a fixed-scope quote?
A fixed-scope quote should state the systems and teams in scope, the exercise types (checklist review, walk-through, tabletop or simulation), the number of exercises and the frequency they support, and the deliverables. Ask who writes the scenarios, who facilitates, who records observations, and who owns the after-action report and plan updates. Confirm whether retesting after remediation is included, how evidence is delivered and stored, and what the partner does not do. Remember that a partner can prepare systems and evidence, but only the organization owns its controls and an independent assessor issues any assessment result.
What evidence will an assessor expect from our incident response tests?
Assessors look for a dated test record for each exercise, the scenario used, the participants, the objectives, the findings and the corrective actions, plus proof that the incident response plan and procedures were updated. SP 800-171A Rev. 3 asks assessors to examine incident response policy, procedures and testing material, and to interview the personnel who run tests and those with information security responsibilities. Keep the scenario, attendance, timeline and after-action items together so one folder answers the examine and interview steps.
Where can we store test records so they stay traceable over time?
Store exercise plans, scenarios, after-action reports and plan revisions in a system that keeps version history and shows who changed what and when. Wiki platforms such as XWiki keep every page change under version control and let you compare and roll back versions. For the case-side evidence created during a simulated incident, DFIR-IRIS keeps each case as one record with a full audit trail and an investigation timeline. Confirm that the platform you choose meets your retention and access rules before you rely on it for assessment evidence.
Authoritative sources for 03.06.03
Start with the requirement itself. The NIST SP 800-171 Rev. 3 text for 03.06.03 asks the organization to test the effectiveness of its incident response capability at a frequency the organization defines, and that frequency is an organization-defined parameter the nonfederal organization must set if the federal agency has not. Read the requirement alongside the *SP 800-171A Rev. 3* assessment procedure for the same number, which shows what an assessor will examine and whom they will interview. The assessment procedure for this requirement uses examine and interview methods only, so the evidence file you build should contain the incident response testing procedures, the test materials and records of past exercises, and a named owner who can speak to them. Confirm the defined frequency with your contracting agency before you write it into the system security plan.
If your organization is in the Defense Industrial Base, also read the eCFR text for the CMMC scoring methodology in 32 CFR 170.24. It shows how the Rev. 2 predecessor of this requirement, 3.6.3, is scored under CMMC Level 2. Check which revision your contract currently names before you plan around it, because the Rev. 2 and Rev. 3 wording differs and the DoD and FAR rules that select a revision have been changing. Ask your contracting officer which version of SP 800-171 applies, and whether any ODP values are to be supplied by the agency. Those answers decide whether your test frequency is a documented choice you defend or a value the agency has already set for you.
How DeployOpen prepares incident response testing evidence
DeployOpen helps organizations plan, build and document the testing side of their incident response capability for 03.06.03, inside their own infrastructure. The organization still owns its incident response plan, its exercises and its results, and an independent assessor decides whether the requirement is met.
How we scope
- Written scope defines which systems, teams and incident response procedures are covered by the testing program.
- Scope records the test frequency the organization has defined for the system, since NIST leaves that value to the organization.
- Scope lists which exercise types will be used, such as checklists, walk-through or tabletop exercises, and simulations.
How we build
- We prepare test checklists, exercise scenarios and simulation runbooks tied to the organization's own incident response procedures.
- We set up the tools that record exercise findings, actions and follow-up, such as case tracking that keeps an audit trail.
- We configure version-controlled documentation so exercise materials and revisions can be compared and traced over time.
How we hand over
- We deliver a test calendar, exercise reports and a record of corrective actions with named owners.
- We document the evidence an assessor will examine, including procedures, exercise materials and results, mapped to the 03.06.03 assessment objects.
- We train the named staff who will run future exercises so the program continues without outside help.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
- Support can cover running additional exercises and updating scenarios when systems or procedures change.
- Ask the assessor and your counsel which evidence they will accept for the defined test frequency before work begins.
