03.13.07: Withdrawn

Withdrawn requirements create a specific kind of assessment risk: operational teams waste time building controls that are no longer required, or worse, the organization fails an internal readiness review because a tracker still shows “missing evidence” for a control that NIST removed. For a CCO, CISO, or GRC lead, the fastest path is to treat 03.13.07 as a controlled exception with clean documentation.

NIST SP 800-171 is commonly flowed down through federal contracting obligations where your nonfederal environment stores, processes, or transmits CUI. In that world, your customers and assessors typically expect a clean, traceable mapping from each NIST requirement to a policy/control/evidence set. A “withdrawn” line item breaks that pattern unless you address it deliberately.

This page gives requirement-level implementation guidance for the 03.13.07: withdrawn requirement: what it means in plain English, who needs to care, how to update your governance artifacts, what evidence to retain, and how to answer the exam/audit questions that usually follow.

Regulatory text

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

Operator interpretation: NIST has removed 03.13.07 as an active requirement in Rev. 3. There is no control objective to implement for 03.13.07 by itself. Your operational duty is to (1) reflect its withdrawn status in your compliance mapping, (2) prevent your evidence program from expecting artifacts for it, and (3) preserve a clear citation-backed explanation for assessors and customers. (NIST SP 800-171 Rev. 3)

What the operator must do:

• Mark 03.13.07 as “Withdrawn” in your control library/crosswalk and SSP mapping so it is not treated as a gap. (NIST SP 800-171 Rev. 3)
• Ensure downstream artifacts (POA&M logic, evidence requests, control testing scripts) don’t auto-generate tasks for it. (NIST SP 800-171 Rev. 3)
• Keep a lightweight record showing you made this determination using the published Rev. 3 text. (NIST SP 800-171 Rev. 3)

Plain-English interpretation (what this means day to day)

A withdrawn requirement is not “optional” and it is not “met by default.” It is not a requirement anymore in this revision. The compliance work is administrative: align your program documentation so you can prove you didn’t ignore a control; you correctly recognized that the control no longer exists in Rev. 3. (NIST SP 800-171 Rev. 3)

For most organizations, the practical problem shows up in three places:

1. Legacy spreadsheets and GRC tools still list 03.13.07 with an “open” status.
2. Evidence collection checklists request screenshots/logs that no one can tie to a real requirement.
3. Assessors and customers ask why your SSP has an empty section or why a gap exists.

Your job is to eliminate ambiguity.

Who it applies to (entity and operational context)

This applies to organizations that are scoping and implementing NIST SP 800-171 Rev. 3 for nonfederal systems handling CUI, including federal contractors and their in-scope environments where CUI is processed, stored, or transmitted. (NIST SP 800-171 Rev. 3)

Operationally, it applies to:

• The SSP owner (often GRC) maintaining the authoritative mapping.
• The control owners for security engineering/IT, who receive evidence requests.
• The internal audit / assessment readiness function that validates completeness.
• Third-party risk and procurement teams that respond to customer due diligence questionnaires referencing NIST SP 800-171 controls. (NIST SP 800-171 Rev. 3)

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

Step 1: Confirm the withdrawn status from the primary source

• Capture the published reference that 03.13.07 is “Withdrawn” in NIST SP 800-171 Rev. 3. (NIST SP 800-171 Rev. 3)
• Store a copy or a controlled reference link to the Rev. 3 publication in your compliance repository. (NIST SP 800-171 Rev. 3)

Step 2: Update your control crosswalk and requirement inventory

In your system of record (GRC tool or spreadsheet):

• Set the requirement status to Withdrawn (N/A).
• Add a short rationale: “Withdrawn in NIST SP 800-171 Rev. 3; no standalone control required.” (NIST SP 800-171 Rev. 3)
• Add the citation field pointing to the Rev. 3 source. (NIST SP 800-171 Rev. 3)

If you use Daydream to manage mappings, configure the requirement record so evidence workflows and recurring collection do not trigger for withdrawn items, while still preserving the audit trail that you reviewed and dispositioned the requirement. (NIST SP 800-171 Rev. 3)

Step 3: Update SSP language so assessors don’t treat it as a missing control

In your SSP (or equivalent system security plan):

• List 03.13.07 with the label Withdrawn.
• Include a one- to two-sentence explanation and the source citation. (NIST SP 800-171 Rev. 3)
• Ensure the SSP does not include a “to be implemented” narrative or placeholder control text for this item.

Step 4: Fix downstream workflows (POA&M, testing scripts, evidence requests)

Withdrawn requirements often remain embedded in automation:

• Remove 03.13.07 from POA&M templates so it cannot be opened as a remediation item.
• Remove it from control test procedures so internal audit doesn’t issue a finding for “missing evidence.”
• Remove it from evidence request lists sent to IT/security. (NIST SP 800-171 Rev. 3)

Step 5: Prepare the assessor/customer narrative (one paragraph, consistent wording)

Create a standard response snippet your teams can reuse in:

• Customer security questionnaires
• Contract compliance attestations (where appropriate)
• Assessment walkthroughs

Example narrative (adapt to your voice):

“Requirement 03.13.07 is marked ‘Withdrawn’ in NIST SP 800-171 Rev. 3. We treat it as not applicable for implementation and do not maintain standalone evidence for it. Our SSP and control crosswalk document this disposition with a citation to the Rev. 3 text.” (NIST SP 800-171 Rev. 3)

Step 6: Put governance around versioning so this doesn’t recur

Most confusion comes from mixed versions (Rev. 2 vs Rev. 3) across teams. Add:

• A named owner for “framework version control” (usually GRC).
• A change log entry whenever NIST mappings are refreshed.
• A rule: no team adds requirement IDs into trackers unless they come from the approved baseline (your Rev. 3 control inventory). (NIST SP 800-171 Rev. 3)

