03.10.05: Withdrawn

NIST SP 800-171 Rev. 3 requirement 03.10.05 is withdrawn, so you do not implement a standalone control for it. You must still operationalize this requirement in practice by documenting that it is withdrawn, mapping any related coverage to other applicable requirements, and keeping your SSP/POA&M coherent so assessors don’t treat “withdrawn” as a missing control. ¹

Key takeaways:

• Treat 03.10.05 as a documentation and mapping task, not an engineering buildout. ¹
• Prevent audit findings by showing explicit SSP traceability: “withdrawn” status, rationale, and where the intent is covered elsewhere (if applicable). ¹
• Your real exposure is assessment confusion: ambiguous SSP/POA&M entries, stale crosswalks, and “TBD” language that looks like a gap. ²

A withdrawn requirement creates a predictable failure mode in audits: the control library still lists the item, the SSP shows “planned” or “not implemented,” and an assessor flags it as a deficiency because the traceability story is unclear. For NIST SP 800-171 Rev. 3 requirement 03.10.05, the operative fact is simple: it is withdrawn. ¹

Your job is to translate “withdrawn” into operational clarity. That means your system security plan (SSP), control matrix, and assessment artifacts must reflect three things consistently: (1) the requirement is withdrawn in the source standard, (2) you are not claiming an implementation that no longer exists, and (3) any related security objective is addressed through other requirements or through your organization’s baseline controls, as appropriate. ¹

This page gives you requirement-level guidance to close the loop quickly: who owns the work, what to change in documentation, what evidence to retain, and what auditors typically ask when they see “withdrawn” in a control set. References for assessment alignment come from NIST SP 800-171A. ²

Regulatory text

Excerpt (framework text): “NIST SP 800-171 Rev. 3 requirement 03.10.05 (Withdrawn).” ¹

Operator interpretation (what you must do)

Because 03.10.05 is withdrawn, there is no enforceable requirement statement to implement under that identifier within NIST SP 800-171 Rev. 3. Your operational obligation shifts to governance: keep your compliance mapping accurate, prevent orphaned control references, and maintain assessor-ready documentation that explains why there is no implementation activity tied to 03.10.05. ¹

In practice, treat “withdrawn” as a controlled exception entry in your SSP/control matrix:

• Status: Withdrawn (N/A)
• Basis: Withdrawn per NIST SP 800-171 Rev. 3
• Coverage: Cross-reference to the requirement(s) that now cover similar intent, or state “No replacement in Rev. 3; not applicable as a standalone requirement,” depending on your internal control architecture. ¹

Plain-English requirement meaning (for CCO/GRC leads)

“Withdrawn” means the standard’s authors removed this specific requirement from the active set in Rev. 3. You are not expected to design, implement, test, or produce operational evidence for 03.10.05 as if it were active. You are expected to keep your compliance program internally consistent so an assessor can trace your control set to the current revision without guessing. ¹

If you support federal work or handle CUI, the practical goal is to avoid two outcomes:

1. A false “gap” in your SSP/POA&M because a withdrawn item is mis-tracked as unimplemented.
2. A credibility hit because your documentation looks copied forward without governance review. ²

Who it applies to

Entities

• Federal contractors and subcontractors implementing NIST SP 800-171 for Controlled Unclassified Information (CUI) in nonfederal systems. ¹

Operational context

• GRC teams maintaining the SSP, control crosswalks, and POA&M for environments that store, process, or transmit CUI.
• Security teams asked to “implement the requirement” must be redirected to documentation hygiene and cross-mapping work, not technical changes. ¹

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

Step 1: Confirm the withdrawn status in your control library

• Update your master control catalog entry for 03.10.05 to: Withdrawn.
• Add a short note: “Withdrawn in NIST SP 800-171 Rev. 3; no standalone implementation required.” ¹

Owner: GRC/control owner (not an engineer).
Tooling tip: In Daydream, implement this as a control status plus a mapped “withdrawn rationale” field so it stays consistent across SSP exports and auditor packets.

Step 2: Fix SSP traceability (the assessor view)

In your SSP, create a control statement entry that is explicit and closed:

• Control identifier: 03.10.05
• Implementation: “Withdrawn”
• Implementation details: “N/A—withdrawn requirement in Rev. 3”
• Inheritance/coverage: link to any related controls you maintain that address similar objectives, if your internal model requires it. ¹

What assessors look for: clarity and lack of ambiguity. NIST SP 800-171A-style assessment activities depend on what you claim in the SSP. If the SSP implies the control exists but is “planned,” you create a test expectation that you cannot satisfy. ²

Step 3: Clean up POA&M entries so “withdrawn” does not look like a gap

Search your POA&M for:

• “03.10.05”
• “3.10.5”
• “10.05”
• Any legacy control name you previously associated with this requirement

Then:

• Close any open items tied solely to 03.10.05 as Not Applicable (Withdrawn).
• Preserve an audit trail note referencing the withdrawn status and the decision rationale. ¹

If the POA&M item represented a real weakness (independent of 03.10.05), re-home it under the correct active requirement(s) or under an internal control objective so remediation continues without losing accountability. ²

Step 4: Update crosswalks and third-party flowdowns (where relevant)

Withdrawn controls often persist in:

• customer security questionnaires,
• contract exhibits,
• third-party security addenda,
• internal control matrices used for bids.

