03.13.03: Withdrawn

Withdrawn requirements create a predictable assessment failure mode: teams either ignore the control entirely (leaving an unexplained gap in the control family), or they “fill the blank” with a homegrown requirement that cannot be supported by the standard text. For 03.13.03, NIST SP 800-171 Rev. 3 explicitly marks the requirement as withdrawn. Your job as a CCO, compliance officer, or GRC lead is to make that withdrawal operational: your compliance system must reflect that the control exists as an identifier, but not as an implementation obligation. ¹

In practice, the work is mostly documentation hygiene plus dependency checks. You want clean traceability in the System Security Plan (SSP), a control crosswalk that won’t confuse assessors, and a record that you validated no customer contract, prime flowdown, or internal policy still references the withdrawn item. If your program uses automation (for example, Daydream as your control system of record), the goal is straightforward: keep 03.13.03 in the library, set it to “Withdrawn,” and attach evidence that explains your treatment and confirms you’re meeting the current revision. ¹

Regulatory text

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

Operator interpretation (what you must do)

Because 03.13.03 is withdrawn, the operational requirement is: do not implement a standalone control for 03.13.03, and do document that the requirement is withdrawn in your compliance artifacts so an assessor can reconcile numbering and completeness. Your evidence should show:

• You recognized the withdrawal in the current revision.
• You did not claim implementation of a non-existent requirement.
• You checked for upstream/downstream dependencies (contracts, policies, tooling) that might still demand the old control by number. ¹

Plain-English interpretation of the requirement

“Withdrawn” means the standard intentionally removed the requirement from the current revision. The identifier may remain for continuity, but there is no control statement to implement. Your compliance obligation is administrative: prevent confusion, prevent stale references, and preserve auditability across revisions. ¹

Who it applies to (entity and operational context)

This applies to:

• Federal contractors and any nonfederal organization that operates systems handling CUI where NIST SP 800-171 Rev. 3 is the applicable security baseline. ¹

Operationally, it touches:

• Your SSP author and control owners (to prevent made-up implementations).
• Your contracts/procurement team (to catch flowdowns that cite 03.13.03).
• Your internal audit/assessment readiness function (to ensure crosswalk completeness).
• Any third party that provides an inherited control or shared responsibility evidence set, if your documentation references requirement numbers. ¹

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

1) Record the control status as withdrawn in your system of record

• In your GRC tool (or control spreadsheet), keep the control row for 03.13.03 and set the implementation status to Withdrawn.
• Add a short rationale field: “Withdrawn in NIST SP 800-171 Rev. 3; no standalone implementation required.” ¹

Daydream-friendly approach: Create/maintain a requirement object for 03.13.03 with status “Withdrawn,” then attach the supporting note and link it to your SSP section or control matrix entry for clean assessor navigation.

2) Update SSP and narrative documents to prevent “missing control” flags

• In the SSP control implementation table, include 03.13.03 with the disposition “Withdrawn.”
• If your SSP template auto-generates required controls, ensure it doesn’t force an implementation narrative for 03.13.03. ¹

3) Run a dependency check across contracts, policies, and procedures

Search for “03.13.03” in:

• Customer contracts, prime contractor flowdowns, security addenda
• Internal policies/standards that cite NIST control numbers
• Third-party security exhibits (shared responsibility matrices, SOC bridge letters where you’ve mapped controls by identifier)

If you find references:

• Confirm whether the document is pegged to an older revision or uses generic numbering.
• Decide whether to update the reference to the current revision language (best outcome), or document an exception with the contractual basis and a compensating mapping note. ¹

4) Ensure your assessment package explains numbering continuity

Assessors and auditors commonly reconcile “expected count” of requirements. Avoid a silent gap.

• Add a short “Withdrawn requirements” note in your assessment readiness memo or SSP appendix.
• State that 03.13.03 is withdrawn and therefore has no test procedure beyond verification of correct documentation. ¹

5) Put a maintenance control in place to prevent regressions

Make this repeatable:

• Add a checklist item to your annual SSP refresh: “Re-validate withdrawn requirements and contract references.”
• Gate SSP template changes through compliance review so a new template doesn’t drop 03.13.03 and trigger a “missing requirement” question. ¹

Required evidence and artifacts to retain

Keep evidence lightweight but explicit. Recommended artifacts:

