03.14.08: Information Management and Retention

To meet the 03.14.08: information management and retention requirement, you must define how you create, store, classify, retain, and dispose of information (especially CUI) and prove those practices run in production. Operationalize it by publishing retention rules, enforcing them in systems (email, file shares, SaaS, backups), and keeping audit-ready evidence of retention and disposal actions. ¹

Key takeaways:

• Write retention and disposal rules that explicitly cover CUI, system-of-record locations, and third-party holdings. ¹
• Enforce retention through technical controls (holds, deletion workflows, backup handling), not “policy only.” ¹
• Keep evidence that retention is configured and operating: schedules, holds, disposition logs, and exceptions. ¹

03.14.08 sits in the “system and information integrity” family of expectations, but operators experience it as an information governance requirement: you need to control the information lifecycle from creation through retention and defensible disposition. For federal contractors and any nonfederal organization handling Controlled Unclassified Information (CUI), the operational goal is straightforward: keep information as long as required for mission, contracts, and legal needs, and securely dispose of it when it is no longer needed. ¹

Assessors commonly fail organizations here for two reasons. First, retention rules exist in a policy binder but aren’t implemented across real repositories like M365/Google Workspace, endpoint caches, SaaS collaboration tools, ticketing systems, and backups. Second, teams cannot produce evidence that retention and disposal are consistent, repeatable, and scoped to CUI. ¹

This page gives requirement-level implementation guidance you can execute quickly: what to decide, what to configure, what to document, what evidence to retain, and how to prepare for assessment questions without overbuilding.

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.14.08 (Information Management and Retention).” ¹

Operator interpretation: You need a defined, implemented, and provable process to manage information and retain it for required periods, with secure disposal at the end of the lifecycle, across the environments where CUI is stored or processed. Your implementation must cover both internal systems and relevant third parties that store or process CUI on your behalf. ¹

Plain-English meaning (what an assessor expects)

An assessor is looking for three things:

1. Rules: documented retention and disposal requirements that reflect your contracts, legal obligations, and business needs, and that explicitly address CUI. ¹
2. Enforcement: technical and procedural controls that make the rules real in day-to-day operations (retention labels, holds, controlled deletion, backup handling, and third-party constraints). ¹
3. Proof: records that show the rules are configured and operating, plus an exception/hold process that prevents improper deletion. ¹

Who it applies to

Entities

• Federal contractors and nonfederal organizations handling CUI in nonfederal systems. ¹

Operational scope (where this shows up in practice)

Include every place CUI can land, intentionally or accidentally:

• Collaboration and file platforms (SharePoint/OneDrive, Google Drive, Box)
• Email and messaging (Exchange, Gmail, Teams/Slack retention)
• Endpoints (local copies, synced folders, downloads)
• Ticketing and engineering systems (Jira, ServiceNow, Git, build logs)
• Backups and archives (backup vaults, immutable storage, endpoint backup)
• Third parties (managed service providers, eDiscovery/forensics providers, cloud hosting, payroll/HR if CUI ever flows there) ¹

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

Step 1: Build a CUI-focused data inventory (minimum viable)

Create an “information map” that answers four questions for each repository:

• What information types are stored here (call out CUI explicitly)?
• Who owns it (business owner + system owner)?
• What is the system of record (source of truth)?
• What is the retention rule and disposal method? ¹

Practical tip: start with the systems that are “quietly authoritative” (email, shared drives, SharePoint, ticketing, backups). These are where retention failures usually live.

Step 2: Define retention requirements and triggers

Document retention rules as a table that includes:

• Record/information category (e.g., “CUI program deliverables,” “CUI incident reports,” “engineering change requests,” “contracts”)
• Retention duration trigger (e.g., “after contract close,” “after last activity,” “after employee separation”)
• Disposition action (delete, archive, destroy, transfer)
• Hold conditions (litigation hold, investigation hold, contract hold)
• Approved storage locations (systems permitted for the category) ¹

If you don’t have strong legal/commercial retention requirements yet, define business-driven minimums and iterate. Assessors care that you have a rational rule set and that you apply it consistently. ¹

Step 3: Implement retention controls in systems (don’t stop at policy)

Your goal is “default enforcement” with exceptions controlled.

Common technical implementations:

• M365/Google: retention labels, retention policies, mailbox retention, shared drive retention, and eDiscovery holds.
• File servers/NAS: folder-level retention with administrative deletion controls, plus periodic disposition workflow.
• Ticketing systems: project retention schemes, closed-ticket retention, attachment retention controls.
• Backups: retention periods aligned to policy, plus a documented approach for secure disposal and handling of legal holds. ¹

Third party controls: Update contracts and onboarding checklists so third parties:

• store CUI only in approved systems,
• meet your retention rules (or stricter),
• support legal holds,
• provide deletion/destruction attestations when requested. ¹

Step 4: Establish a legal hold / investigation hold workflow

You need a simple process that:

• authorizes who can place/remove holds,
• defines what systems are in scope when a hold is issued,
• requires confirmation that holds are implemented,
• records hold start/end and impacted repositories. ¹

If your org doesn’t have in-house counsel, route holds through the CCO, security lead, or an authorized executive, and document the delegation.

Step 5: Run recurring disposition with approval and logging

Set up a repeatable cycle:

