03.07.04: and 03.07.06.

NIST SP 800-171 Rev. 3 requirements 03.07.04 and 03.07.06 expect you to translate the requirement into implementable controls with clear ownership, then prove those controls operate through assessment-ready evidence and tracked remediation. Operationalize them by mapping to your SSP, defining measurable criteria, collecting recurring artifacts, and governing gaps in a POA&M until closure is validated. ¹

Key takeaways:

• Tie the requirement to specific system components and accountable control owners in your SSP. ¹
• Define “done” in measurable terms, then collect operational evidence on a recurring basis that an assessor can re-perform. ²
• Manage gaps through a POA&M with risk ratings, target dates, and closure validation, not “we plan to.” ¹

For most CCOs and GRC leads, “meeting NIST 800-171” fails in two predictable ways: controls are described at a policy level with no clear implementation boundary, or controls exist in tooling but the evidence is scattered, inconsistent, and can’t survive an assessment. Requirements 03.07.04 and 03.07.06 sit in the operational middle: they push you to make the control real (mapped to systems and owners) and provable (tested and evidenced), then to govern the inevitable gaps through disciplined remediation tracking.

This page treats 03.07.04 and 03.07.06 as a paired execution requirement: document what you do (in the System Security Plan), show that you do it (with repeatable evidence aligned to assessment methods), and prove you fixed what you didn’t do (with a POA&M that closes the loop). The goal is straightforward: if an assessor asks “show me,” your team can produce a coherent control narrative and a complete evidence trail without rebuilding the program in the conference room. Primary references are NIST SP 800-171 Rev. 3 and NIST SP 800-171A. ^{1 2}

Regulatory text

Provided excerpt: “NIST SP 800-171 Rev. 3 requirement 03.07.04 (and 03.07.06.).” ¹

Operator interpretation (what you must do): You need an assessment-ready implementation for these requirements: each requirement must be (1) mapped into your System Security Plan (SSP) as a concrete control statement with named owners and in-scope system components, and (2) supported by repeatable operational evidence and remediation governance using a POA&M for gaps through closure validation. The assessment lens and evidence expectations should align to NIST SP 800-171A assessment approaches (examine, interview, test). ^{1 2}

Plain-English interpretation

• 03.07.04 (practical meaning): “Show your work.” Don’t stop at policy language. Describe how the requirement is implemented in your environment, where it’s implemented, and who is accountable for keeping it working. ¹
• 03.07.06 (practical meaning): “Prove it keeps working, and manage gaps like a program.” Maintain evidence that controls operate, assess them periodically in a way an assessor can follow, and track/close deficiencies in a POA&M with discipline. ^{1 2}

Who it applies to

Entity scope

• Nonfederal organizations that handle Controlled Unclassified Information (CUI) in support of federal work, including federal contractors and subcontractors. ¹

Operational scope (where teams get tripped up)

Applies to the CUI environment boundary, including:

• Systems that store, process, or transmit CUI.
• Supporting security services (identity provider, EDR, SIEM, vulnerability scanning, backups) if they are part of how controls are implemented for the CUI boundary.
• Third parties in the boundary (managed service providers, cloud service providers, specialized engineering firms) when their services implement or affect your safeguards for CUI.

If you cannot clearly draw the boundary, you cannot credibly map 03.07.04/03.07.06 to “the system,” and evidence becomes ad hoc.

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

Step 1: Create a control-to-implementation map in your SSP

Build SSP entries that are implementable and assessable:

1. Write the control statement in environment-specific language. Avoid copying requirement text as your implementation.
2. List responsible system components. Example component categories: endpoints, servers, cloud tenant(s), network segments, repositories, ticketing system, log platform.
3. Assign an accountable control owner. Use one named role (not “IT”) with a backup role.
4. Define boundaries and exclusions. If something is out of scope, say why and where the control is handled instead.
5. Identify evidence sources. Specify which logs, reports, tickets, or test outputs will prove operation.

This is the “map the requirement to SSP control statements, responsible system components, and accountable control owners” outcome. ¹

Practical tip: Put the “how we implement” detail where operators live (runbooks, standards), but ensure the SSP points to those documents and stays consistent.

Step 2: Define measurable implementation criteria (“definition of done”)

For each requirement, define criteria that an assessor can verify without reading your intent:

• What configuration state is expected?
• What events should exist (alerts, tickets, approvals)?
• What reviews occur and what constitutes pass/fail?
• What is the escalation path when the control fails?

This aligns to the “define measurable implementation criteria and collect recurring operational evidence” expectation. ¹

Step 3: Align evidence to NIST SP 800-171A assessment methods

NIST SP 800-171A frames how controls are assessed using examine, interview, and test. Build evidence packets that match those methods: ²

• Examine: policies, procedures, SSP excerpts, configuration baselines, screenshots, exported reports, change records.
• Interview: named process owners, administrators, helpdesk leads; a short interview script that matches the SSP narrative.
• Test: reproduce a control outcome (for example, demonstrate alerting, access enforcement, logging, or a configuration state).

Evidence rule: Evidence should be repeatable. If your evidence is “someone remembers,” you will lose time and credibility during assessment.

Step 4: Run an internal control check and open POA&M items for gaps

Conduct a focused check against your measurable criteria:

1. Validate the SSP statement matches reality.
2. Sample evidence across relevant systems (not a single “happy path” screenshot).
3. Identify gaps as POA&M entries with:
   • Clear deficiency statement tied to the requirement
   • Risk rating (qualitative is fine)
   • Target completion date
   • Interim risk treatment (compensating controls if applicable)
   • Owner and closure criteria
