03.11.04 Risk response: requirements and evidence

What NIST SP 800-171 03.11.04 risk response asks for and why it is hard

Your assessment or scan has produced findings, and the contract now requires action. Requirement 03.11.04 Risk response is the step that turns those results into decisions and fixes. It asks the organization to respond to findings from security assessments, monitoring and audits. It is new in Rev. 3, and NIST maps no Rev. 2 requirement to it, so the Rev. 2 requirement set that DoD contractors are assessed against under CMMC Level 2 has no matching ID. It sits in the 03.11 Risk assessment family, next to the risk assessment itself (03.11.01) and vulnerability monitoring and scanning (03.11.02), which feed it. The practical question is not whether you scan but whether every finding ends in a documented disposition that someone accountable approved.

The difficulty is that findings arrive from many places at once: vulnerability scanners, configuration checks, audit log reviews, penetration tests, internal audits and monitoring alerts, each with its own format, severity scale and owner. Without a single place to collect and deduplicate them, the same weakness appears under several names and gets fixed twice, or not at all. The requirement also depends on organization-defined parameters. NIST does not assign ODP values, so if the federal agency has not specified them, your organization must set them for the requirement to be complete. Confirm with the contracting agency which response expectations, timeframes and approval authorities apply, and write them into your system security plan before the first assessment cycle.

Assessors test 03.11.04 with three determination statements, examining the risk assessment policy, assessment reports and audit records, interviewing the people who run assessments and audits, and testing the processes and tools that support them. Prepare a findings register that links each item to its source report, its owner, its decision (remediate, accept with a documented approver, or transfer), its due date and its closure evidence. Ask any tooling vendor or implementation partner to show how that register is produced from your existing scanners and audit sources, and treat any plan that depends on manual spreadsheets as a risk to plan for.

Which findings sources and systems fall under 03.11.04

03.11.04 applies wherever findings about CUI systems originate and wherever they must be acted on. The cards below cover the finding sources, the systems in scope and the third parties whose results reach the organization, along with the scoping decisions that change the work.

Security assessment results

Results from internal self-assessments, the assessments required under the 03.12 family and any third-party assessor reports are the first input to risk response. Each finding needs a recorded decision, such as remediate, accept with justification or transfer, and an owner. Check that the assessment reports you produce are the same documents you use to track findings, because SP 800-171A Rev. 3 examines assessment reports as evidence for this requirement. Confirm with your assessor which report formats they expect to receive.

Continuous monitoring and audit logs

Alerts from monitoring tools and events in system audit records are findings when they show a control is failing or a risk has changed. Work out which alerts become tracked findings and which are closed as routine, and record that rule in writing. Assessors interview staff with auditing responsibilities, so the people reviewing logs must know how a log entry becomes a risk response item. Logging scope is defined under 03.03, so confirm which log sources feed this process.

Vulnerability scan output

Scanner results are a major source of findings, but 03.11.04 covers the response to them, while the monitoring, scanning and remediation timing sit under 03.11.02. Decide which scanner outputs enter the findings register, how duplicates from repeated scans are merged, and who signs off on accepted risk. Scans that cover only part of the CUI boundary will report incomplete findings, so confirm which asset groups each scan task targets.

Systems that process, store or transmit CUI

The findings in scope come from the systems that process, store or transmit CUI, including the security tools and administrative systems that protect them. Their boundary is set by the system security plan, and the scope of CUI systems determines which findings must be tracked to closure. Findings from systems that touch the boundary, such as identity providers or management consoles, usually count because they can affect CUI systems. Document the boundary decision and review it when the architecture changes.

Out-of-boundary systems

A finding on a system outside the CUI boundary is a scoping question, not an automatic obligation. Ask whether the system shares credentials, network segments, backups or administrators with a CUI system, because a shared dependency usually brings the finding into scope. Record the reasoning for each excluded system so an assessor can follow it. Confirm this approach with the federal agency or prime contractor whose contract defines the requirement.

Third-party and supplier findings

Findings reach the organization from cloud providers, managed service providers, software suppliers and external assessors. Their reports can arrive in formats that the organization must translate into its own findings register. Under the 03.17 supply chain requirements, the organization should know which suppliers provide findings and how quickly they must share them. Ask each supplier for its vulnerability disclosure and reporting terms in writing before relying on them for risk response.