• Control matrix / requirement register entry showing 03.13.03 = Withdrawn, with rationale and standard reference. ¹
• SSP excerpt (table row or appendix) listing 03.13.03 as Withdrawn. ¹
• Dependency check output (search results screenshot/export) showing you searched key repositories for “03.13.03,” plus a short disposition note for any hits.
• Document change record (ticket, pull request, or change log) for SSP/template updates tied to the withdrawal handling.
• If applicable: contract clarification memo or flowdown mapping note that explains why a document cites 03.13.03 and how you resolved it. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Why is 03.13.03 not implemented?”
  Answer with: “It is withdrawn in the governing revision; see SSP/control matrix entry.” ¹
• “Show me where you addressed 03.13.03 in your SSP.”
  Have the SSP table row ready.
• “Your contract references 03.13.03; how do you comply?”
  Show the dependency check, the contract excerpt, and your mapping/clarification note. ¹
• “How do you ensure withdrawn items don’t disappear from your control library?”
  Show your control governance procedure and annual refresh checklist.

Frequent implementation mistakes and how to avoid them

Mistake	Why it hurts	Avoid it by doing this
Deleting 03.13.03 from the control list	Creates an unexplained gap; assessor may flag incompleteness	Keep the row, mark “Withdrawn,” add rationale 1
Writing a custom control to “cover” 03.13.03	You can’t cite a withdrawn control statement; invites scope creep	Only document withdrawal; map any real security need to existing active requirements
Leaving old references in policies/contracts	Creates conflicting obligations across documents	Run a repository search and remediate hits with change control
Claiming “Not Applicable” instead of “Withdrawn”	“N/A” implies scoping; “Withdrawn” is revision status	Use the exact disposition “Withdrawn” 1
No evidence trail	Auditors accept withdrawal, but not silence	Retain SSP row + control register + dependency check output

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, and NIST SP 800-171 is a framework baseline rather than a penalty schedule. Your real risk is assessment failure or contractual noncompliance due to documentation inconsistency: the withdrawn requirement becomes a “paper cut” that slows certification/award processes and increases scrutiny across the rest of your control environment. ¹

Practical 30/60/90-day execution plan

Next 30 days (stabilize documentation)

• Add 03.13.03 to your control register as Withdrawn with rationale and citation. ¹
• Update SSP tables/appendices to show the same disposition.
• Create a single “Withdrawn requirements handling” note that you can reuse across assessments.

Next 60 days (remove dependency risk)

• Search contracts, flowdowns, and policy repositories for “03.13.03.”
• Open change tickets for each hit: update references or add mapping notes where updates aren’t possible.
• Align third-party artifacts that cite requirement numbers (shared responsibility matrices, provider control mappings) to remove stale references.

Next 90 days (make it repeatable)

• Add a control-governance step to your SSP refresh process: verify withdrawn items remain documented and consistent.
• Put a simple QA check in your GRC workflow (or Daydream control review): any control marked “Withdrawn” must have an SSP pointer and a dependency-check artifact.
• Train control owners and technical writers: “Withdrawn means document only; do not implement a phantom control.” ¹

Frequently Asked Questions

Do I need to implement anything for the 03.13.03: withdrawn requirement?

No standalone technical or procedural control is required because the requirement is withdrawn in NIST SP 800-171 Rev. 3. Your obligation is to document the withdrawal and keep your SSP/control matrix consistent. ¹

Should 03.13.03 appear in our SSP even though it’s withdrawn?

Yes, include it with the disposition “Withdrawn” so an assessor can reconcile numbering and see you did not skip it accidentally. Keep the rationale short and reference the governing revision. ¹

What if a prime contractor or customer contract still references 03.13.03?

Treat it as a contracting dependency: document the reference, seek clarification or update the citation, and maintain a mapping memo in your assessment package. Do not invent a control statement for a withdrawn requirement. ¹

Is “Withdrawn” the same as “Not Applicable”?

No. “Not Applicable” is a scoping decision for your environment, while “Withdrawn” is a status in the standard’s revision history. Use “Withdrawn” for 03.13.03. ¹

What evidence is enough to satisfy an assessor?

A control register entry and an SSP row marked “Withdrawn,” plus a quick repository search record showing you checked for lingering references, is typically sufficient. Keep it easy to navigate and consistent across artifacts. ¹

How should we track withdrawn requirements in Daydream (or another GRC tool)?

Keep the requirement in the library, set status to “Withdrawn,” and attach the SSP pointer plus a short note and dependency-check evidence. That structure prevents future template changes from reintroducing confusion during assessments. ¹

Footnotes

1. NIST SP 800-171 Rev. 3