03.05.08: Withdrawn

03.05.08 is a withdrawn requirement in NIST SP 800-171 Rev. 3, so you do not implement a standalone control for it. You still must operationalize it by documenting that it is withdrawn, mapping any legacy Rev. 2 control work to the current Rev. 3 requirement set, and retaining evidence that your scoping, traceability, and assessment approach correctly treats 03.05.08 as “not applicable (withdrawn).”

Key takeaways:

• Treat 03.05.08: withdrawn requirement as a governance and traceability task, not a technical implementation task.
• Preserve assessment readiness by documenting how you handled the withdrawal in your SSP/control matrix and audit trail.
• If you previously implemented a Rev. 2-era equivalent, decide whether to keep it as a compensating/internal control or retire it with risk acceptance and change control.

Withdrawn requirements create a specific kind of compliance risk: not the risk of missing a security control, but the risk of misrepresenting your control baseline, confusing assessors, and breaking traceability across versions. For a CCO, CISO, or GRC lead supporting NIST SP 800-171 programs (especially where contract language, customer clauses, or internal policy still references older control catalogs), the operational goal is simple: show that you have a reliable method to detect withdrawals, update your documentation, and avoid “ghost controls” that waste time or create contradictions.

NIST SP 800-171 Rev. 3 explicitly marks 03.05.08 as “Withdrawn” ¹. That means there is no current Rev. 3 requirement text to implement for 03.05.08. Your work is to ensure your system security plan (SSP), control implementation narratives, and evidence collection schedules reflect reality, and that any legacy control activity is either mapped forward to a current requirement, retained voluntarily, or formally retired.

This page tells you exactly what to do to operationalize 03.05.08 in a way that survives audits, customer reviews, and internal governance scrutiny.

Regulatory text

Excerpt / status: “NIST SP 800-171 Rev. 3 requirement 03.05.08 (Withdrawn).” ¹

What the operator must do

Because 03.05.08 is withdrawn, your obligation is not to “implement” it as a security requirement. Your obligation is to:

1. Record the withdrawal in your control baseline documentation (SSP, control matrix, requirement register).
2. Prevent assessment confusion by clearly marking it as withdrawn/not applicable and ensuring it does not appear as an unmet requirement.
3. Maintain traceability from prior baselines (for example, older internal policies, customer security schedules, or legacy mappings) to the Rev. 3 set so reviewers can see you did not skip work by accident.

If your organization previously implemented activities aligned to an older version’s similarly numbered requirement, you also need a governance decision: keep as an internal control, map it to an existing Rev. 3 requirement, or retire it with documented rationale.

Plain-English interpretation (what “withdrawn” means in practice)

“Withdrawn” means NIST removed this requirement from the Rev. 3 catalog. There is no longer a requirement statement to satisfy under Rev. 3 for 03.05.08 ¹.

Operationally, auditors and customers still expect you to show:

• You noticed it was withdrawn (you are maintaining the baseline).
• You updated your SSP/control crosswalk accordingly.
• You did not leave behind contradictory artifacts, like test plans, policies, or “open POA&M items” that claim 03.05.08 is required.

Think of this as configuration management for compliance documentation.

Who it applies to (entity and operational context)

This matters for any organization that:

• Is a federal contractor or supports federal programs, and
• Operates nonfederal systems that handle CUI and use NIST SP 800-171 as the required or referenced security baseline ¹.

Operational contexts where this comes up:

• SSP refresh cycles and readiness reviews against NIST SP 800-171 Rev. 3.
• Customer security questionnaires that still reference older requirement lists by number.
• Third-party due diligence where you flow down NIST SP 800-171 expectations to a third party handling your CUI.
• Internal audit where GRC compares “declared compliance” to the actual Rev. 3 requirement set.

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

Use the steps below to close 03.05.08 cleanly and keep your program assessment-ready.

Step 1: Confirm the baseline and version you are attesting to

• Update your program charter, SSP header, or compliance statement to explicitly reference NIST SP 800-171 Rev. 3 as the baseline for the system ¹.
• Identify where your organization references requirement numbers: SSP, control matrix, ticketing templates, policy cross-references, and third-party contract exhibits.

Deliverable: “Baseline declaration” note in SSP or control register that you are using NIST SP 800-171 Rev. 3 ¹.

Step 2: Mark 03.05.08 as withdrawn in your requirement register/control matrix

In your control matrix row for 03.05.08, set:

• Status: Withdrawn (Rev. 3) / Not applicable (withdrawn)
• Implementation: None required (withdrawn)
• Evidence: Governance evidence only (see below)

Do not mark it “Compliant” or “Implemented.” Withdrawn is not “pass”; it is “removed.”

Deliverable: Updated control matrix and SSP traceability entry citing withdrawal ¹.

Step 3: Resolve any legacy mappings and “orphaned” artifacts

Search for “03.05.08” across:

• Policies and standards
• Procedures/runbooks
• Control test scripts
• POA&M items
• Risk register entries
• Third-party due diligence templates and security addenda

For each find, take one of three actions:

Legacy artifact found	Action option	What to document
A policy section references 03.05.08	Update reference to Rev. 3 baseline; remove 03.05.08 citation	Change log entry and policy redline rationale
A technical control was built “for 03.05.08”	Map it to a current Rev. 3 requirement if it supports one	Crosswalk note: “legacy control supports X requirement(s)” 1
A task/test exists only for 03.05.08	Retire it, or keep it as an internal control	Risk acceptance or internal control designation; owner and review cadence

Deliverable: Crosswalk memo or “withdrawn requirements disposition log.”

Step 4: Update assessment approach and evidence collection routines

Adjust your recurring evidence plan so:

