03.14.08 Information management and retention

03.14.08 information management and retention: what the requirement asks for

Requirement 03.14.08 asks the organization to manage and retain controlled unclassified information (CUI) within the system, and the CUI output from it, in line with applicable laws, Executive Orders, directives, regulations, policies, standards, guidelines and operational requirements. If you own a system that holds CUI, this means you must be able to show that the system keeps CUI only as long as the governing rules allow, stores it where those rules permit, and releases output only when a rule says it may leave. The risk is threefold: CUI kept longer than needed, CUI kept in the wrong place such as an unmanaged file share or a backup nobody tracks, and CUI released in reports, exports or printouts with no rule behind the release.

The requirement is hard because the retention and handling rules come from outside the system. Contract clauses, agency agreements, the CUI authorities that apply to a given category, and your own records policies each set expectations, and none of them configures a server or an application. The organization has to translate those rules into system behavior: retention periods applied to specific repositories, disposition steps that actually run, and output controls on exports and shared links. Start by listing which CUI categories the system holds and which sources set their rules, then confirm with your contracting officer or agency sponsor which rules govern your data. Those confirmations are the inputs an assessor will ask to see.

03.14.08 is new in Rev. 3. NIST's change analysis lists it as one of the 19 requirements added in that revision and maps no Rev. 2 requirement to it. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID for 03.14.08. DoD contractors remain assessed against Rev. 2 under current DoD direction, so a Rev. 3 gap in this area will not show up in a CMMC Level 2 check, but a contracting officer or agency that adopts Rev. 3 may still ask about it. NIST lists SI-12 from SP 800-53 Rev. 5 as the source control. When you read the NIST and SP 800-53 texts to plan your work, use them to understand the requirement and write your own procedures in your own words, rather than copying control language into your policies.

Which systems, records and CUI outputs fall under 03.14.08

Requirement 03.14.08 reaches beyond the data store itself. It covers CUI kept in systems, the CUI that systems produce, the records teams that decide how long material lives, and outside parties that hold CUI on your behalf. Work through these six decisions before you write the retention procedure, because each one changes who must follow which rule.

Systems that store or process CUI

Start with the system boundary in your system security plan and list every platform where CUI is created, stored, processed or transmitted. For each one, record the data sets it holds and the retention period that applies. Self-hosted collaboration tools such as XWiki, BookStack and Nextcloud can hold CUI in documents and attachments, so their version history, trash and file lifecycle settings belong in scope. Confirm the retention rule for each data set with the contracting officer or your counsel before you set a default.

CUI output from the system

The requirement also covers CUI that leaves the system: reports, spreadsheet exports, printouts, email attachments, screenshots and backup copies. Each output type can outlive the source record and escape the retention schedule. Map where outputs are generated, who can create them, and where they land. Access rules such as download and sync restrictions can limit output paths, but they do not replace a disposition decision for the copies that already exist.

Backups and archived copies

Backups hold CUI long after production data is deleted, so retention for backup sets must match the rules for the originals. Decide how long each backup tier is kept, where it is stored, and how expired sets are destroyed. Check whether restored data is subject to the same disposition rules. Ask your backup vendor or internal team to document deletion and rotation schedules, and include them in your retention evidence.

Records and disposition teams

Assessors interview the people who manage information, records and disposition. Name the records owner, the approver for disposition, and the team that runs deletion. Confirm that these roles know which laws, contract terms and agency agreements apply to each data set. Where legal hold applies, the disposition team must be able to pause destruction. Document who approves each category of disposal and keep the approvals as evidence.

Governing rules and their owners

The retention period comes from the contract, the CUI category and any agreement with the federal agency, not from a single NIST setting. Build a register that lists each applicable law, Executive Order, directive, contract clause and internal policy, with its owner and the data sets it covers. Where two rules conflict, record the decision and who made it. Without this register, the examine and interview steps for 03.14.08 are hard to pass.

Third parties that hold CUI

Cloud providers, managed service providers, e-discovery vendors and offsite storage firms may hold CUI for you. Their retention and deletion practices become part of your retention story. Identify each third party that stores or processes CUI, obtain their retention and destruction terms in writing, and confirm how they certify deletion. Ask whether the contract with each provider reflects the rules that apply to your data sets.

How an assessor tests 03.14.08

This table compares the three assessment methods SP 800-171A Rev. 3 uses for 03.14.08, the objects each method reviews and the findings assessors commonly record. Read it as a checklist of what to have ready before an assessor arrives, since 03.14.08 is assessed with four determination statements and each method must produce evidence that the retention and disposition rules are actually applied.