How an assessor tests 03.11.04 under SP 800-171A

This table shows how an assessor works through the three determination statements for 03.11.04 using the examine, interview and test methods, with the evidence each object type usually produces. Read each row as one assessment object, the question the assessor asks about it, and the gap that most often appears in practice.

Assessment object	What the assessor checks	Evidence requested	Common findings
Examine: risk assessment policy	Whether the policy defines how assessment results are routed to a response decision, who approves the response, and how deadlines are set	Current policy and procedure documents, version history, and approval records	Policy exists but names no owner for accepting risk or no link to the assessment process
Examine: assessment reports and system audit records and event logs	Whether each finding from assessments, monitoring and audits has a recorded response such as remediation, mitigation, or accepted risk	Findings register or ticket export with status, owner, dates and closure evidence	Findings open for long periods with no documented disposition, or closed without verification
Interview: personnel with assessment and auditing responsibilities	How findings reach decision makers and how responses are prioritized and tracked	Walkthrough of the finding lifecycle using a real recent example from the organization	Staff describe the process differently, or responsibilities for risk acceptance are unclear
Interview: system administrators and personnel with security responsibilities	Whether those who implement fixes know what to do, and how exceptions are approved	Change records linked to findings and examples of exceptions with approval	Fixes applied outside change control, so the response cannot be traced to the finding
Test: processes for assessments and audits	Whether the response process runs as written when a finding is raised	Test finding traced end to end from source report to closure	Process stops at ticket creation with no escalation path for overdue items
Test: mechanisms and tools supporting assessments and auditing	Whether tools generate, store and route findings so responses can be tracked and reviewed	Tool configuration, user and permission lists, and sample exports showing status history	Findings not imported from scanners, duplicates left open, or no audit trail of status changes

How to build a finding-to-action process that passes review

This sequence turns findings from assessments, monitoring and audits into dated decisions, tracked plans and verified closures, so an assessor can trace each result to a documented outcome. The organization owns every decision; an implementation partner can prepare the records, tooling and evidence that show the process ran.

Name finding sources and owners
Start by listing every source that produces findings for the CUI environment: vulnerability scans, security assessments, continuous monitoring, audit log reviews, penetration tests, supply chain reviews and internal or external audits. For each source, name an owner who receives its output and is accountable for the next action. Record the sources and owners in the risk assessment policy and procedures so an assessor can compare them against the examine and interview objects listed for 03.11.04. The step is done when every source has a named owner and that mapping is approved and stored with the policy.
Set intake and deduplication rules
Define how findings enter the process: which system or ticket queue receives them, what fields each record must carry (asset, source, date, description and evidence), and how repeat findings from different tools are matched. Deduplication matters because the same weakness can appear in several scanners and assessments, and duplicate records make closure metrics misleading. Tools such as DefectDojo can import findings from many report formats and deduplicate them using per-tool hashcode fields, but the organization must decide the matching logic and confirm it in its own environment. The output is a written intake standard and a sample of imported records showing consistent fields.
Define triage and severity criteria
Set the criteria the organization uses to rank findings: asset criticality, whether the asset stores, processes or transmits CUI, exploitability, exposure and compensating controls. Document the severity levels and the response expectations tied to each level. NIST leaves the specific values to the organization for the parameters it names, so these thresholds, and any response times that connect to the vulnerability monitoring requirements, must be defined by the organization and approved by its decision makers. The output is a triage standard that an assessor can read and check against a sample of triaged findings.
Assign remediation or risk acceptance decisions
For each triaged finding, a named owner chooses one of two outcomes: remediate the weakness, or accept the residual risk with a documented rationale and an approver with authority to accept it. Risk acceptance should not be a silent default. Each decision needs a target date set by the organization under its own standard, and the record should link to the affected system and to the risk assessment. The output is a decision log entry for every finding, with the outcome, the approver and the date. Ask your assessor early which evidence format they expect for acceptances.
Track plans of action and milestones
Findings that will not close immediately move into a tracked plan that lists the weakness, the corrective steps, the responsible owner, the milestones and the expected completion date. Requirement 03.12 also uses plans of action and milestones for security assessment, so the same records can serve both requirements if the organization structures them consistently. Review open items on the schedule the organization defined, escalate overdue items to the people who approved them, and record each change instead of overwriting history. The output is a current register of open items with an auditable change history.
Verify fixes before closing
A finding is not closed when someone says it is fixed. Verification means re-running the scan, re-test or configuration check that found the weakness, or examining the change record and confirming the result. Keep the verification output with the finding so it can be reviewed later. Where a fix is a compensating control or risk acceptance, verify that the control is operating as described. The output is a verification artifact, such as a re-scan report or a dated configuration check, attached to each closed record.
Close records and review the process
Close each record only after the verification artifact is attached, the decision is documented and the owner signs off. Periodically sample closed findings to confirm that closure evidence exists, that acceptances were approved by the right authority and that repeat findings are being recognized as repeats. Feed patterns back into the risk assessment and the assessment program. Keep closed records for the retention period the organization sets. The output is a closure log and a periodic review record that an assessor can sample during testing.

