03.13.05: Withdrawn

A withdrawn control creates a specific kind of compliance risk: not security risk from a missing safeguard, but assessment risk from confusion, stale crosswalks, and inconsistent documentation. For a Compliance Officer, CCO, or GRC lead, the goal is simple: make sure 03.13.05 does not appear as an unaddressed requirement in your System Security Plan (SSP), control implementation statements, control testing, or POA&M workflows.

NIST SP 800-171 Rev. 3 lists 03.13.05 as “Withdrawn,” which means there is no active requirement text to implement under that identifier. ¹ Your job is to translate that into operational reality across your compliance stack: policies, control catalogs, assessment procedures, evidence collection, and third-party flows where you pass down CUI protection obligations.

This page gives requirement-level implementation guidance for quickly operationalizing the 03.13.05: withdrawn requirement status: who it applies to, what to document, how to keep auditors aligned, and what artifacts to retain so your team does not waste cycles remediating something that no longer exists. ¹

Regulatory text

Excerpt (as provided): “NIST SP 800-171 Rev. 3 requirement 03.13.05 (Withdrawn).” ¹

Operator interpretation of the regulatory text

Because 03.13.05 is explicitly labeled Withdrawn, there is no control objective to satisfy under that requirement number in Rev. 3. ¹ The operational requirement becomes:

1. Do not implement “phantom controls.” Don’t create a new safeguard solely to “cover” 03.13.05.
2. Do implement governance around the withdrawal. Ensure your compliance documentation and assessment scope reflect that 03.13.05 is not applicable because it is withdrawn.
3. Do preserve traceability. Maintain crosswalk evidence that you track revisions and reconcile differences so assessors can verify you’re aligned to Rev. 3 and not an older internal control list. ¹

This is a documentation, traceability, and assessment-readiness requirement, not a technical build.

Plain-English interpretation (what this means in practice)

• If your SSP/control matrix lists 03.13.05 as “planned,” “partial,” or “not implemented,” you are creating a self-inflicted finding.
• If your internal testing plan includes 03.13.05 steps, your team will burn time collecting evidence that has no assessment value.
• If a customer, prime contractor, or third party questionnaire asks about 03.13.05, you need a consistent, repeatable response: “Withdrawn in NIST SP 800-171 Rev. 3; mapped as not applicable (withdrawn).” ¹

Who it applies to (entity and operational context)

This guidance applies when you are aligning to NIST SP 800-171 Rev. 3 for nonfederal systems handling CUI and federal contractors operating those systems. ¹

Operationally, it matters most for teams that maintain:

• An SSP and supporting policies/procedures for CUI environments
• A control implementation matrix or GRC control catalog mapped to NIST SP 800-171
• An internal audit/testing program for 800-171 alignment
• A POA&M workflow used to track remediation items
• Third-party requirements flow-down for suppliers or service providers touching CUI (even if indirectly)

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

1) Find every place 03.13.05 appears

Create a quick inventory of references across:

• SSP and any SSP appendices/control implementation statements
• Control matrix (spreadsheet, GRC tool, or compliance repository)
• Testing plans and test scripts
• POA&M items (open, closed, or templated)
• Policies/standards if they cite control numbers
• Third-party security exhibits and contract templates that list specific 800-171 controls

Deliverable: a “03.13.05 reference list” with system/document name, location, owner, and proposed update.

2) Update your control mapping to reflect “Withdrawn”

In your control matrix, set 03.13.05 to a standardized status such as:

• Not applicable – Withdrawn in Rev. 3
  Add a short rationale field: “Requirement withdrawn in NIST SP 800-171 Rev. 3; no implementation required under this identifier.” ¹

If your GRC tooling forces an implementation statement, keep it factual and brief. Avoid inventing “compensating controls” unless another active requirement needs them.

3) Ensure no downstream workflow treats it as a gap

• Remove 03.13.05 from recurring evidence requests.
• Remove it from automated control tests.
• Add a POA&M guardrail: any imported checklist item for 03.13.05 should auto-resolve as “withdrawn,” not “open.”

Practical tip: if you import third-party assessment templates, add a normalization layer that translates older lists into Rev. 3 status. This is where teams get tripped up.

4) Build a Rev. 2 → Rev. 3 reconciliation note (assessor-ready)

Assessors and customers commonly work from older mappings. Your job is to make the mismatch boring:

• Add a short section in the SSP “Control framework versioning and exceptions”
• List withdrawn requirements (including 03.13.05) with a one-line explanation
• Point to the NIST SP 800-171 Rev. 3 source as authority ¹

5) Train the people who answer questionnaires

Give Procurement, Security, and Sales/BD a standard response snippet for the 03.13.05: withdrawn requirement question. Consistency prevents accidental commitments.

6) Make it repeatable (change control)

Add “framework change review” to your governance cadence:

• Monitor updates to NIST SP 800-171 Rev. 3 postings and your internal mapping set. ¹
• Require that any control list update records: date, approver, and summary of changes (e.g., withdrawn items, renumbered items, new items).