Method	Objects the assessor reviews	Common findings
Examine	System and information integrity policy and procedures; the laws, Executive Orders, directives, regulations, standards, policies and operational requirements that govern information management and retention	Retention rules exist only in a policy document and are not reflected in system configuration or records schedules
Interview	Personnel with information management, records management, retention and disposition responsibilities	Staff cannot explain which CUI categories have retention periods or who approves disposition
Test	Processes for information management, retention and disposition, run against the system	No evidence that disposition actually ran, such as deletion logs, purge reports or expired-data sampling
Examine (output)	Rules governing CUI produced by the system, such as exports, reports and downloads, and how those rules are documented	Output channels such as email, shared drives or exports are not covered by any retention or marking rule
Interview (ownership)	Owners of the CUI categories held in the system and the people who decide what must be kept or destroyed	Ownership is unclear, so disposition decisions default to whoever administers the platform
Test (exceptions)	Legal hold, litigation or contract-driven retention exceptions and how they override scheduled disposition	Holds are applied informally without a record of scope, start date or release

How to implement 03.14.08 in order

This sequence turns the 03.14.08 requirement into a documented, enforced and tested retention and output process, with each step producing evidence an assessor can examine. It starts with the rules that apply to the CUI and ends with the decisions recorded in the system security plan.

Identify governing laws and operational requirements
Start by listing every law, regulation, contract term, agency policy and internal operational need that governs each category of CUI the system holds. The contracting officer or the federal agency that owns the contract or agreement should confirm which requirements apply, because NIST places application and compliance responsibility with that agency. Your privacy, records and legal teams should review the list. This step is complete when each CUI data set has a named source of authority and a short written rule set that the organization can point to. If the OSCAL catalog ODP values for 03.14.08 are defined by the agency, confirm them in the OSCAL catalog before you rely on them, because an unassigned value leaves the requirement incomplete.
Map each rule to retention and disposition
Build a retention schedule that translates each rule from the first step into a retention period, a trigger for when that period starts, and a disposition action such as return to the agency, sanitization, or destruction. Record which system holds each data set and where backups and copies sit, since disposition must reach all of them. Ask the federal contract owner to approve periods that come from contract terms. Done means the schedule is approved, versioned and covers every CUI location in the system boundary.
Configure enforcement and flagging controls
Configure the system to enforce the schedule where the platform allows it, and to flag records that reach a retention trigger or disposition date where it does not. Typical controls include access rules that block upload, download or sync for designated content, version history that preserves an audit trail of changes, and tagging that marks CUI so retention rules can find it. Confirm each capability in the product documentation before you claim it in the system security plan. Done means each rule in the schedule has a named control, a test that shows the control works, and a record of the test result.
Define approval or blocking for CUI output
Define how CUI leaving the system is approved, logged or blocked. This covers exports, reports, printed or emailed extracts, and files sent to outside parties. Specify who may approve each output type, what the approval record must contain, and what the system blocks by default. Coordinate with the owners of the media protection and system communications procedures so the rules do not conflict. Done means a written output procedure exists, approvers are named, and a sample output has been run through the process with its approval recorded.
Assign owners for disposition decisions
Name an accountable owner for each data set and a backup who can make disposition decisions when the owner is unavailable. Owners should be people who understand the business purpose of the data, not only system administrators. Document their duties, including approving holds for legal or contract reasons and signing off on destruction. Give the owners a short training note covering the schedule and the decision log. Done means every data set has a current owner, a backup and a signed or recorded acceptance of the role.
Run and log a first disposition cycle
Run one controlled disposition cycle on a limited set of records that are due for action, or on a clearly labeled test data set if no live records are due. Record what was found, who approved each action, the method used, and the result, including any exceptions or holds. Keep the log in a location with access controls and retention of its own. Done means the cycle is complete, the log entries are complete, and any gaps found are assigned to an owner with a fix date.
Record decisions in the system security plan
Update the system security plan with the schedule, the enforcement and flagging controls, the output procedure, the owner roster, the disposition log location and the results of the first cycle. Describe how the implementation meets the 03.14.08 determination statements, and reference the evidence for each. Ask an independent assessor or the federal contract owner to review the wording before the plan is finalized, because only an independent assessor issues assessment results. Done means the plan is approved internally and each claim points to evidence that exists.

How self-hosted open-source platforms can produce 03.14.08 evidence

