03.13.02: Withdrawn

NIST SP 800-171 Rev. 3 requirement 03.13.02 is withdrawn, meaning you are not expected to implement or be assessed against a standalone control statement for it. You still must prove you identified the withdrawal, updated your SSP/assessment mappings, and ensured any replaced or related requirements are covered by other implemented controls ¹.

Key takeaways:

• Treat 03.13.02 as a documentation and governance requirement, not a technical implementation item ¹.
• Update your SSP, control crosswalks, and assessment scope so auditors don’t flag a “missing control” ².
• If you previously implemented something for 03.13.02, decide whether to retain, merge, or retire it based on current control coverage and risk.

“Withdrawn” requirements are deceptively risky in audits: the control is gone, but your evidence trail still has to make sense. A C3PAO or internal assessor can’t test what no longer exists, yet they can and will test whether your program tracks version changes, keeps mappings current, and avoids dead control references that create scope confusion.

For Compliance Officers and GRC leads supporting environments that handle Controlled Unclassified Information (CUI), the operational goal is straightforward: eliminate ambiguity. Your System Security Plan (SSP), policies, procedures, and assessment artifacts should clearly show that 03.13.02 is not applicable because it is withdrawn, and that the underlying security objective (if any) is addressed elsewhere in your NIST SP 800-171 Rev. 3 implementation.

This page tells you exactly what to change, what to keep, and how to answer the inevitable exam question: “Why is this requirement not implemented?” The deliverable is a clean, defensible audit trail that aligns to NIST SP 800-171 Rev. 3 and is assessable under NIST SP 800-171A ³.

Regulatory text

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

Plain-English interpretation

• There is no active requirement to implement for 03.13.02. “Withdrawn” means NIST removed the requirement from Rev. 3 and it should not be evaluated as a current control requirement ¹.
• Your job is to reflect that reality everywhere your program references requirements. Auditors and customers care that your SSP and control mappings are current, coherent, and assessable ².
• You still need a traceable decision. The most common audit finding around withdrawn items is not security failure; it is documentation drift (SSP says “planned” or “not implemented,” a policy references it, or a tool mapping expects evidence).

Who it applies to (entity and operational context)

This guidance applies when:

• You are a federal contractor, subcontractor, or other nonfederal organization operating a system that processes, stores, or transmits CUI and you use NIST SP 800-171 Rev. 3 as the control baseline ¹.
• You maintain an SSP and POA&M for that environment and expect assessment activities aligned to NIST SP 800-171A ².
• You have a GRC platform, spreadsheet, or governance process that maps requirements to controls, owners, and evidence.

Operationally, this shows up in:

• SSP requirement tables and narratives
• Control crosswalks (Rev. 2 to Rev. 3 transitions)
• POA&M entries created historically for “03.13.02”
• Internal audit programs and test scripts
• Third-party assessments and customer security questionnaires that reuse older mappings

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

Treat this as a mini change-management task with tight scope control.

1) Confirm the withdrawal and freeze the interpretation

• Record the source statement that 03.13.02 is withdrawn in your control library notes ¹.
• Add a one-line “interpretation” entry: “Withdrawn in Rev. 3; no standalone implementation required; handled through program governance and mapping hygiene.”

Operator tip: keep the note short and unambiguous. Auditors don’t want essays; they want a clear scope decision.

2) Remove 03.13.02 from assessable scope (without deleting history)

• In your SSP requirement matrix, mark 03.13.02 as Withdrawn / Not Applicable (Withdrawn by standard) and reference the standard text ¹.
• In assessment workpapers aligned to NIST SP 800-171A, ensure 03.13.02 is excluded from test procedures or explicitly labeled “Withdrawn” so it does not appear as an untested gap ².

3) Identify “dangling references” across documentation

Search your repository for:

• “03.13.02”
• “3.13.2” (common formatting variant)
• Any legacy control IDs tied to 03.13.02 in templates

Update:

• Policies/procedures that cite the withdrawn requirement
• SSP narrative sections that mention it
• Evidence indexes that expect periodic artifacts

Outcome: no document should imply 03.13.02 is an active requirement.

4) Decide what to do with any legacy technical/administrative controls

If you implemented a safeguard in the past specifically “for 03.13.02,” classify it into one of three buckets:

Legacy control behavior	Keep / Merge / Retire	Decision rule
Still reduces relevant risk and supports other active requirements	Keep	Map it to the active requirement(s) it now supports 1.
Duplicates other controls and adds operational overhead	Merge	Consolidate procedures and evidence under one owner/control statement.
No longer relevant, creates noise, or conflicts with current architecture	Retire	Document retirement approval and remove from operational checklists.

5) Update SSP control statements, owners, and components (critical for audit clarity)

Even though the requirement is withdrawn, your program still benefits from consistent mapping discipline:

• Map the withdrawal status to an SSP entry that names:
  • Control owner (who maintains the mapping decision)
  • Systems/components in scope (the CUI boundary the SSP covers)
  • Where the objective is covered instead (if applicable)

This aligns with the practical expectation that requirements are tied to implementable safeguards and accountable owners ¹.

6) Clean up the POA&M

• If you have an open POA&M item for 03.13.02, do not “close” it as implemented.
• Reclassify it as:
  • “Withdrawn requirement,” and
  • Link to any replacement coverage (if you mapped the work to other active requirements).
• Require closure validation: a reviewer confirms the SSP mapping is updated and that no assessment script still tests it.

This prevents the common evidence gap where a POA&M appears “suspiciously closed” without a real fix.

7) Make the decision repeatable (version-change hygiene)

