03.01.13: Withdrawn

A withdrawn requirement creates a predictable audit failure mode: your program either (a) claims coverage for a control that no longer exists, which signals weak change control, or (b) shows an “unmet requirement” in a GRC tool, which triggers a preventable finding and distracts from real risk.

For NIST SP 800-171 Rev. 3, requirement 03.01.13 is explicitly marked “Withdrawn.” (NIST SP 800-171 Rev. 3) That means assessors should not expect a technical or procedural safeguard mapped to 03.01.13 as a separate requirement. What they will expect is discipline: your System Security Plan (SSP) and requirement crosswalk reflect the current version, your POA&M doesn’t carry zombie items, and you can explain how you manage changes between revisions without breaking compliance reporting.

This page gives requirement-level implementation guidance for a CCO/GRC lead: who needs to care, what to update, what evidence to retain, how to answer auditor questions, and how to keep third-party and customer-driven assessment templates from reintroducing the withdrawn item.

Regulatory text

Excerpt: “NIST SP 800-171 Rev. 3 requirement 03.01.13 (Withdrawn).” (NIST SP 800-171 Rev. 3)

Operator interpretation

Because 03.01.13 is withdrawn, the operator action is not “deploy a control.” The operator action is to treat the withdrawal as a controlled change in your compliance baseline:

• Your SSP must reflect that 03.01.13 has no implementation statement because it is withdrawn. (NIST SP 800-171 Rev. 3)
• Your control crosswalk (NIST-to-internal controls, NIST-to-CSF/ISO mappings, customer mappings) must not create an orphan requirement or a fake gap. (NIST SP 800-171 Rev. 3)
• Your POA&M must not carry remediation tasks for a requirement that no longer exists in the current baseline, unless a contract explicitly requires the legacy behavior. (NIST SP 800-171 Rev. 3)
• Your assessment procedures (internal test plans, evidence checklists, scripts) must explicitly mark 03.01.13 as withdrawn so testers don’t hunt for evidence that cannot exist. (NIST SP 800-171 Rev. 3)

Practical rule: withdrawn requirements still require work, but the work is program governance, documentation accuracy, and downstream dependency management.

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

• No standalone compliance obligation exists for 03.01.13 in Rev. 3. (NIST SP 800-171 Rev. 3)
• You must not present it as implemented as though it were an active requirement. (NIST SP 800-171 Rev. 3)
• You must show version-aware governance so an assessor sees intentional baseline management rather than a mapping error. (NIST SP 800-171 Rev. 3)

Who it applies to

This affects any organization that uses NIST SP 800-171 Rev. 3 as a compliance baseline for protecting Controlled Unclassified Information (CUI) in nonfederal systems, including:

• Defense contractors and subcontractors handling CUI in corporate or program environments. (NIST SP 800-171 Rev. 3)
• Federal contractors where customer terms flow down NIST SP 800-171 expectations. (NIST SP 800-171 Rev. 3)
• Nonfederal organizations handling CUI under agreements or data-sharing arrangements that point to NIST SP 800-171. (NIST SP 800-171 Rev. 3)

Operational contexts where this shows up immediately:

• You run a GRC control library with requirement IDs.
• You maintain an SSP/POA&M set for an enclave, tenant, or boundary.
• You respond to customer security questionnaires or prime contractor scorecards that cite requirement numbers.

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

1) Confirm your baseline and scope

1. Identify which systems/enclaves are declared in-scope for NIST SP 800-171 Rev. 3 in the SSP. (NIST SP 800-171 Rev. 3)
2. Confirm that your requirement library is actually using Rev. 3 requirement identifiers and text references. (NIST SP 800-171 Rev. 3)

Output: a baseline statement: “NIST SP 800-171 Rev. 3 is the governing requirement set for this boundary.” (NIST SP 800-171 Rev. 3)

2) Update SSP mappings to show 03.01.13 is withdrawn

1. In your SSP control mapping table, add an entry for 03.01.13 with status “Withdrawn (no implementation required).” (NIST SP 800-171 Rev. 3)
2. Add a short rationale note: “Withdrawn in NIST SP 800-171 Rev. 3; not assessed as a requirement.” (NIST SP 800-171 Rev. 3)
3. If your SSP format requires a control narrative, include: “Not applicable due to withdrawal; see baseline management record.” (NIST SP 800-171 Rev. 3)