Self-hosted open-source platforms can produce useful evidence for 03.14.08, but none of them satisfies the requirement on its own. The requirement asks the organization to manage and retain CUI within the system and CUI output from it in line with the laws, policies, standards and operational requirements that apply to it. The assessor will look for a documented retention and disposition policy, the people who own it, and proof that the system behaves the way the policy says. Wiki, document and file tools can supply parts of that proof, as long as the organization decides what the rules are first.

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and it lets users compare any two versions and roll back to an earlier one. This suits the retention and disposition policy itself and its approval history. An assessor can ask to see the version in force on a given date and the record of who approved it. XWiki is licensed under LGPL-2.1-or-later. Confirm with your own team that the version history is retained for the period your policy requires and that it is backed up with the rest of the system.

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Used this way, it can show documented ownership: which role owns the retention schedule, which role may edit it, and which role may view records that carry CUI. Nextcloud's File Access Control app, licensed under AGPL-3.0-only, can deny upload, modification, deletion, download and sync when rules match user group, IP address, collaborative tags, MIME type, file name, request time or user agent. These controls support the handling of CUI output, such as blocking downloads outside approved networks. None of these tools sets a retention period or performs disposition by itself. Before relying on them, confirm each tool's capability against your own disposition and deletion workflow, and document where the tool stops and a manual or contracted process begins.

Evidence that passes 03.14.08 and how to keep it current

An assessor testing 03.14.08 wants to see that retention and disposition rules exist, that the system enforces them, and that people actually carry them out. The cards below cover the artifacts that show each of those three things, with the refresh cadence and sign-off each one needs between formal assessments.

Approved retention schedule mapped to obligations

This is the document that states what CUI is kept, for how long, and why. Each retention period should trace to a law, Executive Order, regulation, contract clause or operational need, which is what the 03.14.08 determination statements ask an assessor to examine. Check that every CUI category in the system has a line in the schedule and that the owner of each line is named. Refresh it whenever a contract with new retention terms is signed and at least once a year. The records officer or legal counsel signs it, and the system owner acknowledges it.

System configuration exports for retention and access

Exports from the platform showing retention settings, deletion jobs, and the access rules that govern who can read, move, export or purge CUI give an assessor something to test rather than only read. Capture them with a timestamp and the configuration version, and compare each export against the approved schedule. Any gap between the two is a finding. Re-export after every change to storage, backup or identity settings, and review the set quarterly. The platform administrator prepares the export and the security lead signs it off.

Disposition logs

Disposition logs record when CUI was deleted, archived or transferred, which records were involved, the authority for the action, and who performed it. They show the retention rules were applied in practice, which the test objects for 03.14.08 target. Confirm that logs are complete, cannot be edited by the people whose actions they record, and cover backups and copies held in other locations. Review them monthly and reconcile sampled entries against the schedule. The data owner approves disposition batches and the security lead reviews the monthly reconciliation.

Output approval records

CUI output includes reports, exports, printouts and files sent from the system, and 03.14.08 covers that output as well as stored data. Approval records show who authorized each release, the marking applied, and the recipient or destination. Sample them against outbound transfer logs to find releases with no approval. Refresh the approval workflow whenever recipients or marking rules change, and sample records at least quarterly. The information owner signs off on the workflow, and the compliance lead reviews the sampled records.

Role and ownership assignments

A named role for each retention and disposition task shows who is accountable when something goes wrong. The assessor will look for people with records, retention and disposition responsibilities, so the assignments must match the people who actually run the work. Keep an up-to-date matrix listing each task, the role holder, and the backup. Update it whenever staff change roles or leave, and verify it at least quarterly against the directory. HR and the system owner sign it off.

Interview-ready records of disposition operators

Interviews are one of the three assessment methods for 03.14.08, so the people who run disposition must explain the process consistently. Prepare a short record for each operator covering the rules they apply, the escalation path for unclear cases, and the last time they performed or reviewed a disposition. Walk through a sample case with each operator before an assessment. Refresh the records after any process change and at least annually. The security lead confirms each record and the operator acknowledges it.

What meeting 03.14.08 costs in money and effort

This table compares the cost components of meeting 03.14.08, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations were supplied, so use the drivers to scope a quote and to ask your provider for a written breakdown. Open-source platforms carry no license fee, but the implementation and upkeep work below still applies.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Retention schedule and policy work	Legal, records and compliance staff, sometimes with outside counsel	One-time, then periodic review	Number of CUI data sets, number of governing contracts and laws, and how many record types need separate rules
Engineering time for retention rules and logging	Internal platform engineers or an implementation partner	One-time build, then recurring changes	Number of systems and CUI outputs, how many access and deletion rules must be configured, and whether retention is already automated
Evidence upkeep	Internal operations or compliance staff	Recurring	Frequency of disposition runs, volume of retained logs and version history, and how often schedules change
External review of the retention schedule	Outside counsel or records specialists, if engaged	One-time, with recurring reviews when laws change	Complexity of applicable federal and contractual rules and the number of jurisdictions or agencies involved
Assessor effort for interviews and testing	The independent assessor, paid under the assessment engagement	Recurring with each assessment cycle	Number of personnel with records responsibilities to interview and number of retention processes to test
Contract-specific rule variations	Internal staff who map each contract to a retention rule	Recurring as contracts change	How many contracts set different retention or disposition rules for the same CUI