Actions:

• Update your NIST crosswalk to show 03.10.05 as withdrawn and ensure downstream mappings do not require evidence.
• If a customer document still references 03.10.05, respond with: “Withdrawn in NIST SP 800-171 Rev. 3,” plus your mapping note to current controls if asked. ¹

Step 5: Build a lightweight “withdrawn requirements” governance rule

Put a simple rule into your compliance change management:

• Any “withdrawn” requirement triggers SSP update, POA&M cleanup, and crosswalk refresh.
• Review and approve the change (GRC + system owner) so the record is defensible. ²

Required evidence and artifacts to retain

Keep these in your audit binder (or Daydream evidence locker) so you can answer questions in minutes:

1. SSP excerpt showing 03.10.05 marked withdrawn with narrative rationale. ¹
2. Control matrix / crosswalk extract showing “Withdrawn” status and any successor mapping decisions. ¹
3. POA&M change log showing closure or re-mapping of any 03.10.05 items, with approver and date. ²
4. Change management record (ticket or memo) documenting the update and who approved it. ²
5. Assessor-ready explanation (one-page) summarizing: “Withdrawn; no test steps; evidence is the documentation alignment.” ¹

Common exam/audit questions and hangups

What they ask	What they mean	What to show
“Why is 03.10.05 not implemented?”	They think it’s an active requirement	SSP entry explicitly stating “Withdrawn” with citation to the standard 1
“Do you have evidence for 03.10.05?”	They expect test artifacts	Evidence is documentation control: SSP/control matrix + POA&M cleanup 2
“Where did the intent go?”	They worry a security objective was dropped	Crosswalk note to other active requirements or internal control objectives, with clear boundaries 1
“Why is it still in your POA&M?”	They see governance drift	POA&M closure record or re-homed remediation item 2

Frequent implementation mistakes (and how to avoid them)

1. Marking it ‘Not Implemented’ instead of ‘Withdrawn.’
   Fix: Use “Withdrawn (N/A)” language. “Not implemented” implies a deficiency. ¹

2. Leaving legacy SSP text from prior revisions.
   Fix: Add a revision hygiene checkpoint: if requirement status changes, SSP narrative changes too. ²

3. Closing a POA&M item that represented a real risk.
   Fix: If the gap is real, re-map it to the correct active requirement or internal control objective; don’t bury it under “withdrawn.” ²

4. Inconsistent answers across teams.
   Fix: Publish a short internal FAQ: “03.10.05 is withdrawn; do not engineer a control; route questions to GRC.” ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source set for this requirement. Your risk here is indirect: inaccurate SSP/POA&M traceability can drive negative assessment outcomes, rework, and credibility issues with customers and assessors who expect alignment to NIST SP 800-171 Rev. 3 and assessment-ready artifacts aligned with NIST SP 800-171A. ^{1 2}

Practical 30/60/90-day execution plan

First 30 days (stabilize documentation)

• Update control library entry to “Withdrawn (N/A)” and add the citation reference in the control note. ¹
• Update SSP control statement for 03.10.05.
• Search and remediate POA&M references; close or re-map with approvals. ²

By 60 days (eliminate downstream confusion)

• Refresh crosswalks used for bids, customer questionnaires, and internal audits to reflect withdrawn status. ¹
• Add a standard response snippet for customer inquiries about 03.10.05 and store it with your assessment packet.

By 90 days (make it repeatable)

• Add a “framework revision change” SOP step: withdrawn/added/modified requirements trigger SSP + POA&M + crosswalk updates.
• In Daydream, set a recurring compliance review task that flags withdrawn requirements and checks for stray POA&M entries before assessments.

Frequently Asked Questions

If 03.10.05 is withdrawn, can I ignore it completely?

You can ignore it as a technical implementation requirement, but you can’t ignore it in your documentation if it appears in your control set. Mark it withdrawn in the SSP/control matrix so assessors don’t interpret it as a gap. ¹

What evidence do I provide for a withdrawn requirement?

Provide governance evidence: the SSP entry showing “Withdrawn (N/A),” your updated crosswalk, and POA&M cleanup records. That matches how assessors evaluate what you claim and how you manage exceptions. ²

Should 03.10.05 appear in the SSP at all?

If your SSP is structured to track the full requirement list, keep it with an explicit “Withdrawn” status. If your SSP only lists applicable requirements, document your inclusion/exclusion rule and ensure consistency across artifacts. ¹

A customer contract still references 03.10.05. What do I do?

Respond with the withdrawn status in NIST SP 800-171 Rev. 3 and offer a mapping note to current controls if the customer wants equivalent coverage language. Keep the exchange as part of your compliance record. ¹

Can I keep a POA&M item open under 03.10.05 for tracking convenience?

Avoid it. A POA&M item tied to a withdrawn identifier confuses assessments and weakens traceability. Re-map the task to the active requirement(s) or internal control objective that actually governs the fix. ²

How do I prevent “withdrawn” requirements from turning into audit findings later?

Put a governance check in your framework update process: any withdrawn control triggers SSP update, POA&M search/cleanup, and crosswalk refresh, with an approval record. Then you can answer assessor questions with one consistent packet. ²

Footnotes

1. NIST SP 800-171 Rev. 3

2. NIST SP 800-171A