• identify candidate data past retention,
• validate no hold applies,
• approve disposition (data owner),
• execute deletion/destruction,
• capture logs/attestation and exception notes. ¹

Step 6: Make it assessable (map requirement → controls → evidence)

Create a one-page control narrative for 03.14.08 that points to:

• the policy section,
• the retention schedule table,
• the system configurations,
• the operating records (logs/tickets),
• the exception/hold register. ¹

Daydream fits naturally here as the system to keep the mapping tight and evidence collection repeatable: store the control narrative, assign repository owners, schedule evidence requests, and keep artifacts versioned so you can answer assessor questions without a scramble. ¹

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Governance artifacts

• Information Management & Retention Policy (approved, current)
• Retention schedule (table) with categories, triggers, and disposition methods
• Data/information map (systems, owners, CUI scope)
• Roles and responsibilities (data owners, IT admins, records manager, legal/hold authority) ¹

Technical configuration evidence

• Screenshots/exports of retention policies and label configurations (M365/Google/SaaS)
• Backup retention settings and deletion/disposal procedure
• Access controls around deletion (who can purge, how approvals work) ¹

Operational run evidence

• Disposition runbooks and completed tickets/approvals
• Deletion/destruction logs or attestations (including for third parties)
• Hold register and hold implementation confirmations
• Exception register (what, why, approval, expiry date) ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me where CUI is stored and the retention rule for each repository.” ¹
• “How do you prevent a user or admin from deleting CUI that must be retained?” ¹
• “What happens when a legal hold is issued? Show evidence of a hold executed in systems.” ¹
• “Do your backups retain data longer than policy? If yes, why, and how do you handle disposal?” ¹
• “Which third parties store your CUI, and how do you ensure they follow your retention and deletion requirements?” ¹

Hangups that slow assessments:

• retention exists only for email but not for file shares, chats, tickets, engineering systems, or backups,
• “we delete on request” with no logs or approvals,
• retention categories too generic to map to repositories and contracts. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating backups as out of scope.
   Fix: document backup retention explicitly and align it to the retention schedule, with a clear hold story. ¹

2. Mistake: No authoritative “system of record.”
   Fix: assign one system as the recordkeeping source per CUI category; treat other copies as convenience copies with tighter retention where feasible. ¹

3. Mistake: No exception management.
   Fix: keep a simple exception register with approval, scope, compensating control, and an expiry review. ¹

4. Mistake: Third parties can retain data indefinitely.
   Fix: contract clauses and offboarding checklists that require return/destruction and attestations. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program on case law. Your practical risk is assessment failure or contractual noncompliance if you cannot show retention is defined, implemented, and evidenced across CUI repositories and third parties. ¹

Operational risk is also real: poor retention increases breach impact (too much data kept) and impairs investigations and contract performance (data deleted too early). Treat 03.14.08 as both a security and governance control. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Confirm where CUI exists (initial inventory across top repositories). ¹
• Publish a retention schedule table with owners, triggers, and disposition methods. ¹
• Stand up a legal/investigation hold workflow and a hold register template. ¹
• Pick one evidence approach (ticketing + folder, or Daydream) and start capturing artifacts in one place. ¹

By 60 days (implement controls where it matters most)

• Configure retention and deletion controls in your primary collaboration suite and email. ¹
• Document backup retention and disposal procedures, including how holds affect backups. ¹
• Update third-party templates: CUI location restrictions, retention obligations, deletion attestations, and offboarding steps. ¹

By 90 days (prove operation)

• Run a real disposition cycle for at least one repository and capture the approvals and logs. ¹
• Test a hold end-to-end (issue, implement in systems, document, release). ¹
• Build the assessor packet for 03.14.08: narrative, mapping to systems, screenshots/exports, sample tickets, hold register, and exception register. ¹

Frequently Asked Questions

Does 03.14.08 require specific retention periods for CUI?

The provided requirement reference does not specify exact durations; it requires that you manage and retain information under defined rules and prove they operate. Set retention periods based on contracts, legal needs, and mission requirements, then enforce them across repositories. ¹

Are backups part of “information retention” for this control?

Yes in practice, because backups preserve information and can defeat your disposal objectives if unmanaged. Document backup retention, align it to your retention schedule, and keep evidence of configuration and disposal actions. ¹

What’s the minimum evidence an assessor will accept?

Provide a retention policy/schedule, proof of system configuration (exports or screenshots), and operational records that show retention and disposition happening (tickets/logs) plus a hold/exception mechanism. If you can’t show operating records, expect a finding. ¹

How do we handle CUI copied into email, chat, or tickets?

Define approved repositories as systems of record and apply retention policies to collaboration tools to control convenience copies. Train users and implement technical restrictions where feasible, then rely on retention/holds to prevent premature deletion. ¹

What do we need from third parties to satisfy 03.14.08?

You need contract terms and operating proof that third parties store CUI only as authorized, follow your retention rules (or stricter), support holds, and can attest to deletion/destruction on request or at offboarding. Keep those attestations and offboarding records. ¹

We can’t technically delete individual records from immutable backups. Is that a failure?

Not automatically. Document the constraint, define how long immutable backups are kept, how holds are handled, and how disposal occurs at end of retention; track it as an approved exception if it deviates from standard rules. Keep evidence of the exception approval and the backup retention configuration. ¹

Footnotes

1. NIST SP 800-171 Rev. 3