Add a lightweight control to your governance cadence:

• A periodic standards review trigger: when NIST SP 800-171 changes, you update mappings and assessment scope ⁴.
• Assign responsibility to GRC or the SSP owner.

Where Daydream fits naturally: Use Daydream to track requirement-to-SSP mappings and attach the withdrawal rationale and approvals as evidence, so the “why is this not implemented?” question is answered in one place.

Required evidence and artifacts to retain

Auditors generally want proof that your program is current and decisions are controlled. Keep:

1. SSP excerpt / requirement matrix entry showing 03.13.02 = Withdrawn/NA, with citation ¹.
2. Control library change record (ticket or change log) documenting:
   • what changed,
   • who approved,
   • when it was applied,
   • impacted documents/systems.
3. Assessment scope document or test plan showing 03.13.02 removed or labeled withdrawn ².
4. POA&M updates (if applicable) showing reclassification and closure validation.
5. Document search results / remediation list proving you removed dangling references (policy citations, templates).
6. Mapping crosswalk (optional but helpful) that shows where any legacy implementation effort now maps in Rev. 3.

Common exam/audit questions and hangups

Expect these questions and prepare short, evidence-backed answers:

• “Why is 03.13.02 not implemented?”
  “It is withdrawn in NIST SP 800-171 Rev. 3; our SSP lists it as Withdrawn/NA and our assessment plan excludes it.” ³

• “Show me where this is documented.”
  Provide SSP matrix page, change ticket, and assessment scope excerpt.

• “Did you remove it from your POA&M?”
  Show reclassification/closure notes and reviewer sign-off.

• “What replaced it?”
  If you mapped legacy activity to other requirements, show the crosswalk. If not, state clearly: “No replacement identified; requirement removed; no test required.” Keep it factual ¹.

Frequent implementation mistakes and how to avoid them

1. Leaving 03.13.02 as “Planned” in the SSP
   Fix: mark Withdrawn/NA with citation and a short rationale ¹.

2. Deleting all traces (and losing the audit trail)
   Fix: retain a change log and historical reference; remove from active testing only.

3. Closing POA&M work as “implemented” without re-scoping
   Fix: reclassify as withdrawn, link to current coverage, require closure validation.

4. Assessor confusion from inconsistent labeling (03.13.02 vs 3.13.2)
   Fix: normalize naming across SSP, control library, and evidence index.

5. Treating “withdrawn” as permission to ignore governance hygiene
   Fix: run a standards-change checklist and document the outcome ⁴.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific withdrawn requirement. The practical risk is still real: customers and assessors may treat inconsistent mappings as a sign your SSP is stale, your assessment scope is unreliable, or your POA&M governance is weak ². That can lead to failed assessments, delayed awards, or corrective action requests, even if your technical controls are strong.

A practical 30/60/90-day execution plan

Use this phased plan to operationalize quickly without inventing time-based claims about how long remediation “should” take. The phases are sequencing, not duration guarantees.

First 30 days (Immediate stabilization)

• Update SSP requirement matrix: 03.13.02 = Withdrawn/NA with citation ¹.
• Update assessment scope/test scripts to remove 03.13.02 checks ².
• Open a documentation cleanup ticket to remove dangling references.

Next 60 days (Program alignment)

• Complete repository search and update policies/procedures/templates that cite 03.13.02.
• Review POA&M for any entries tied to 03.13.02; reclassify and document closure validation.
• If you maintain crosswalks, update Rev. 2 to Rev. 3 mapping notes to prevent reintroduction.

Next 90 days (Sustainment)

• Add a recurring standards-change review step to your GRC calendar and assign an owner ⁴.
• Run an internal “assessment readiness” check using NIST SP 800-171A-style evidence expectations to confirm the withdrawn requirement cannot surface as an artificial gap ².
• Centralize evidence in a system of record (for many teams, Daydream becomes the practical home for mappings, approvals, and artifacts).

Frequently Asked Questions

If 03.13.02 is withdrawn, do we need a compensating control?

Not for 03.13.02 itself. You need a documented rationale showing it is withdrawn and evidence your SSP and assessment scope reflect that status ³.

Should we keep the SSP row for 03.13.02 or delete it?

Keep a row or note if your SSP template lists all requirement identifiers, but mark it Withdrawn/NA and cite the standard. Deleting it is fine only if your template does not enumerate withdrawn items and your crosswalks will not re-add it.

Our customer checklist still asks about 03.13.02. How do we respond?

Respond that 03.13.02 is withdrawn in NIST SP 800-171 Rev. 3 and provide a short excerpt citation plus your SSP mapping note ¹. Offer to map the customer’s intent to the current Rev. 3 requirement set if they want an equivalent discussion.

What if we previously implemented a technical safeguard tied to 03.13.02?

Decide whether it supports other active requirements; if it does, map it there and keep the evidence stream. If it does not, retire it with an approval record so the change is controlled.

Will an assessor fail us for not implementing 03.13.02?

They should not assess a withdrawn requirement as a missing control, but they can flag inconsistent documentation or stale scope definitions. Keep SSP, POA&M, and assessment artifacts aligned to avoid preventable findings ².

What evidence is “enough” to prove we handled the withdrawal?

An updated SSP entry plus an assessment scope/test plan update usually resolves the question, backed by a change record. If you had POA&M items or policy references, include the cleanup artifacts too.

Footnotes

1. NIST SP 800-171 Rev. 3

2. NIST SP 800-171A

3. NIST SP 800-171 Rev. 3; NIST SP 800-171A

4. NIST SP 800-171 Rev. 3 landing page