Operator tip: This is where assessors look first. A clean SSP entry prevents “missing control” churn.

3) Fix your GRC tooling so it doesn’t generate a false gap

1. In your control library, set 03.01.13 to a state that does not count as noncompliance (examples: “withdrawn,” “retired,” “superseded”), according to your tool’s taxonomy. (NIST SP 800-171 Rev. 3)
2. Ensure dashboards and compliance scoring exclude withdrawn items from denominator calculations for Rev. 3 reporting. (NIST SP 800-171 Rev. 3)
3. Add a link or note pointing to the Rev. 3 text reference for audit traceability. (NIST SP 800-171 Rev. 3)

If you use Daydream: record 03.01.13 as withdrawn, tie it to the SSP entry, and attach the “baseline decision” artifact so the withdrawn status is provable during evidence collection. (NIST SP 800-171 Rev. 3)

4) Clean up POA&M items and legacy remediation work

1. Search POA&M for “03.01.13” and any legacy control names that mapped to it in older internal crosswalks. (NIST SP 800-171 Rev. 3)
2. For each item found, choose one disposition:
   • Close as withdrawn (with rationale and approval). (NIST SP 800-171 Rev. 3)
   • Convert to another active requirement if the underlying risk/control objective still exists elsewhere in your current baseline. Document the new mapping. (NIST SP 800-171 Rev. 3)
   • Keep as contractual if a customer contract, prime flowdown, or internal policy still requires it. Document the authority and treat it as “beyond NIST baseline.” (NIST SP 800-171 Rev. 3)
3. Validate closure evidence before marking complete (closure memo, review ticket, updated SSP mapping). (NIST SP 800-171 Rev. 3)

5) Update assessment scripts, evidence checklists, and auditor-facing narratives

1. In test procedures, mark 03.01.13 as “withdrawn; no test.” (NIST SP 800-171 Rev. 3)
2. Add a standard auditor response in your assessment binder: “03.01.13 is withdrawn in Rev. 3; excluded from testing; see SSP mapping and baseline management record.” (NIST SP 800-171 Rev. 3)

6) Validate third-party and customer artifacts that may reintroduce the requirement

1. Review customer security requirement matrices, prime contractor scorecards, and third-party due diligence questionnaires for mention of 03.01.13. (NIST SP 800-171 Rev. 3)
2. Where it appears, respond with: “Withdrawn in NIST SP 800-171 Rev. 3; we manage via baseline governance; available evidence attached.” (NIST SP 800-171 Rev. 3)

Required evidence and artifacts to retain

Keep these artifacts together (single folder or GRC evidence object) to make audits fast:

• SSP excerpt showing 03.01.13 listed as withdrawn with rationale. (NIST SP 800-171 Rev. 3)
• Baseline management record (change log entry, governance memo, or ticket) approving the withdrawn status and date applied. (NIST SP 800-171 Rev. 3)
• Control crosswalk export demonstrating 03.01.13 does not map to an internal control as an active requirement. (NIST SP 800-171 Rev. 3)
• POA&M closure records for any legacy 03.01.13 items, with disposition and approver. (NIST SP 800-171 Rev. 3)
• Assessment procedure page marking “no test; withdrawn” and showing version reference. (NIST SP 800-171 Rev. 3)

Common exam/audit questions and hangups

Auditor question	What they are testing	Strong operator answer	Evidence
“Why is 03.01.13 missing?”	Baseline accuracy	“It is withdrawn in Rev. 3; we track it as withdrawn to prevent false gaps.” (NIST SP 800-171 Rev. 3)	SSP excerpt; baseline record
“Show me your control for 03.01.13.”	Mapping discipline	“No standalone control exists for withdrawn requirements; here is our mapping and exclusion from testing.” (NIST SP 800-171 Rev. 3)	Crosswalk; test plan
“Why does your tool show it as noncompliant?”	Tool governance	“Configuration issue fixed; withdrawn requirements are excluded from scoring; here is the updated report.” (NIST SP 800-171 Rev. 3)	Screenshot/export; change ticket
“Did you close POA&M items correctly?”	Remediation governance	“We closed/converted legacy items with approval and retained rationale.” (NIST SP 800-171 Rev. 3)	POA&M history; approvals

Frequent implementation mistakes (and how to avoid them)

1. Leaving 03.01.13 as ‘Not Implemented.’
   Fix: mark it withdrawn and exclude from scoring and testing. Retain a baseline record. (NIST SP 800-171 Rev. 3)

