03.13.02: Withdrawn

03.13.02 is a withdrawn requirement in NIST SP 800-171 Rev. 3, so you do not implement a standalone technical control for it. You operationalize it by documenting that it is withdrawn, mapping any legacy implementation to the current requirement set, and retaining evidence that your NIST SP 800-171 scope, SSP, and control crosswalk reflect the withdrawal. (NIST SP 800-171 Rev. 3)

Key takeaways:

• Treat the 03.13.02: withdrawn requirement as a governance task: correct mappings, not new controls. (NIST SP 800-171 Rev. 3)
• Your audit risk is “missing evidence” and “outdated crosswalks,” not failure to meet a technical safeguard. (NIST SP 800-171 Rev. 3)
• Update SSPs, POA&Ms, and assessment narratives so reviewers see a clean, current control set with an explicit “withdrawn” disposition. (NIST SP 800-171 Rev. 3)

Withdrawn requirements create a specific kind of compliance failure: organizations keep implementing, testing, and claiming alignment to a control that no longer exists, then struggle to explain mismatches between their SSP, their evidence, and their assessor’s checklist. For NIST SP 800-171 Rev. 3, requirement 03.13.02 is explicitly marked “Withdrawn.” (NIST SP 800-171 Rev. 3)

For a CCO, GRC lead, or compliance operator, the goal is straightforward: ensure your program documentation and control mappings reflect Rev. 3 accurately, and ensure any legacy references (policies, control matrices, ticket templates, internal audit scripts, third-party questionnaires, and evidence binders) do not imply there is an active obligation where none exists. This is especially relevant in CUI environments where your SSP and assessment artifacts must be internally consistent and traceable.

This page tells you exactly how to “implement” a withdrawn requirement: what to change, what to keep, what to stop collecting, and what evidence to retain so an assessor can follow your logic quickly and move on.

Regulatory text

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

Operator interpretation (what you must do)

Because 03.13.02 is withdrawn, your obligation is not to deploy a new control. Your obligation is to:

1. Accurately represent the requirement’s withdrawn status in your compliance mapping and narrative documentation. (NIST SP 800-171 Rev. 3)
2. Ensure no active testing/evidence requests depend on 03.13.02 as if it were enforceable in Rev. 3. (NIST SP 800-171 Rev. 3)
3. Prevent “control drift” where teams keep operating legacy procedures solely to satisfy a retired citation, creating confusion in audits and assessments. (NIST SP 800-171 Rev. 3)

If you previously implemented something labeled “03.13.02” under an older internal mapping, you can keep the underlying security practice if it is valuable; just map it to the correct current requirement(s) or treat it as an internal control enhancement.

Plain-English interpretation of the requirement

The 03.13.02: withdrawn requirement means: “This specific control identifier is no longer part of the NIST SP 800-171 Rev. 3 requirement set.” (NIST SP 800-171 Rev. 3)

In practice, assessors and customers will still notice it because:

• your legacy SSP may reference it,
• your evidence binder may include it,
• your GRC tool may still list it,
• your third-party due diligence packages may still ask suppliers about it.

So your job is to make your program “Rev. 3 clean”: no orphaned references, no stale test steps, and no incorrect claims of coverage.

Who it applies to (entity and operational context)

This applies to organizations that align to NIST SP 800-171 Rev. 3 for protecting CUI in nonfederal systems, including:

• Federal contractors and subcontractors handling CUI in their environments. (NIST SP 800-171 Rev. 3)
• Nonfederal system operators (internal IT, cloud, managed service providers) that store, process, or transmit CUI for a covered entity. (NIST SP 800-171 Rev. 3)

Operationally, this touches:

• SSP and POA&M ownership (GRC / security compliance),
• security control owners (cybersecurity operations),
• internal audit / readiness assessment teams,
• third-party risk teams if you flow requirements down to suppliers.

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

Step 1: Identify where 03.13.02 appears

Search across your compliance system for references to “03.13.02” and “13.02” including:

• SSP control descriptions and inherited controls,
• control matrices / crosswalks (NIST to ISO, NIST to internal policy),
• POA&M items,
• audit workpapers and test scripts,
• evidence folders and naming conventions,
• third-party security questionnaires and contract exhibits.