If you use Daydream, treat this as a mapped requirement record with recurring evidence limited to “withdrawn status confirmed + mapping remains correct,” rather than technical evidence collection. Daydream’s value here is preventing withdrawn items from reappearing as open gaps when you refresh mappings or import customer control lists.

Required evidence and artifacts to retain

You’re proving governance and traceability. Keep these artifacts in your audit repository:

1. Control matrix extract showing 03.13.05 marked “Not applicable – Withdrawn in Rev. 3,” with rationale.
2. SSP excerpt documenting the withdrawn status and your version alignment to Rev. 3. ¹
3. Change record (ticket, pull request, or GRC change log) showing who approved the mapping update and when.
4. Retired test procedure list or screenshot showing 03.13.05 removed from testing/evidence requests.
5. Questionnaire response guidance (internal KB article or playbook snippet) for 03.13.05 inquiries.

Common exam/audit questions and hangups

Auditors and customer assessors tend to get stuck in predictable places:

• “Where is the implementation evidence for 03.13.05?”
  Answer: it is withdrawn in Rev. 3; provide SSP/control matrix rationale and the citation. ¹

• “Your POA&M shows 03.13.05 open. Why?”
  Root cause is usually template imports. Fix the workflow so withdrawn requirements cannot open new remediation items.

• “Which control replaced 03.13.05?”
  Do not guess. If you haven’t done a formal crosswalk, state only what you can support: 03.13.05 is withdrawn in Rev. 3. ¹ Then point to your broader Rev. 3 control coverage approach.

• “Are you sure you’re assessing against Rev. 3?”
  Show your version statement in the SSP and your revision-controlled mapping.

Frequent implementation mistakes (and how to avoid them)

1. Marking 03.13.05 as “Not implemented” instead of “Withdrawn.”
   Fix: standardize statuses and lock the dropdown values in your control matrix.

2. Creating a compensating control narrative to “cover” it.
   Fix: only create controls for active requirements. Withdrawn means no requirement to satisfy under that ID. ¹

3. Letting third-party templates create fake findings.
   Fix: add an intake rule: any checklist line for 03.13.05 maps to “withdrawn” automatically.

4. Forgetting to update evidence automation.
   Fix: re-run your evidence collection schedule after control list edits and confirm 03.13.05 is not in the queue.

Enforcement context and risk implications

No public enforcement cases specific to 03.13.05 were provided in the source catalog for this requirement, and NIST SP 800-171 itself is a standard used in contractual and programmatic contexts rather than a penalty schedule. ¹

Your real risk is operational:

• Assessment failure risk: an assessor flags “missing control” due to stale control lists.
• Contractual friction: a prime or customer sees an “open item” and escalates.
• Program integrity risk: your governance appears sloppy if you cannot explain why a requirement is withdrawn and how you manage revisions.

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleed)

• Identify every reference to 03.13.05 across SSP, matrices, tests, and POA&M.
• Update mappings to “Not applicable – Withdrawn in Rev. 3” with consistent rationale. ¹
• Remove 03.13.05 from evidence requests and test scripts.

Next 60 days (make it assessor-proof)

• Add an SSP section for framework versioning and withdrawn requirements, including 03.13.05. ¹
• Implement workflow guardrails so imported templates cannot open POA&M items for withdrawn requirements.
• Publish a standard questionnaire response for 03.13.05: withdrawn requirement.

By 90 days (make it repeatable)

• Formalize a framework change control process with approval and version tracking.
• Add a periodic review of the control mapping against the NIST SP 800-171 Rev. 3 source and landing page. ¹
• If you manage many customer/prime questionnaires, centralize responses in a controlled repository (Daydream or equivalent) so “withdrawn” stays consistent across teams.

Frequently Asked Questions

If 03.13.05 is withdrawn, do we need to do anything at all?

Yes. You need to document that it is withdrawn, update your control mapping status, and ensure no audit/testing workflow treats it as an open gap. ¹

Should 03.13.05 appear in our SSP?

It can appear as a line item marked “Not applicable – Withdrawn in Rev. 3” if your SSP template includes a full control list. Keep the rationale short and factual. ¹

Our customer checklist still includes 03.13.05. How should we respond?

Respond with a consistent statement that 03.13.05 is withdrawn in NIST SP 800-171 Rev. 3 and is therefore not applicable under that identifier. Attach or reference your SSP/control matrix excerpt if needed. ¹

Do we need a compensating control for a withdrawn requirement?

No, not for the withdrawn identifier itself. If you identify a real security gap, address it under the relevant active requirement or your internal control objectives.

Can we close an existing POA&M item tied to 03.13.05?

If the only driver is the withdrawn requirement reference, you can close it as “not applicable (withdrawn)” and retain the evidence showing the basis for closure and approval. ¹

How do we prevent withdrawn controls from resurfacing during future assessments?

Put a normalization step into template imports and maintain revision-controlled mappings with an approval trail. Tools like Daydream help by keeping a single source of truth for mappings and recurring evidence expectations.

Footnotes

1. NIST SP 800-171 Rev. 3