Evidence that satisfies 03.11.04 and how to keep it current

An assessor testing 03.11.04 Risk response follows one thread: a finding from an assessment, monitoring activity or audit, through a documented decision, to proof that the decision was carried out and reviewed. The artifacts below form that chain, and each is easiest to defend when it is updated as work happens rather than assembled before an assessment.

Risk response procedure

This is the written procedure that says how findings are triaged, who decides between fixing, accepting, transferring or avoiding a risk, and how long each step may take. Assessors look for a procedure that names roles and matches what staff actually do. Review it on a defined schedule, record the version and approval date, and confirm that the scanning, monitoring and audit teams all follow the same steps.

Assessment and audit reports

These are the outputs of risk assessments, vulnerability scans, monitoring reviews and internal or external audits, each showing the scope, date, method and findings. Keep every report as issued, not only the summary, so the findings can be traced back to their source. Import results into a single findings register as they arrive, and note which tool, scan or auditor produced each record.

Remediation or risk acceptance record

For each finding, the record shows the owner, the chosen response, the target date, and the closure or acceptance decision. A risk acceptance needs a named approver with authority to accept the risk, a stated rationale and an expiry or review date. Track changes to status over time instead of overwriting them, because an assessor will ask when a finding was opened and when it was closed.

Verification records

Verification shows that a fix worked, not only that a ticket was closed. Keep the rescan output, configuration evidence, test results or re-review notes that confirm the corrected state. Link each verification record to the original finding so the chain holds. Where a finding is accepted rather than fixed, keep the periodic re-check that confirms the accepted condition has not changed.

Plans of action and milestones

When a finding cannot be closed by its target date, the plan of action and milestones records the weakness, the planned corrective steps, the owner and the milestone dates. Assessors compare these plans against the findings register to confirm nothing open has been left out. Update milestones as they move and record the reason for each change, so the plan reflects current status rather than the original estimate.

Audit logs showing review

Logs prove that findings were actually reviewed, not only generated. Keep records of who viewed or triaged each finding, when status changed, and when responsible staff reviewed open items. Confirm that the audit logs covering the findings tools are themselves retained and protected, because an assessor may ask to see both the review and the trail behind it. Export a sample of review activity each quarter so it is ready on request.

What meeting 03.11.04 costs in money and effort

This table breaks the cost of meeting 03.11.04 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are stated because none are supplied for this requirement, so use the table to structure a written quote and to compare what each option removes from the budget.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendor or internal budget holder	Recurring for commercial tools; one-time setup	Number of finding sources and tools; self-hosted open source can remove license spend but not operating effort
Engineering time to build intake and tracking	Internal platform team or implementation partner under a fixed scope	One-time, with later changes	Number of sources feeding findings, deduplication rules, and integration with ticketing and the system security plan
Staff time for triage and decisions	Security staff, system owners, and risk decision makers	Recurring	Finding volume, severity mix, and how clearly response timelines and owners are defined in advance
Evidence upkeep	Internal compliance or GRC staff	Recurring	Frequency of assessments and audits, retention of records, and how much evidence is generated automatically
External testing or review	Independent testers or assessors engaged by the organization	Recurring, usually tied to a review cycle	Scope of systems tested, depth of testing, and whether reviews are scheduled or ad hoc
Auditor sampling	Independent assessor, paid by the organization	Recurring per assessment cycle	Number of findings sampled, quality of response records, and clarity of documented decisions
Remediation and retesting	System owners and operations staff	Recurring	Number of confirmed findings and the effort to fix and verify each one

