03.07.04: and 03.07.06.

A CCO or GRC lead usually gets stuck on NIST SP 800-171 requirements for one of two reasons: the control text is precise but the operational expectations are implicit, and teams collect evidence late (or inconsistently) right before an assessment. The result is a scramble to reconstruct what happened, who approved it, and whether the control actually operated over time.

This page gives requirement-level implementation guidance for “03.07.04: and 03.07.06.” as referenced in NIST SP 800-171 Rev. 3 ¹. The practical goal is simple: you should be able to point an assessor to a control statement, show where it is implemented in the environment(s) that process/store/transmit CUI, and produce clean evidence that ties directly back to each requirement.

Because the provided source excerpt does not include the full verbatim control language for 03.07.04 and 03.07.06, this guidance focuses on how to operationalize the requirement as a compliance deliverable: define scope, map to controls, assign ownership, implement, and maintain recurring evidence that stands up in audits against NIST SP 800-171 Rev. 3 ¹.

Regulatory text

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

What the operator must do with this text (practical interpretation):

1. Treat 03.07.04 and 03.07.06 as distinct requirements under NIST SP 800-171 Rev. 3, each requiring a documented control design and proof of operation ¹.
2. Implement controls in the CUI scope boundary (people, process, technology) where CUI is processed, stored, or transmitted ¹.
3. Maintain assessment-ready evidence: mapping, implementation details, and recurring operational records that show the controls are not “paper-only” ¹.

If you are building an SSP/assessment package, the minimum expectation is that each requirement maps to: (a) a policy statement, (b) a procedure/runbook, (c) technical configuration or system behavior, and (d) routine evidence collection.

Plain-English interpretation (what 03.07.04 and 03.07.06 mean in practice)

You are accountable for two things:

• Control design: You can explain how your organization meets the intent of 03.07.04 and 03.07.06 in the real environment(s) that handle CUI ¹.
• Control operation: You can prove the control ran as expected, exceptions were handled, and issues were tracked to closure ¹.

Given the limited excerpt, the safest operational stance is to assume an assessor will test:

• Whether the requirements are implemented in-scope (not in an unrelated corporate environment).
• Whether the controls are consistently applied (not one-off).
• Whether evidence is traceable: requirement → control → system(s) → artifact(s).

Who it applies to (entity and operational context)

This applies to:

• Federal contractors and subcontractors operating nonfederal systems that handle CUI ¹.
• Any business unit, program, enclave, or cloud environment that stores, processes, or transmits CUI, including shared services that are within the authorized boundary ¹.

Operationally, expect it to touch:

• IT/security operations (system configuration, monitoring, and logging)
• GRC/compliance (control mapping, SSP content, evidence management)
• Engineering (where CUI systems are built/maintained)
• Third-party management (if a third party provides in-scope infrastructure or security tooling)

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

Step 1: Confirm scope and boundary for CUI systems

• Identify in-scope systems, networks, identities, endpoints, and cloud services that handle CUI.
• Document boundary decisions in your SSP artifacts (or equivalent).
  Output: “CUI System Inventory + Boundary Statement” tied to the program(s) ¹.

Step 2: Build a requirement-to-control mapping for 03.07.04 and 03.07.06

Create a simple mapping table:

Requirement	Control statement (your words)	Control type	Control owner	Systems in scope	Evidence source
03.07.04	Describe how you satisfy it	Prevent/Detect/Correct	Named role	Named systems	Logs/tickets/config

Rule: Do not map both requirements to one generic “security policy” control. Split them. Assessors treat them separately ¹.

Step 3: Align policy, standard, and procedure (write what you do)

Minimum documentation set:

• Policy: high-level commitment and governance.
• Standard: specific configuration/security requirements that apply to in-scope systems.
• Procedure/runbook: step-by-step operational actions (who does what, where, what tool, what record is produced).

Make each document cite the requirement IDs 03.07.04 and 03.07.06 explicitly so the trail is obvious ¹.

Step 4: Implement the control in the environment (make it testable)

This is where many teams fail: they describe a control but cannot demonstrate it in the systems that handle CUI.

Implementation checklist (adapt to the actual control intent once you pull the exact control text from NIST):

• Confirm the control is enabled/configured in the in-scope tools (directory, endpoint, email, SIEM, cloud platform, etc.).
• Verify inheritance: if you rely on a third party (cloud/SaaS/MSSP), document the shared responsibility and what you verify yourself.
• Establish exception handling: who approves deviations, where exceptions are recorded, and how they expire.

Step 5: Set up recurring evidence collection (don’t wait for the audit)

Build an evidence cadence that produces artifacts naturally as part of operations:

• Configuration exports (where appropriate)
• Change tickets showing control-related changes
• Monitoring outputs and alert handling tickets
• Access reviews or operational reviews relevant to the requirement
• Exception register entries and approvals

A practical approach is an “evidence playlist” per requirement: a short list of artifacts you can pull on demand that proves the control operated.

Step 6: Operational QA: test like an assessor

Run an internal “audit drill”:

• Pick an in-scope system.
• Ask the control owner to produce evidence for 03.07.04 and 03.07.06.
• Verify each artifact answers: what happened, when, who approved, what system, and what requirement.

If you use Daydream, configure each requirement as a record with mapped controls, owners, and recurring evidence requests so evidence collection happens continuously rather than during a last-minute scramble ¹.

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Design evidence

• Requirement-to-control mapping sheet (03.07.04 and 03.07.06 separated)
• SSP/control narrative for each requirement (where you describe implementation)
• Policies/standards/procedures that cite the requirement IDs ¹

Operational evidence (examples of what auditors actually accept)

• System configuration snapshots/exports that demonstrate settings tied to the control
• Tickets for control-related changes, approvals, and implementations
• Monitoring/alert artifacts with triage and closure records
• Exception register (with approvals, scope, expiry, compensating controls)
• Training/acknowledgment records if the control relies on user action

Evidence hygiene rules:

• Timestamp everything.
• Identify the system and environment (prod/dev; enclave name).
• Tie each artifact back to 03.07.04 or 03.07.06 in the filename, ticket tag, or GRC record.

Common exam/audit questions and hangups

Auditors and assessors tend to probe these areas:

• “Show me this control operating on the systems that handle CUI, not your corporate IT baseline.” ¹
• “Who owns 03.07.04? Who owns 03.07.06? What happens if they’re out?”
• “Where is the documented procedure, and what evidence does it generate?”
• “How do you track and approve exceptions, and how do you know they expire?”
• “If a third party provides the service, what do you validate yourself?”

Hangups that trigger findings:

• Evidence exists but is not clearly in-scope for CUI.
• A “policy-only” mapping with no system proof.
• Evidence is ad hoc, inconsistent, or lacks timestamps/owners.

Frequent implementation mistakes and how to avoid them

1. Combining both requirements into one generic control.
   Fix: Create separate control statements, separate owners, and separate evidence lists.

2. Relying on screenshots with no provenance.
   Fix: Prefer exports, logs, and system-generated reports. If you must use screenshots, pair them with configuration IDs and change tickets.

3. No exception governance.
   Fix: Maintain an exception register with approvals and expirations tied to requirements ¹.

4. Third-party dependency with no verification.
   Fix: Document shared responsibility, collect third-party attestations where available, and retain your own validation evidence (service settings, tenant configs, or monitoring outputs).

Enforcement context and risk implications

NIST SP 800-171 is a control standard used in federal contracting contexts to protect CUI ¹. The most common real-world risk is not a dramatic “policy gap.” It is an evidence gap: you did the work, but you cannot prove it, or you proved it once and cannot show ongoing operation. That translates into assessment findings, delayed contract milestones, and program friction.

A practical 30/60/90-day execution plan

Because no source-backed implementation durations are provided, treat the plan as phases you can execute quickly.

Immediate: establish clarity and ownership

• Pull the exact control statements for 03.07.04 and 03.07.06 from NIST SP 800-171 Rev. 3 and paste them into your control register ¹.
• Assign control owners and backups; document escalation paths.
• Define in-scope CUI systems and confirm boundary.

Near-term: implement and document

• Draft/update policy/standard/procedure so each explicitly references 03.07.04 and 03.07.06.
• Implement the technical and operational steps in the in-scope environment.
• Stand up exception handling and recordkeeping.

Ongoing: evidence and internal testing

• Create a recurring evidence plan: what artifacts, who collects them, and where they are stored.
• Run quarterly internal sampling (or align to your assessment cycle): can each owner produce evidence in a single request?
• Track gaps as POA&M items and drive closure with dates and owners.

Frequently Asked Questions

Do I need separate policies for 03.07.04 and 03.07.06?

Usually no. You need separate control statements and evidence trails per requirement, even if a single policy covers both. Make the mapping and artifacts distinct so an assessor can test each requirement cleanly ¹.

What’s the minimum evidence that passes an assessment?

A control narrative tied to the requirement plus system-level proof that the control is enabled and operating in the CUI boundary. Pair configuration evidence with operational records like tickets, logs, or reports that show ongoing execution ¹.

We use a cloud provider. Can we inherit compliance for these requirements?

You can inherit parts of implementation, but you still own demonstrating how requirements are met for your CUI processing. Document shared responsibility and retain tenant-level configuration and monitoring evidence you control ¹.

How do I stop evidence collection from becoming a fire drill?

Define an evidence playlist per requirement and collect artifacts as part of normal operations (change management, monitoring, access workflows). Tools like Daydream help by assigning owners and scheduling recurring evidence requests against each requirement ¹.

Can I mark 03.07.04 and 03.07.06 as “not applicable”?

Only if you can justify exclusion based on your system boundary and how CUI is handled, and that justification holds up to scrutiny. Document the rationale in the SSP/control register and keep it consistent with the actual environment ¹.

What’s the fastest way to find gaps?

Run a tabletop test: ask the control owner to produce evidence for one in-scope system on demand. If they can’t produce it quickly, you have either an implementation gap or an evidence/recordkeeping gap ¹.

Footnotes

1. NIST SP 800-171 Rev. 3