03.13.16: Withdrawn

Withdrawn requirements create a predictable assessment failure mode: your team assumes “nothing to do,” but your assessor expects a complete control catalog and a defensible mapping story. Requirement 03.13.16 in NIST SP 800-171 Rev. 3 is explicitly marked “Withdrawn.” ¹ That means NIST removed the requirement from the active set; you are not expected to design or operate a control to satisfy it.

Your job as a Compliance Officer, CCO, or GRC lead is to prevent ambiguity. In practice, ambiguity shows up as inconsistent control matrices, inherited templates that still list the requirement, or an SSP that is silent about why the control is missing. The right response is disciplined hygiene: update your baseline, document the status, and retain evidence that you reviewed the requirement and intentionally excluded it.

This page gives requirement-level implementation guidance to operationalize the 03.13.16: withdrawn requirement quickly: who it applies to, exactly what to document, what artifacts to keep, common audit questions, and a practical execution plan.

Regulatory text

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

What the operator must do

Because the requirement is withdrawn, your operational obligation is documentation and traceability, not implementation:

• Record that 03.13.16 is withdrawn in your control catalog/control matrix.
• Ensure your SSP and assessment artifacts reflect the withdrawn status so the assessor can reconcile numbering without assuming a gap.
• Confirm no internal policy, procedure, or third-party contract incorrectly claims compliance to a control that no longer exists (a common templating issue).
• Track the decision (who reviewed it, what source was used, and where it is documented) as part of recurring evidence collection. ¹

A clean mapping line item is often the difference between a smooth assessment and a preventable finding.

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

“Withdrawn” means NIST has removed 03.13.16 from the current requirement set. You are not expected to build, operate, or test a control for it. ¹

What you are expected to do is:

• Maintain an accurate baseline for the version you claim (Rev. 3).
• Show that you reviewed 03.13.16 and intentionally marked it as not applicable because it is withdrawn (not because you missed it).
• Prevent stale mappings from earlier templates or tool exports from creating contradictions.

If you manage multiple baselines (for example, internal policy still referencing older control sets), treat “withdrawn” as a configuration management issue: align the authoritative baseline and then drive updates outward to dependent documents.

Who it applies to (entity and operational context)

This applies to:

• Federal contractors and other organizations operating nonfederal systems handling CUI that align their security program to NIST SP 800-171 Rev. 3. ¹
• GRC/compliance owners responsible for SSPs, control matrices, and assessment readiness packages.
• Control owners indirectly, because the withdrawn status should prevent wasted engineering work and prevent contradictory evidence requests.

Operational contexts where this matters most:

• You are preparing for an internal readiness review or an external assessment and need an assessor-friendly control inventory.
• You inherited a control library (spreadsheets, GRC tool content, or a “Rev. 2/Rev. 3 blended” template) that still lists 03.13.16 as active.
• You are harmonizing NIST SP 800-171 with other frameworks and want clean crosswalk logic without phantom controls.

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

Use this as a short runbook to operationalize the 03.13.16: withdrawn requirement.

Step 1: Confirm authoritative source and scope

1. Open the official Rev. 3 source and confirm the requirement is listed as “Withdrawn.” ¹
2. Confirm your compliance scope statement references NIST SP 800-171 Rev. 3 (not an older revision or an internal hybrid). ¹

Output: a citation-backed note in your compliance workspace that 03.13.16 is withdrawn per Rev. 3.

Step 2: Update your control baseline and control matrix

1. In your control matrix, keep the control ID row for 03.13.16 (do not delete it).
2. Set status to: Withdrawn (NIST SP 800-171 Rev. 3). ¹
3. In the “implementation” column, write a short statement: “Withdrawn by NIST in Rev. 3; no implementation required.”
4. In the “evidence” column, point to the artifact location (see evidence section).

Why keep the row: Assessors often reconcile numbering. Missing rows look like missing controls.

Step 3: Align SSP language and assessment narratives

1. In the SSP, add a brief statement in the relevant section or control appendix: “03.13.16 is withdrawn in NIST SP 800-171 Rev. 3 and is excluded from the implemented requirement set.” ¹
2. If you maintain an “exceptions/deviations” register, do not treat “withdrawn” as an exception. Treat it as baseline metadata.

Step 4: Clean up dependent documents and third-party flows

1. Search internal policies, standards, and procedures for “03.13.16” and remove or annotate any references.
2. Check third-party security exhibits, supplier requirements, or contract appendices that list NIST controls. If they include 03.13.16 as an obligation, issue a controlled revision or clarification memo.
3. If you use a GRC tool or evidence platform (including Daydream), ensure the requirement is tagged as withdrawn so tasks and evidence requests are not generated for control owners.

Step 5: Add recurring evidence hygiene

Even withdrawn items benefit from recurring governance checks:

• Reconfirm the withdrawn status when you refresh your baseline versioning or when your SSP is re-issued. ¹
• Ensure new templates, M&A inherited programs, or new business units do not reintroduce the control as active.

Required evidence and artifacts to retain

Store these in your assessment package so an auditor can close the loop quickly:

1. Control matrix entry for 03.13.16 showing “Withdrawn” with a Rev. 3 citation. ¹
2. SSP excerpt or appendix entry documenting withdrawn status and exclusion from the implemented set. ¹
3. Baseline version statement (a short document or SSP section) that clearly states you follow NIST SP 800-171 Rev. 3. ¹
4. Document change record (ticket, change log, or controlled document revision notes) showing you updated templates/policies if they previously referenced 03.13.16.
5. Tool configuration evidence (screenshot or export) showing the requirement is marked withdrawn in your GRC system, if applicable.

Practical tip: In Daydream, teams typically store a “Withdrawn/Not Applicable Determinations” bundle alongside the SSP so withdrawn items don’t get lost when evidence is refreshed.

Common exam/audit questions and hangups

Assessors tend to ask the same questions for withdrawn controls because they’re validating completeness:

• “Why is 03.13.16 missing from your implemented controls list?”
  Expectation: You show the control matrix row and the SSP note stating it is withdrawn in Rev. 3. ¹

• “Which revision are you claiming?”
  Hangup: If your documents inconsistently mention Rev. 2 vs Rev. 3, the withdrawn status becomes a symptom of a larger baseline governance problem.

• “Do you have any internal control that replaced it?”
  Good response: “No requirement exists in Rev. 3; we addressed adjacent risks through our broader security program where applicable.” Keep this factual and avoid inventing a “replacement control” unless your internal standards truly define one.

• “Show evidence that you reviewed it.”
  Provide the cited excerpt, your mapping entry, and the change log/ticket.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it causes trouble	How to avoid it
Deleting 03.13.16 from the spreadsheet/tool	Creates numbering gaps that look like omissions	Keep the row; mark as withdrawn with citation. 1
Treating “withdrawn” as “not applicable” without explanation	“N/A” reads like scoping avoidance	Use the word “Withdrawn” and cite Rev. 3. 1
Leaving old policy text that references 03.13.16	Produces contradictions across artifacts	Run a document search and revise under change control.
Creating an unnecessary compensating control	Wastes engineering time and confuses control intent	Only implement controls that map to active requirements or explicit internal risk decisions.
No evidence of review	Auditors can still write a documentation finding	Keep a short decision record plus SSP/control matrix mapping.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, and NIST SP 800-171 is a framework standard rather than an enforcement docket. ¹

Your real risk is indirect:

• Assessment risk: A withdrawn requirement can still generate findings if your documentation set looks incomplete or inconsistent.
• Contractual risk: If a contract or third-party flowdown incorrectly references withdrawn controls, you can create obligations you cannot “prove,” or you can invite disputes about what standard applies.

Treat this as baseline governance. Clean baselines reduce noise and keep attention on real control gaps.

Practical execution plan (30/60/90)

First 30 days (stabilize baseline hygiene)

• Confirm 03.13.16 is withdrawn in your authoritative Rev. 3 source and capture the citation for your workpapers. ¹
• Update control matrix row: status = Withdrawn; add rationale and evidence pointer.
• Add SSP note or appendix entry documenting withdrawn status. ¹

By 60 days (remove contradictions)

• Sweep policies, standards, procedures, and templates for references to 03.13.16; correct them under document control.
• Check third-party security schedules and flowdowns that cite NIST controls; issue clarifications or revisions if 03.13.16 appears.
• Update your GRC tooling so the requirement does not generate tasks or evidence requests.

By 90 days (operationalize recurring assurance)

• Add a baseline/version verification step to your SSP refresh process so withdrawn requirements stay correctly flagged. ¹
• Build an “assessment readiness” checklist item: “Withdrawn controls reconciled and evidenced.”
• If you use Daydream for evidence collection, standardize a recurring “control catalog reconciliation” workflow so withdrawn items remain documented as your program evolves.

Frequently Asked Questions

If 03.13.16 is withdrawn, should we remove it from our SSP?

Don’t remove it silently. Keep a short SSP note or appendix entry stating it is withdrawn in NIST SP 800-171 Rev. 3 and therefore excluded from the implemented set. ¹

Will an assessor write a finding because we didn’t implement 03.13.16?

They should not expect implementation for a withdrawn requirement, but they can still document an issue if your control inventory is incomplete or your baseline version is unclear. Keep the mapping row and citation to close the loop. ¹

How should we label it in our control matrix: “N/A” or “Withdrawn”?

Use “Withdrawn” explicitly and cite NIST SP 800-171 Rev. 3. “N/A” without context often triggers scoping follow-up questions. ¹

What evidence is “enough” for a withdrawn requirement?

Maintain a control matrix entry marked withdrawn, an SSP reference, and a brief decision record (ticket or change log) showing you reviewed and updated your baseline artifacts. ¹

Our contract references NIST SP 800-171, but doesn’t specify revision. What do we do about 03.13.16?

Treat that as a contract clarification task. Document which revision governs your program and align flowdowns and assessment language to that revision so “withdrawn” items don’t become disputed obligations. ¹

How does Daydream help with a withdrawn control?

Use Daydream to keep a single source of truth for the control catalog, mark 03.13.16 as withdrawn, and attach the SSP excerpt and mapping evidence so auditors see a complete, reconciled requirement set without extra control-owner tasks.

Footnotes

1. NIST SP 800-171 Rev. 3