Deliverable: an “occurrence list” that shows every place the withdrawn citation appears, who owns it, and whether it drives evidence collection.

Step 2: Set an explicit disposition: “Withdrawn (Rev. 3)”

In your control register or GRC tool, create a standard disposition field (or equivalent note) that states:

• Control ID: 03.13.02
• Status: Withdrawn
• Rationale: Withdrawn in NIST SP 800-171 Rev. 3 (NIST SP 800-171 Rev. 3)
• Action: No standalone implementation; map legacy activities to current applicable controls or keep as internal best practice.

This is the core audit move: you are not “ignoring” it; you are treating it correctly.

Step 3: Remap any legacy implementation to current requirements (or de-scope it)

If you find operational activities labeled as “03.13.02,” decide which bucket they fall into:

Legacy activity labeled 03.13.02	Decision	What to document
Activity clearly supports another active security objective	Keep the activity	Update mapping to the current active requirement(s); remove 03.13.02 label (NIST SP 800-171 Rev. 3)
Activity is redundant, costly, or conflicts with modern architecture	Retire or reduce it	Record decision and risk acceptance/exception if needed
Activity is valuable but not required by the framework	Keep as internal control	Mark as “internal standard” and exclude from NIST assessment assertions

Don’t guess the “new home” requirement without doing the mapping. If your team lacks time, document that mapping as a tracked action item with an owner.

Step 4: Clean up SSP and POA&M

Update the SSP so the control set you claim matches Rev. 3:

• Remove 03.13.02 from the SSP’s list of implemented requirements. (NIST SP 800-171 Rev. 3)
• If the SSP template forces an entry, set it to “Withdrawn” and explain “Not applicable; withdrawn in Rev. 3.” (NIST SP 800-171 Rev. 3)
• Close any POA&M items that exist only to “implement 03.13.02,” documenting closure reason as “Requirement withdrawn.” (NIST SP 800-171 Rev. 3)

Step 5: Fix evidence collection so you stop generating junk

Withdrawn requirements create noisy evidence binders. Make evidence collection match what you test:

• remove recurring evidence tasks tied only to 03.13.02,
• rename folders so assessors do not see a phantom requirement,
• keep a single “withdrawn requirements” memo in the binder explaining the disposition and pointing to Rev. 3.

Step 6: Update third-party flowdowns and questionnaires (if you used 03.13.02)

If your supplier language references 03.13.02, update it at the next contract refresh:

• replace the withdrawn citation with “NIST SP 800-171 Rev. 3 applicable requirements,” or your organization’s derived control list,
• align procurement and TPRM templates so suppliers are not asked to attest to withdrawn items.

Step 7: Make it repeatable (recurring evidence)

Even though 03.13.02 is withdrawn, you still need repeatable governance:

• a periodic “framework delta review” task for NIST SP 800-171 revisions, and
• a standard method to document withdrawn/superseded controls in your control register. (NIST SP 800-171 Rev. 3)

If you use Daydream, treat this requirement page as the canonical record: mark it “withdrawn,” attach the SSP excerpt showing removal, and schedule a lightweight recurring check that your mappings stay current across policies, controls, and evidence requests.

Required evidence and artifacts to retain

Keep artifacts that prove you handled the withdrawal intentionally:

1. Control register entry showing 03.13.02 status “Withdrawn” with rationale. (NIST SP 800-171 Rev. 3)
2. SSP excerpt or revision history showing 03.13.02 removed or labeled withdrawn. (NIST SP 800-171 Rev. 3)
3. Crosswalk update log (NIST-to-internal, NIST-to-ISO, etc.) showing removal/remap of 03.13.02.
4. POA&M closure record if any items were opened solely for 03.13.02.
5. Evidence binder index showing no active testing/evidence is collected for 03.13.02.
6. Change ticket / approval for the documentation update (optional but helpful for audit traceability).

Common exam/audit questions and hangups

Expect reviewers to probe consistency:

• “Why is 03.13.02 missing from your SSP/control matrix?”
  Answer: It is withdrawn in NIST SP 800-171 Rev. 3; we track it as withdrawn with a documented disposition. (NIST SP 800-171 Rev. 3)

• “Your policy references 03.13.02. Are you using the right version?”
  Fix: update policy citations and show a change record.