• 03.05.08 is excluded from technical evidence pulls (no screenshots, logs, config exports tied to it).
• 03.05.08 is included in governance evidence pulls (proof that you manage withdrawn items correctly).

If you use a platform like Daydream to manage requirement mapping and evidence routines, create a “Withdrawn requirements” collection task that automatically attaches the control matrix row, SSP excerpt, and change record for the period.

Deliverable: Evidence collection checklist entry for “withdrawn requirement governance.”

Step 5: Communicate the withdrawal to internal and external stakeholders

Send a short notice to:

• Control owners: “03.05.08 is withdrawn in Rev. 3; stop tracking it as a standalone requirement.”
• Internal audit: “Testing scope updated; see crosswalk log.”
• Key third parties (if you flowed this down by number): “Our baseline is Rev. 3; 03.05.08 is withdrawn; updated exhibit attached.”

Deliverable: Email/memo with attachment of updated matrix excerpt.

Required evidence and artifacts to retain

Auditors cannot “test” a withdrawn requirement, but they can test your governance. Keep:

1. SSP excerpt showing baseline is NIST SP 800-171 Rev. 3 and the treatment of 03.05.08 as withdrawn ¹.
2. Control matrix / requirement register row for 03.05.08 marked “Withdrawn” with reviewer/approver and date.
3. Change control record (ticket, PR, or document revision history) showing when you updated references.
4. Withdrawn requirements disposition log (one line is enough if nothing else referenced it).
5. Third-party communication artifacts if any contract/security exhibit previously referenced 03.05.08 by number.
6. Assessment scope statement showing it is out of test scope because it is withdrawn ¹.

Common exam/audit questions and hangups

Expect these, and have crisp answers:

• “Why is 03.05.08 missing from your implementation?”
  Answer with the citation and show the matrix row labeled withdrawn ¹.

• “Show me how you manage changes between revisions.”
  Provide the disposition log and change control tickets.

• “Do you still perform the activity that used to satisfy 03.05.08?”
  Be explicit: either mapped to another current requirement, retained as internal control, or retired with risk sign-off.

• “Your policy references 03.05.08; why?”
  This is a common finding. Fix the reference and show document revision history.

Frequent implementation mistakes and how to avoid them

1. Marking withdrawn as “Compliant.”
   Avoidance: Use a distinct status value (“Withdrawn”) and train assessors internally on what it means.

2. Leaving POA&M items open for 03.05.08.
   Avoidance: Close or re-scope the item with a rationale note and mapping to current requirements where applicable.

3. Continuing to request evidence from system teams for a non-existent requirement.
   Avoidance: Update the evidence calendar and remove automated evidence requests tied to 03.05.08.

4. Breaking third-party flowdowns.
   Avoidance: Update contract exhibits and security schedules to cite the baseline (NIST SP 800-171 Rev. 3) rather than a static list of numbers ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement. Practically, the risk is indirect:

• Misrepresentation risk: Claiming compliance to requirements that do not exist in the current baseline can undermine credibility in customer reviews and assessments.
• Assessment friction: Withdrawn items create avoidable back-and-forth if your documentation is not explicit.
• Control bloat: Teams waste time maintaining “ghost controls,” which crowds out attention from active Rev. 3 requirements ¹.

Practical 30/60/90-day execution plan

Use phased execution without anchoring to hard calendar promises.

First 30 days (stabilize documentation)

• Update SSP/control matrix to mark 03.05.08: withdrawn requirement as withdrawn ¹.
• Run an enterprise search for “03.05.08” and log every occurrence.
• Create the withdrawn requirements disposition log and route for approval.

Next 60 days (clean up the ecosystem)

• Remediate policy/procedure references and publish revisions.
• Close or re-scope any open POA&M items tied to 03.05.08.
• Update third-party templates and contract exhibits that cite requirement numbers.

By 90 days (make it repeatable)

• Add a recurring “baseline maintenance” control activity: monitor NIST SP 800-171 Rev. 3 updates and reconcile your matrix ¹.
• Bake withdrawn handling into your internal audit test plan: verify withdrawn items are consistently labeled and excluded from technical testing.
• In Daydream (or your GRC system), standardize a “Withdrawn requirement” workflow: status, required artifacts, approval, and evidence attachment.

Frequently Asked Questions

If 03.05.08 is withdrawn, can I ignore it completely?

You can ignore it as a technical control, but you still need to document that it is withdrawn in your Rev. 3 baseline and show traceability in your SSP/control matrix ¹.

Should I keep the legacy control we built for 03.05.08?

Keep it only if it supports a current Rev. 3 requirement or if you choose to retain it as an internal control for risk reasons. Otherwise, retire it with documented approval and remove the outdated citation.

What status should I use in my control matrix for 03.05.08?

Use “Withdrawn” (or “Not applicable (withdrawn)”) and include a note pointing to NIST SP 800-171 Rev. 3 as the basis ¹. Avoid labeling it “Compliant.”

Our customer questionnaire still asks about 03.05.08. What do we answer?

Respond that 03.05.08 is withdrawn in NIST SP 800-171 Rev. 3 and attach the relevant SSP/control matrix excerpt showing how you treat it ¹.

How do I show evidence for a withdrawn requirement during an audit?

Provide governance artifacts: the updated control matrix row, SSP excerpt, and change control record showing you recognized the withdrawal and updated scope ¹.

Does a withdrawn requirement affect third-party due diligence scope?

Yes, in the sense that your third-party questionnaires and flowdowns should reference the correct baseline and not demand evidence for withdrawn items. Update templates so third parties are assessed against active Rev. 3 requirements ¹.

Footnotes

1. NIST SP 800-171 Rev. 3