Open-source tools that can produce 03.11.04 evidence

Three open-source tools cover different parts of the 03.11.04 evidence chain: collecting vulnerability results, consolidating findings from other tools, and tracking assessments against frameworks. None of them decides how a finding is responded to, so the organization still owns the response record. Each card names what the tool produces and what the team must configure before it can serve as evidence.

DefectDojo for finding consolidation

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and it offers a generic findings import for formats it does not support natively. It deduplicates findings using per-tool hashcode fields, so a finding that reappears in a later scan updates the existing record rather than creating a duplicate. For 03.11.04, the evidence is the finding history: when each result arrived, who owned it, and what was done. Confirm that the tool versions in your pipeline are on the supported list, that hashcode settings match each tool's output, and that closure reasons are recorded consistently so assessors can trace each response.

Greenbone Community Edition for scan results

Greenbone Community Edition (OpenVAS) is licensed under AGPL-3.0-or-later. Its gvmd service stores scan results in PostgreSQL, manages users and permissions, and schedules scan tasks, while users run scans and review results in the Greenbone Security Assistant web interface. The stored results give an assessor dated, repeatable records of what was found and when. Confirm the scan schedule, the access roles that restrict who can change or close results, the backup of the PostgreSQL database, and the retention period for past results, since these determine whether the scan history can be produced during an assessment.

CISO Assistant for assessment tracking

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including NIST CSF, ISO 27001, SOC 2 and NIS2, and it runs audits and compliance assessments against them with automatic mapping between frameworks. For 03.11.04, it can hold the risk assessment policy, the assessment reports and the response decisions as linked evidence against the requirement. Automatic mapping is a convenience that must be checked, because the organization must confirm that any mapping it relies on matches the framework text it is assessed against. Confirm which framework version is loaded, who approves each response decision, and how the tool records exceptions and accepted risks.

Who owns 03.11.04 and what can be outsourced

The organization owns the requirement. 03.11.04 asks that findings from security assessments, monitoring and audits lead to action, and that decision belongs to the people accountable for the CUI environment. No partner can accept a risk on your behalf or decide that a finding is acceptable. Your team sets the response procedure, decides which findings must be fixed, and signs off on exceptions.

Risk decisions: Named owners decide whether a finding is remediated, mitigated, transferred or accepted, and record the reasoning.
Response procedure: A written procedure defines triage, priority, owners, timeframes and escalation for each finding source.
Accepted-risk record: Every accepted risk has an approver, a rationale, a compensating measure and a review date.
Staff time: Your system administrators and security staff must actually work the findings, which a partner cannot do for you.
Policy alignment: The procedure must match your risk assessment policy and your system security plan.

Before engaging anyone, confirm who signs the accepted-risk record and whether that person can be reached during an assessment.

Questions buyers ask about 03.11.04 cost, effort and scope

Can we handle 03.11.04 risk response in-house?

Yes, if you already have an assessment and monitoring process that produces findings, and a team that owns the decisions about them. The requirement asks you to respond to findings from security assessments, monitoring and audits, so the work is mostly governance and disciplined follow-through rather than new tooling. Most organizations struggle with the handoffs: deciding who triages a finding, who accepts a risk, who approves a fix, and how the outcome is recorded. Assessors will look for a written procedure and records showing that findings were actually acted on. If your team lacks capacity or has never run this loop end to end, an implementation partner can help build the workflow, but the organization must still own the risk decisions.

How much extra effort does 03.11.04 add beyond 03.11.01 and 03.11.02?

Usually less than the two requirements it follows, because 03.11.04 consumes their outputs rather than creating new assessments. Risk assessment under 03.11.01 and vulnerability monitoring under 03.11.02 generate the findings; 03.11.04 adds the response layer: triage, assignment, remediation or documented risk acceptance, and evidence that each step happened. The effort therefore depends on finding volume and how well the earlier processes already record results. Tracking findings in a single system, with owners and due dates, is what keeps this manageable. Ask any partner to estimate effort from your actual finding counts and current ticketing practice, and confirm that estimate in writing before work starts.