4. Require closure validation: do not close a POA&M item until the evidence demonstrates the fix is implemented and operating.

This is the “track gaps in POA&M with target dates, risk ratings, and closure validation before marking complete” outcome. ¹

Step 5: Operationalize recurring evidence collection

Treat evidence like a production process:

• Assign evidence owners (often the same as control owners).
• Define where evidence is stored and how it is labeled.
• Standardize artifacts (templates for review sign-offs, test scripts, export formats).
• Record exceptions and their approvals.

Where Daydream fits naturally: teams commonly fail on evidence sprawl. A GRC workflow in Daydream can bind the SSP control statement, evidence checklist, and POA&M task chain to the same requirement record, so audits don’t become a document scavenger hunt.

Required evidence and artifacts to retain

Keep artifacts that prove (a) control design, (b) control operation, and (c) remediation governance. Examples:

• SSP control statements for 03.07.04/03.07.06 with component scope and ownership. ¹
• Procedures/runbooks referenced by SSP (access management, logging, vulnerability management, incident handling, configuration management), where applicable. ¹
• Evidence of operation: system exports, logs, review records, approvals, test results aligned to examine/interview/test. ²
• Assessment workpapers: internal checklists, test scripts, sampling notes, and outcome summaries aligned to NIST SP 800-171A. ²
• POA&M register with owners, target dates, status, risk notes, and closure validation artifacts. ¹

Common exam/audit questions and hangups

Expect assessors to press on coherence and traceability:

• “Show me where this requirement is implemented in your SSP and which systems it covers.” ¹
• “Who is the control owner, and what do they do to keep it operating?” ¹
• “Show evidence from multiple points in time, not a single screenshot.” ²
• “Demonstrate the test method you used. What did you examine, who did you interview, what did you test?” ²
• “Why is this POA&M item still open? What is the compensating control and who accepted the risk?” ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
SSP contains copied requirement text	No implementation boundary or “how”	Write environment-specific statements and list system components and owners. 1
Evidence is ad hoc	Cannot be re-performed; inconsistent across teams	Build an evidence checklist mapped to examine/interview/test and standardize exports. 2
POA&M is a parking lot	Open items never close; no validation	Require closure criteria and closure validation artifacts before status changes. 1
“Tool = control” thinking	Tools exist but aren’t configured, monitored, or reviewed	Define measurable criteria and keep recurring operational proof. 1
Boundary confusion	Control appears “implemented” but outside the CUI boundary	Document boundary clearly and map each requirement to that boundary. 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list case examples. Practically, the risk is contractual and assessment-driven: weak SSP specificity, missing evidence, and unmanaged POA&M gaps create findings, delay awards, and increase the chance your CUI environment is judged not assessment-ready. ^{1 2}

Practical 30/60/90-day execution plan

First 30 days (stabilize documentation and ownership)

• Confirm the CUI boundary and inventory in-scope systems and third parties.
• Update SSP entries for 03.07.04/03.07.06 with control owner, components, and evidence sources. ¹
• Stand up an evidence repository structure and naming convention aligned to NIST SP 800-171A methods. ²

By 60 days (make it testable and repeatable)

• Define measurable implementation criteria per control statement.
• Run an internal assessment-style check (examine/interview/test) and document workpapers. ²
• Create POA&M items for every gap with owners, target dates, and closure criteria. ¹

By 90 days (operate the governance loop)

• Start recurring evidence collection and review cadence owned by control owners.
• Validate at least one POA&M closure end-to-end (fix implemented, evidence collected, closure validated).
• Put metrics in front of leadership: open POA&M items by risk tier, overdue items, and evidence freshness (qualitative if needed).

If you need to accelerate, Daydream can centralize SSP narratives, evidence requests, and POA&M workflows so control owners produce artifacts in a consistent format without GRC chasing emails.

Frequently Asked Questions

How do I write an SSP statement that won’t get flagged as “too generic”?

Include three elements: the implementation mechanism (“how”), the scoped components (“where”), and the accountable owner (“who”). Then list the specific evidence sources you will provide during assessment. ¹

What evidence is strongest for 03.07.04 and 03.07.06?

Evidence that supports examine/interview/test is strongest: configuration exports and logs (examine), named role interviews with a consistent script (interview), and a repeatable demonstration of control behavior (test). ²

Can I keep POA&M items open indefinitely if we have a plan?

You can track gaps in a POA&M, but assessors will expect ownership, target dates, interim risk handling, and closure validation once remediation is complete. A “plan” without validation artifacts usually does not clear the finding. ¹

Do third parties need to be included in these mappings?

If a third party provides services that implement or materially affect safeguards in the CUI boundary, you need to reflect that dependency in scope, ownership, and evidence collection. Otherwise the SSP narrative will not match operational reality. ¹

What’s the fastest way to get assessment-ready if my evidence is scattered?

Build an evidence index per requirement: artifact name, system of record, owner, and collection method aligned to NIST SP 800-171A. Then collect a first “baseline” packet and refine until it is repeatable. ²

How should we prove POA&M closure?

Require closure criteria up front (what evidence will prove the fix), then collect that evidence after remediation and have a second party review it before marking closed. Store the validation with the POA&M record. ¹

Footnotes

1. NIST SP 800-171 Rev. 3

2. NIST SP 800-171A