• “Show me evidence for 03.13.02.”
  Response: there is no evidence because it is withdrawn; provide the withdrawn disposition memo and mapping record. (NIST SP 800-171 Rev. 3)

• “Are you sure you didn’t drop an underlying control objective?”
  Show your remap: the underlying practice is mapped to active requirements or retained as an internal control.

Frequent implementation mistakes and how to avoid them

1. Deleting all traces without explanation.
   Keep a short withdrawn disposition note so assessors don’t assume you missed a requirement. (NIST SP 800-171 Rev. 3)

2. Continuing to collect evidence for a withdrawn control.
   Remove the evidence tasks; remap the activity to a current requirement if it still matters.

3. Leaving legacy crosswalks in place.
   Old spreadsheets live forever. Update the authoritative mapping and archive the old one with a clear “superseded” label.

4. Letting third parties drive your control set.
   If a prime contractor questionnaire still lists 03.13.02, respond with the withdrawal reference and provide your Rev. 3-aligned control list. (NIST SP 800-171 Rev. 3)

Enforcement context and risk implications

No public enforcement cases were provided for this specific withdrawn requirement in the source catalog, so treat risk here as assessment and contractual risk rather than a direct “violation” event.

Practical risk you should plan for:

• Assessment friction: assessors spend time reconciling mismatched control lists and may question program maturity.
• False assertions: if you claim compliance to “all requirements” but your documents reference withdrawn items incorrectly, customers may challenge the accuracy of your representations.
• Operational waste: teams spend time running tests and collecting evidence that does not support current requirements.

Practical execution plan (30/60/90-day)

A staged plan helps you get clean quickly without turning this into a documentation marathon.

First 30 days (Immediate cleanup)

• Inventory all references to 03.13.02 across SSP, policies, control register, POA&M, and evidence library.
• Add a formal “Withdrawn” disposition entry in the control register with citation to Rev. 3. (NIST SP 800-171 Rev. 3)
• Stop any recurring evidence requests tied only to 03.13.02.

By 60 days (Program alignment)

• Complete remapping of any legacy “03.13.02” activities to active requirements or internal controls.
• Update SSP text and remove/mark the requirement as withdrawn consistently across all SSP sections. (NIST SP 800-171 Rev. 3)
• Update internal audit scripts and readiness checklists so testing aligns to Rev. 3.

By 90 days (Sustainment)

• Update third-party templates (questionnaires, contract exhibits) to remove 03.13.02 references.
• Implement a “framework delta review” procedure so withdrawn/superseded items get dispositioned systematically. (NIST SP 800-171 Rev. 3)
• In Daydream (or your GRC system), attach the finalized artifacts and set a recurring control mapping review task tied to NIST SP 800-171 updates.

Frequently Asked Questions

What does “03.13.02: withdrawn requirement” mean for my compliance obligations?

It means NIST SP 800-171 Rev. 3 does not require a standalone control for 03.13.02. Your obligation is to reflect the withdrawal in your SSP, mappings, and evidence approach so your program matches Rev. 3. (NIST SP 800-171 Rev. 3)

Should we remove the security practice we previously associated with 03.13.02?

Not automatically. Keep the practice if it supports current objectives, but map it to the correct active requirement(s) or keep it as an internal control, not as “03.13.02.” (NIST SP 800-171 Rev. 3)

Auditors asked for evidence of 03.13.02. What do I show?

Provide your control register disposition (“Withdrawn”), an SSP excerpt showing it is not in scope, and your crosswalk update record. That package shows you handled the requirement intentionally. (NIST SP 800-171 Rev. 3)

Our customer contract references 03.13.02 explicitly. Are we stuck implementing it?

Treat it as a contractual interpretation issue: document that the requirement is withdrawn in Rev. 3 and propose updated language that references the applicable Rev. 3 requirement set. Track the decision and customer response in your contract file. (NIST SP 800-171 Rev. 3)

How should this appear in our SSP?

Your SSP should not present 03.13.02 as an implemented control. If your template requires an entry, label it “Withdrawn (Rev. 3)” with a one-line explanation and no test procedure. (NIST SP 800-171 Rev. 3)

What’s the biggest operational risk with withdrawn requirements?

Conflicting artifacts. If your SSP, POA&M, and evidence binder disagree about what’s required, assessors spend time reconciling your story, and stakeholders question your version control discipline.