What does the work need from our team?

It needs named owners from several functions, not only security. The work typically involves a security lead to set triage rules, system owners to fix issues in their systems, a risk owner who can accept residual risk, and an auditor-facing contact who holds the evidence. Administrators must be able to pull logs and scan results on request. SP 800-171A Rev. 3 assesses 03.11.04 through examining the risk assessment policy, assessment reports and audit records, interviewing people with assessment and auditing responsibilities, and testing the processes and tools that support them. Your team should be ready to explain those processes and show them working.

How does 03.11.04 relate to Rev. 2 and CMMC?

It has no Rev. 2 counterpart, so it does not appear in the CMMC Level 2 assessment. NIST's change analysis lists 03.11.04 as one of 19 requirements new in Rev. 3, and NIST maps no Rev. 2 requirement to it. Because 32 CFR 170.14(c)(3) makes CMMC Level 2 identical to Rev. 2, that assessment covers 110 requirements with no matching ID. The DoD's current direction, as stated in Class Deviation 2026-O0025, Revision 3, names Rev. 2 for contracting purposes, while a proposed FAR rule would require Rev. 3 using DoW-published ODP values. Check which version your contract names before deciding how much weight to give this requirement now.

Can a partner take on 03.11.04 under a fixed scope?

Yes. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For 03.11.04, a scope would typically cover reviewing your existing assessment and monitoring outputs, defining the response workflow, configuring the open-source platforms that track findings, and preparing the evidence an assessor will request. It would not cover the decisions your organization makes about risk acceptance, and DeployOpen does not issue audit reports or certifications. Ongoing support and continuous testing are available as retainers if findings need upkeep after the initial build.

What should we ask for in a quote for 03.11.04?

Ask for a written scope that names each system in the response workflow, the platforms in use, and the evidence to be delivered. A useful quote separates one-time work, such as designing the procedure and configuring tools, from recurring work, such as reviewing findings, retaining records and updating the process when assessments change. Confirm who is responsible for each part, including what the client must supply, such as scan access, ticket exports and named owners. Ask how changes to scope are priced and how the partner will handle findings it discovers during the work. Costs rise with the number of systems in the CUI boundary, the volume of findings and the number of owners who must sign off.

Which open-source tools can support 03.11.04 evidence?

DefectDojo and Greenbone Community Edition are the two most directly relevant. DefectDojo imports and reimports findings from more than 500 security tool report formats, including through its open source edition, and deduplicates them using per-tool hashcode fields, which keeps one vulnerability from being tracked as many. Greenbone Community Edition (OpenVAS) stores scan results in PostgreSQL and schedules scan tasks through gvmd. CISO Assistant can record assessments and map them to frameworks, which helps show the chain from finding to decision. Confirm each tool's integration with your existing scanners and ticketing system in your own environment before committing to a design.

How DeployOpen scopes and prepares 03.11.04 evidence

DeployOpen works on 03.11.04 Risk response as an implementation partner. We help the organization build the path from assessment findings, monitoring results and audit results to tracked, owned action, and we prepare the records an assessor will examine. The organization keeps ownership of its controls, and only an independent assessor issues assessment results.

How we scope

Confirm which assessment, monitoring and audit sources feed the response process for the CUI environment.
Agree in writing which systems, ticketing tools and finding sources are in scope for 03.11.04 evidence.
Record the response timelines and ownership roles the organization will define, since those values are set by the organization.

How we build

Configure a findings pipeline, for example DefectDojo, to import and deduplicate results from scanners and assessment tools.
Set up the vulnerability management service, such as Greenbone Community Edition, so scan results are stored and reviewed in one place.
Map each finding to an owner, a documented decision and a remediation or risk acceptance record that an assessor can trace.

How we hand over

Deliver the risk response procedure and the records that show how findings were triaged, assigned and closed.
Provide a walkthrough of audit records and assessment reports so interviewed staff can explain the process.
Document the configuration, data flows and access settings of the tooling so the organization can operate it without us.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if the organization wants help keeping the process current.
Confirm with your assessor which evidence formats they accept before we finalize the handover package.

03.11.04 Risk response