Required evidence and artifacts to retain

Even though there is no technical control, you still want audit-ready proof that you handled the item correctly.

Retain these artifacts:

• Control crosswalk entry showing 03.13.07 dispositioned as Withdrawn, with citation. (NIST SP 800-171 Rev. 3)
• SSP excerpt listing 03.13.07 as Withdrawn and explaining no implementation applies. (NIST SP 800-171 Rev. 3)
• Change record (ticket, pull request, or GRC change log) showing when you updated mappings and who approved it.
• Evidence workflow configuration (screenshot/export) showing 03.13.07 is excluded from evidence requests, if your tooling supports it.
• Customer/assessor narrative snippet stored in your standard questionnaire response library. (NIST SP 800-171 Rev. 3)

Common exam/audit questions and hangups

Question you’ll get	What the examiner/assessor is really testing	How to answer (and what to show)
“Where is your evidence for 03.13.07?”	Whether your program is complete and controlled	Show the SSP/crosswalk marking “Withdrawn” plus citation to Rev. 3. (NIST SP 800-171 Rev. 3)
“Why is it listed in your tracker as ‘open’?”	Whether governance and tooling are aligned	Show the change record that removed/closed it and updated workflows.
“Are you using Rev. 2 or Rev. 3?”	Version control and contractual scope	State your baseline version and show the approved baseline inventory. (NIST SP 800-171 Rev. 3)
“Does ‘withdrawn’ mean you can ignore the whole control family?”	Whether you’re over-scoping out of convenience	Confirm only 03.13.07 is withdrawn, and other 03.13 controls remain addressed per your SSP. (NIST SP 800-171 Rev. 3)

Frequent implementation mistakes (and how to avoid them)

1. Leaving 03.13.07 “blank” without explanation.
   Fix: Write a clear disposition statement (“Withdrawn in Rev. 3”) and cite the source. (NIST SP 800-171 Rev. 3)

2. Creating a “compensating control” for a withdrawn item.
   Fix: Don’t invent control activity. If the risk is real, map it to the correct active requirement(s) or to your internal security standards, not to 03.13.07. (NIST SP 800-171 Rev. 3)

3. Failing internal QA because testing scripts still expect evidence.
   Fix: Update test procedures and evidence lists at the same time you update the crosswalk.

4. Version drift across third parties and customers.
   Fix: Maintain a standard “framework baseline statement” in your due diligence responses that names the revision you follow and keep your mapping aligned. (NIST SP 800-171 Rev. 3)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement. The practical risk is assessment friction: a withdrawn requirement can still trigger findings in internal audits, customer reviews, or third-party assessments if your documentation and evidence program treat it as an unmet control. Your goal is clean traceability from requirement text to program disposition. (NIST SP 800-171 Rev. 3)

Practical 30/60/90-day execution plan

First 30 days (stabilize the baseline)

• Identify every place 03.13.07 appears (GRC tool, spreadsheets, SSP, test scripts, evidence checklists).
• Update the authoritative crosswalk record to “Withdrawn” with citation and owner sign-off. (NIST SP 800-171 Rev. 3)
• Patch evidence workflows so no tasks are generated for 03.13.07.

By 60 days (make it assessor-ready)

• Update SSP text and export an assessor-ready SSP excerpt showing the withdrawn disposition. (NIST SP 800-171 Rev. 3)
• Update internal audit/testing procedures to exclude 03.13.07 from sampling.
• Add the standard narrative snippet to your questionnaire response library. (NIST SP 800-171 Rev. 3)

By 90 days (prevent recurrence)

• Implement framework version governance: baseline statement, change log, and approval workflow for requirement inventory updates. (NIST SP 800-171 Rev. 3)
• Run a “withdrawn/retired requirement” check across your library to ensure similar issues won’t pop up later.
• If you manage third-party due diligence centrally, standardize how you respond when customers reference outdated requirement IDs.

Frequently Asked Questions

Do I need a control or procedure for the 03.13.07: withdrawn requirement?

No standalone control is required because 03.13.07 is withdrawn in NIST SP 800-171 Rev. 3. You do need documentation showing you dispositioned it correctly in your SSP/crosswalk with a citation. (NIST SP 800-171 Rev. 3)

Should 03.13.07 appear in our SSP at all?

Many teams keep it listed as “Withdrawn” to avoid questions about gaps in numbering and to show deliberate review. If you include it, add a short explanation and cite the Rev. 3 text. (NIST SP 800-171 Rev. 3)

What if a customer questionnaire asks how we comply with 03.13.07?

Respond that 03.13.07 is withdrawn in NIST SP 800-171 Rev. 3 and provide the citation. Then confirm you meet the rest of the applicable requirements in the relevant control family through your SSP mapping. (NIST SP 800-171 Rev. 3)

Can an assessor still write a finding for “missing 03.13.07 evidence”?

They can raise a question if your documentation is inconsistent. If your SSP and crosswalk clearly mark it as withdrawn and your evidence program excludes it, you have a defensible position grounded in the framework text. (NIST SP 800-171 Rev. 3)

How do we prevent withdrawn requirements from staying open in our GRC tool?

Make “requirement status maintenance” a governed process: one baseline inventory, change control, and periodic reconciliation between framework text and your requirement library. Tools like Daydream help by tying requirements to recurring evidence logic so withdrawn items don’t keep generating noise. (NIST SP 800-171 Rev. 3)

Does “withdrawn” mean the security topic no longer matters?

Withdrawn only means the specific numbered requirement is not present as an active requirement in Rev. 3. If the underlying risk matters to your environment, address it through the applicable active requirements and your internal security standards. (NIST SP 800-171 Rev. 3)