Who owns retention decisions, who builds the controls and what the auditor tests

The organization owns the retention rules for CUI in its system and for CUI output from it. Records management, legal, system owners and security staff decide which laws, contract terms and operational requirements apply, how long each category of CUI is kept, and how it is disposed of once that period ends. The requirement is met only when those decisions are written down, approved and followed, so the organization cannot delegate them to a vendor.

Retention schedule: Records and legal staff define retention periods by CUI category, tied to the contract, the CUI category authority and any operational need.
Approval and disposition: Named owners approve exceptions, legal holds and destruction of CUI, and the approvals are recorded.
Output rules: Security and system owners decide what CUI may leave the system in reports, exports and printouts, and under what conditions.
Personnel training: Staff with records, retention and disposition duties know the schedule and their approval role.
Federal agency duties: NIST states that application of SP 800-171 and any compliance issues rest with the federal agency that holds the contract or agreement, so confirm with the contracting agency what it expects.

Before engaging anyone, confirm that the retention schedule exists in writing and has a named owner.

Where 03.14.08 assessments usually fail

Assessors testing 03.14.08 look for retention rules that the system enforces, disposition records that prove decisions were carried out, and CUI leaving the system through every channel. The gaps below are the ones that most often leave an organization unable to show evidence, and each card pairs a gap with the check that closes it.

Retention rules exist only on paper

The retention schedule sits in a policy document, but no system setting, tagging rule or workflow applies it to the CUI stored in the system. An assessor interviewing records staff will ask how the schedule is enforced, and a policy alone answers that question poorly. Check that each CUI repository has a configured retention rule or a documented manual step with an owner, and that the rule matches the schedule in the policy.

No disposition has ever run

Many systems hold CUI that has passed its retention period, but no one has ever deleted, archived or sanitized it, so there is no record of a disposition. Assessors test the process for information management, retention and disposition, and an empty log leaves nothing to examine. Run a supervised disposition cycle on a test set, keep the approval, the action taken and the result, and repeat it on a set schedule.

CUI output channels left out

03.14.08 covers CUI output from the system as well as CUI stored in it. Email attachments, bulk exports, reports, printouts and file shares often sit outside the retention design, so copies persist after the source record is disposed of. Inventory each output channel, state how long its copies may exist, and confirm that the access and file controls in the system enforce that limit where the platform supports them.

Backups and collaboration copies missed

Retention is applied to the primary database or file store, while backup sets, sync clients, shared links and collaboration spaces keep older CUI for years. The disposition then does not reach every copy the organization holds. Document where copies exist beyond the primary system, set a retention period for each, and confirm that backup expiry and sync deletion follow the same schedule as the source record.

Disposition decisions have no owner

When no named role approves disposition, records either sit indefinitely or are removed without a decision on record. Assessors interview personnel with records and retention responsibilities, and vague answers about who decides are a common finding. Assign the approval role in writing, define who executes the action, and record who approved each disposition and when, so the decision can be traced.

Only Rev. 2 or CMMC IDs mapped

03.14.08 is new in Rev. 3, and NIST maps no Rev. 2 requirement to it. Teams that build their evidence matrix from Rev. 2 or CMMC Level 2 identifiers never reach this requirement, even when their practices are sound. Map the Rev. 3 requirement directly, using its four determination statements, and confirm with the contracting agency which revision applies to the contract before choosing the assessment baseline.

What buyers ask about 03.14.08 cost, time and scope

How much more effort does 03.14.08 add compared with other 03.14 requirements?

Usually less effort in the technical sense, but more coordination. 03.14.08 is a governance and records requirement rather than a tooling one, so it asks for documented rules on what CUI the system holds, how long it is kept, how it is disposed of and how CUI leaving the system in outputs is handled. The sibling requirements on flaw remediation, malicious code protection, alerts and system monitoring tend to be met largely through patching processes, endpoint protection and logging that many organizations already run. The effort for 03.14.08 depends on how much records management already exists. An organization with a retention schedule and disposition process has a short gap to close. One without either will spend most of its effort on defining rules that other teams must then follow. Ask your assessor or partner which of the 03.14 requirements already have evidence in your environment before comparing effort.

