03.13.14: Withdrawn

A withdrawn requirement creates a specific kind of compliance risk: teams keep “passing” internal checklists for something that no longer exists, while assessors see outdated scoping, mismapped controls, and stale SSP/POA&M content. For NIST SP 800-171 Rev. 3 requirement 03.13.14, the correct response is administrative rigor. You need to show that your program recognizes the withdrawal, that you updated your documentation and mappings accordingly, and that nothing in your CUI environment depends on a phantom requirement for risk acceptance or control completeness. ¹

This page is written for a Compliance Officer, CCO, or GRC lead who has to operationalize the 03.13.14: withdrawn requirement quickly. The work is straightforward but easy to do sloppily: a note in a spreadsheet is not enough if your SSP narrative, control owners, and audit evidence still reference the withdrawn item. Your goal is clean lineage from NIST SP 800-171 Rev. 3 to your control statements, system scope, evidence collection, and remediation governance. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.13.14 (Withdrawn).” ¹

Operator interpretation (what you must do)

Because the requirement is explicitly withdrawn, the operator obligation is not to “implement 03.13.14.” The obligation is to:

1. Record that 03.13.14 is withdrawn in your control library and compliance mappings.
2. Ensure no policies, procedures, SSP content, or assessment workpapers treat 03.13.14 as an active requirement.
3. Crosswalk legacy mappings (Rev. 2 artifacts, old customer questionnaires, inherited templates) to the current Rev. 3 requirement set so your compliance posture is not misstated. ¹

This is still auditable work. Assessors routinely test whether your SSP and evidence set are current, internally consistent, and mapped to the correct requirement identifiers. ¹

Plain-English interpretation of the requirement

“Withdrawn” means NIST removed this requirement from the operative set in Rev. 3. You should not spend engineering effort to build a new safeguard solely to satisfy 03.13.14. Instead, treat it as a documentation and program-integrity requirement: your program must reflect the current baseline and avoid stale mappings that create confusion, duplicated testing, or incorrect risk acceptance.

A practical way to frame it internally: 03.13.14 is a control-catalog hygiene check. If your artifacts still reference it, your program is drifting from the authoritative text. ¹

Who it applies to (entity and operational context)

This matters for:

• Federal contractors handling Controlled Unclassified Information (CUI) in nonfederal systems. ¹
• Any nonfederal organization handling CUI on behalf of the government, including through third parties (cloud providers, managed service providers, consultants) where your SSP boundary includes their systems or shared responsibilities. ¹

Operational contexts where withdrawn requirements cause problems:

• You adopted an older control matrix and never reconciled it to Rev. 3.
• Your third-party due diligence package asks suppliers to attest to requirement IDs that are no longer current.
• Your SSP includes boilerplate control narratives keyed to withdrawn identifiers.
• Your POA&M tracks remediation items tied to the withdrawn control ID, making closure validation ambiguous.

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

Step 1: Mark 03.13.14 as “Withdrawn” in your control library

• Add an entry for 03.13.14: withdrawn requirement with status “Withdrawn (Rev. 3)”.
• Add a short rationale: “Withdrawn in NIST SP 800-171 Rev. 3; no standalone implementation required.” ¹
• Assign a control owner anyway (usually GRC) to ensure it stays correctly handled during updates.

Output: Control catalog record, with clear status and handling notes.

Step 2: Find and remediate legacy references across your GRC surface area

Search for “03.13.14” (and common variations like “3.13.14” or “03-13-14”) in:

• SSP sections and control narratives
• Policies/standards (especially cybersecurity standards and secure engineering standards)
• Internal audit programs and test scripts
• Third-party questionnaires and contract security exhibits
• Tooling: compliance platforms, ticket templates, evidence indexes

For each hit, make one of these dispositions:

• Remove the reference if it implies an active requirement.
• Replace with the correct current requirement reference (if your legacy control text still applies elsewhere).
• Annotate as “Withdrawn in Rev. 3” if you must preserve historical context (for example, in an archived assessment).

Output: A change log showing what you changed and where.

Step 3: Update your SSP mapping and control statements

Even though 03.13.14 is withdrawn, the program expectation remains: your SSP should cleanly map active requirements to:

• control statement(s)
• responsible system components (people/process/technology)
• accountable control owners

If you previously mapped safeguards to 03.13.14, remap them to the correct active control(s) or remove them if redundant. Keep the SSP internally consistent: no orphaned narrative, no dangling references in diagrams, and no evidence requests tied to a withdrawn ID. ¹

Practical tip: If your SSP has a table keyed by requirement ID, include 03.13.14 with “Withdrawn” and “Not applicable (withdrawn)” so assessors see that you handled it deliberately, not accidentally.

Step 4: Fix POA&M items and closure criteria

If your POA&M contains items tied to 03.13.14:

• Reclassify them to the correct active requirement, if the remediation is still relevant.
• If the item exists only because of the withdrawn ID, close it with a documented rationale and approval (GRC + system owner). ¹
• Update closure validation steps so evidence points to the active control requirement(s), not the withdrawn one.

Output: POA&M record updates with traceable approvals and closure notes.

Step 5: Adjust your assessment procedures and evidence collection

Update your internal assessment program so:

• Test plans do not include 03.13.14 as a test objective.
• Evidence indices do not request artifacts “for 03.13.14.”
• Assessors are given a short memo in the assessment package noting 03.13.14 is withdrawn and how your program handles withdrawn items. ¹

Step 6: Put change control around requirement mappings going forward

Withdrawn requirements are a symptom of why you need governance around control mappings:

• Define who can edit SSP/control mappings.
• Require peer review for mapping changes.
• Maintain version history (what changed, when, and why). Daydream (as a workflow) fits naturally here by tracking mappings, owners, evidence, and POA&M closure in one place, so withdrawn items don’t linger in templates and spreadsheets.

Required evidence and artifacts to retain

Keep evidence that demonstrates deliberate handling of the 03.13.14: withdrawn requirement:

1. Control library entry showing “Withdrawn” status and rationale. ¹
2. SSP excerpt(s) where 03.13.14 is marked withdrawn or absent from active control mappings, with change history.
3. Crosswalk or change log listing documents and questionnaires updated to remove/annotate 03.13.14.
4. POA&M updates (if applicable) showing re-mapping or closure with approvals and closure validation notes.
5. Assessment plan/workpapers update showing 03.13.14 removed from test steps and evidence requests.

Common exam/audit questions and hangups

Expect these questions in an assessment or customer audit:

• “Why is 03.13.14 missing from your SSP control table?”
  Good answer: “It is withdrawn in Rev. 3; we track it as withdrawn in our control library and do not test it as an active requirement.” ¹
• “Show me how you ensure your mappings stay aligned to Rev. 3.”
  Have your mapping governance procedure and version history ready.
• “You referenced 03.13.14 in a policy. Which requirement does that policy section actually support?”
  Be ready to point to the updated mapping.
• “Is any POA&M item still tied to withdrawn controls?”
  Your POA&M should show either re-mapping or justified closure.

Audit hangup: assessors may treat inconsistent documentation as a sign that other parts of the SSP are stale. Withdrawn-control hygiene is a credibility check.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid
Deleting 03.13.14 everywhere with no record	Creates questions about whether you noticed the withdrawal or missed it	Keep a control-library entry marked “Withdrawn” and a change log. 1
Leaving old requirement IDs in third-party questionnaires	Forces suppliers to answer against a non-operative control, weakens diligence	Maintain a “questionnaire baseline” and update requirement references under document control.
Closing POA&M items without re-mapping analysis	Remediation may still be needed under another active requirement	Require a re-mapping review step before closing.
Continuing to collect evidence “for 03.13.14”	Wastes effort and confuses assessors	Update evidence catalogs and test scripts; retrain control owners.
Treating “withdrawn” as “not applicable” without explanation	“N/A” can look like a scoping dodge	Use explicit language: “Withdrawn in Rev. 3.” 1

Enforcement context and risk implications

No public enforcement cases were provided for this specific requirement in the source catalog, and NIST SP 800-171 is a standard that is commonly enforced through contractual and acquisition mechanisms rather than a single civil penalty schedule. Your practical risk is still real: stale mappings and SSP inconsistencies can drive negative assessment outcomes, contract friction, and delayed awards when customers require demonstrable alignment to the current requirement set. ¹

A practical 30/60/90-day execution plan

Days 0–30: Stabilize documentation and scope

• Add 03.13.14 to your control library as “Withdrawn,” assign GRC ownership, and document handling. ¹
• Run enterprise text search across SSP, policies, assessment scripts, and third-party questionnaires.
• Create a change log and remediate the highest-impact documents first (SSP, customer-facing attestations).

Days 31–60: Fix mappings and remediation governance

• Update SSP control mappings and remove any evidence requests tied to 03.13.14. ¹
• Review POA&M for items referencing 03.13.14; re-map or close with approvals.
• Update internal assessment procedures and workpapers to reflect Rev. 3 control IDs.

Days 61–90: Prove it works and prevent recurrence

• Run a mini internal audit of “withdrawn requirement hygiene”: SSP table, evidence index, questionnaire baseline, POA&M integrity.
• Add a standing control: “Framework update review” that checks for withdrawn/added requirements during each revision cycle. ¹
• If you use Daydream, configure a mapping review workflow (owner, reviewer, evidence fields, and POA&M linkage) so withdrawn items can’t persist in downstream templates.

Frequently Asked Questions

Do I need to implement any technical control for 03.13.14?

No. It is explicitly withdrawn in NIST SP 800-171 Rev. 3, so there is no standalone implementation target. Your obligation is to keep your SSP, mappings, and evidence program aligned to the active Rev. 3 requirements. ¹

Should 03.13.14 appear in our SSP at all?

It can, as long as it is clearly labeled “Withdrawn” and not treated as an active requirement. Many teams keep it in mapping tables to show intentional handling and avoid questions about gaps. ¹

What if a customer or prime contractor questionnaire still asks about 03.13.14?

Respond that 03.13.14 is withdrawn in Rev. 3 and point to your SSP/control library note. Offer to map your relevant safeguards to the current active requirement(s) that cover the same objective, if applicable. ¹

We have a POA&M item tagged to 03.13.14. Do we close it?

First determine whether the underlying weakness maps to an active Rev. 3 requirement. If it does, re-tag it and keep the remediation plan; if it does not, close it with documented rationale and approvals. ¹

How do auditors react if our documentation references withdrawn requirements?

They typically treat it as a documentation currency and governance problem. Even if your technical safeguards are strong, inconsistent mappings reduce confidence in the SSP and can expand the scope of follow-up testing. ¹

How do we prevent withdrawn requirements from resurfacing in templates?

Put requirement-ID mappings under change control and maintain a single source of truth for control statements and evidence requests. Use tooling or workflows (including Daydream) that tie requirement IDs to owners, system components, and recurring evidence so deprecated items do not propagate.

Footnotes

1. NIST SP 800-171 Rev. 3