2. Deleting it everywhere.
   Fix: keep a placeholder entry labeled “withdrawn” so assessors see intentional handling, not an omission. (NIST SP 800-171 Rev. 3)

3. Closing POA&M without documenting why.
   Fix: add a closure rationale that cites withdrawal and record an approver. (NIST SP 800-171 Rev. 3)

4. Failing to reconcile customer/prime matrices.
   Fix: maintain a standard response packet and attach the SSP excerpt when questioned. (NIST SP 800-171 Rev. 3)

Risk implications (why you should treat this as more than cleanup)

Withdrawn requirements commonly create:

• False negatives (dashboard shows a gap that isn’t real), which diverts remediation capacity away from active CUI risks. (NIST SP 800-171 Rev. 3)
• False positives (claiming implementation for a non-existent requirement), which undermines assessor confidence in your SSP accuracy and control ownership discipline. (NIST SP 800-171 Rev. 3)
• Contract misalignment if a third party (prime, customer, assessor) still expects an older mapping, which turns into prolonged clarification cycles during audits. (NIST SP 800-171 Rev. 3)

Practical 30/60/90-day execution plan

First 30 days (triage and baseline integrity)

• Confirm Rev. 3 baseline and list all in-scope SSPs and crosswalks. (NIST SP 800-171 Rev. 3)
• Update SSP entry for 03.01.13 to “Withdrawn” and publish SSP revision. (NIST SP 800-171 Rev. 3)
• Configure GRC/control library status so 03.01.13 does not count as a deficiency. (NIST SP 800-171 Rev. 3)
• Open a single change ticket that links SSP, tool configuration, and testing procedure updates. (NIST SP 800-171 Rev. 3)

Next 60 days (downstream dependency cleanup)

• Review POA&M for legacy items and close/convert with approvals. (NIST SP 800-171 Rev. 3)
• Update assessment scripts and evidence checklists; publish an assessor note. (NIST SP 800-171 Rev. 3)
• Reconcile customer/prime requirement matrices that reference 03.01.13; store response language. (NIST SP 800-171 Rev. 3)

By 90 days (operationalize and prevent recurrence)

• Add a baseline-change step to your compliance change management process: “identify withdrawn/superseded requirements and update mappings.” (NIST SP 800-171 Rev. 3)
• Schedule periodic control library hygiene reviews aligned to SSP maintenance events. (NIST SP 800-171 Rev. 3)
• In Daydream or your GRC, create a recurring evidence task to confirm withdrawn requirements remain excluded from scoring and testing after tool updates. (NIST SP 800-171 Rev. 3)

Frequently Asked Questions

If 03.01.13 is withdrawn, do we mark it “Not Applicable” or “Withdrawn”?

Prefer “Withdrawn” because it preserves the reason and ties directly to the framework language. If your tool only supports “Not Applicable,” add a note stating it is withdrawn in Rev. 3. (NIST SP 800-171 Rev. 3)

Will assessors expect evidence for 03.01.13 anyway?

They should not expect a control test for a withdrawn requirement, but they will expect your SSP and test plan to show you handled it deliberately. Keep the SSP entry and baseline-change record ready. (NIST SP 800-171 Rev. 3)

We have an older customer matrix referencing 03.01.13. What do we do?

Treat it as a contract alignment issue, not a control gap. Provide written clarification that 03.01.13 is withdrawn in Rev. 3 and attach your SSP excerpt showing the withdrawn status. (NIST SP 800-171 Rev. 3)

Should we remove 03.01.13 from our SSP entirely?

Don’t remove it if removal will look like an omission. Keep it listed as withdrawn so your SSP reads as a complete, version-aware mapping. (NIST SP 800-171 Rev. 3)

How do we handle a POA&M item created for 03.01.13 last year?

Close it as withdrawn if it only exists to satisfy 03.01.13, or convert it to the correct active requirement if it addresses a real control objective still needed. Document the decision and approval either way. (NIST SP 800-171 Rev. 3)

What’s the cleanest way to show this in a GRC platform like Daydream?

Keep 03.01.13 as a requirement record marked withdrawn, link it to the SSP section, and attach the baseline-change ticket/memo. That creates a single audit trail and prevents scoring engines from flagging a non-issue. (NIST SP 800-171 Rev. 3)