Can our own team implement 03.14.08 without an outside partner?

Often yes, if the team has someone who can write retention and disposition rules and the authority to get them applied. The work is mostly definition and evidence: identifying where CUI lives, agreeing retention periods with the people who own the obligations, configuring the systems that enforce them and recording that disposal happened. Those tasks sit with the organization, which owns its controls. An outside partner can help with the technical configuration and evidence collection, but the organization still has to make the decisions. Outside help is most useful when the team lacks records management experience, when retention rules conflict across contracts, or when the same rules must be applied across several self-hosted platforms at once. Any engagement should begin with written scope so that responsibilities are clear from the start.

How long does 03.14.08 take, and what drives the timeline?

No fixed duration applies to 03.14.08, because the time depends on the starting point. Four factors matter most: how many systems and data stores hold CUI, whether retention periods are already written down, how many legal or contractual sources set obligations, and how quickly system owners can change configurations. Organizations with a clear inventory of CUI locations and an existing schedule move faster. Organizations that must first find out where CUI sits, or that must reconcile conflicting requirements, need more time for discovery before any configuration starts. Ask for a timeline that lists the discovery, policy approval, configuration and evidence stages separately, so that the schedule shows where waiting on other teams will slow the work.

What does 03.14.08 need from legal, records and system owners?

It needs decisions that only those roles can make. Legal or contracting staff identify which laws, contract clauses and agency requirements set retention and disposition obligations for CUI. The records or information management function defines the schedule, the disposition method and the approval steps. System owners confirm where CUI is stored and output, and they configure or accept the technical controls that enforce the rules. Security or compliance staff track how these decisions map to the requirement and collect the evidence. The organization should record who approves each rule. A partner can draft documents and configure systems, but it cannot decide legal obligations, so those inputs must come from the organization.

Is 03.14.08 assessed for DoD contractors if CMMC Level 2 has no matching requirement?

Confirm this with your contracting officer and assessor before relying on any answer. NIST mapping shows that 03.14.08 is new in Rev. 3 and has no Rev. 2 requirement behind it, so CMMC Level 2, which assesses the 110 Rev. 2 requirements, has no matching ID for it. A DoD contract may still name a specific revision of SP 800-171 in its clause, and recent DoD guidance has pointed to Revision 2 for baseline compliance. Because the applicable revision and any future FAR changes can shift, the safe planning approach is to read the clause in your contract, ask the contracting officer which revision governs, and prepare evidence for 03.14.08 in case a later revision applies. Note that assessment bodies decide what they test under their own procedures.

What should we ask a partner for in a fixed-scope quote for 03.14.08?

Ask for a written scope that names the systems and data stores in scope, the retention and disposition rules to be produced, the configuration work on each platform, and the evidence the partner will prepare for each determination statement in the assessment procedure. The quote should list deliverables, what the organization must provide, the assumptions about existing records policy, and what is excluded, such as legal review or the assessment itself. Ask who owns each deliverable and how changes to scope are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and any quote follows from that written scope. Note that DeployOpen prepares systems and evidence but does not issue assessment reports or certifications; an independent assessor does that work.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the systems and records that show how CUI is managed and retained for 03.14.08. Your organization owns the retention rules and the decisions behind them, and an independent assessor reaches the conclusion on the requirement.

How we scope

Agree in writing which systems hold CUI and which CUI outputs leave them, such as reports, exports and printed material.
Confirm with your team which laws, contract terms and internal standards set the retention and disposition periods that apply.
Record the named roles responsible for information management, retention and disposition, so interview evidence has a clear owner.

How we build

Configure document and file platforms so CUI records keep version history showing what changed, when and by whom.
Set role-based permissions and access rules so only authorized users can upload, modify, download or delete retained CUI.
Document the disposition process for CUI output, including how records are archived, reviewed and removed at end of retention.

How we hand over

Deliver the written retention and disposition procedure, mapped to the four determination statements in SP 800-171A Rev. 3 for 03.14.08.
Provide configuration records and screenshots that show retention, versioning and access rules as they operate in your environment.
Walk your assessor and staff through the evidence set so interview answers match the documented process and the system behavior.

How we support

Support ongoing review of retention settings whenever contract terms, applicable laws or your operational requirements change.
Continuous testing and upgrades of the platforms that hold CUI are available as a retainer after handover.
Updates to evidence follow your assessment cycle, so the record stays current between formal assessments.