A Contract Data Requirements List, or CDRL, identifies the data that a Department of Defense contractor must deliver under a contract. It defines each deliverable’s title, governing instructions, delivery schedule, approval requirements, recipients and other administrative details.
The Government normally documents a CDRL on DD Form 1423 or DD Form 1423-1 and incorporates it into the solicitation and resulting contract as an exhibit. Once incorporated, its delivery requirements are contractual. Therefore, program teams should manage CDRL dates with the same discipline they apply to hardware deliveries, reviews and other contract commitments.
What Is a Contract Data Requirements List?
A CDRL is the standardized format DoD uses to identify potential data requirements in a solicitation and deliverable data items in a contract. The Defense Federal Acquisition Regulation Supplement at DFARS 215.470 directs contracting officers to include DD Form 1423 when data must be delivered under a contract.
A CDRL can require management, engineering, logistics, test, software, cost, schedule or other program data. Common examples include:
- Integrated Master Schedule submissions
- Systems engineering plans
- Monthly status and cost reports
- Test plans, procedures and reports
- Technical manuals and engineering drawings
- Configuration management reports
- Risk and opportunity registers
- Review packages for the System Requirements Review, Preliminary Design Review or Critical Design Review
- Software documentation and data dictionaries
The exact list varies by contract. A CDRL used on one program does not automatically apply to another program, even when the programs acquire similar products.
How the CDRL, DID and SOW Work Together
The Contract Data Requirements List does not work alone. A well-formed data requirement usually connects three elements: the contractual task, the content instructions and the delivery instructions.
The SOW defines the work
The Statement of Work (SOW) defines what the contractor must perform. For example, the SOW may require the contractor to develop and maintain a systems engineering management plan.
The SOW should establish the underlying task. However, it should not conflict with the CDRL’s delivery dates or administrative instructions. For more detail on organizing contractual work, see how the WBS connects to the Statement of Work and the comparison of a SOW, PWS and SOO.
The DID defines the data content
A Data Item Description (DID) defines the intended use, format and content of a data product. The CDRL commonly identifies the applicable DID in its authority field.
For example, a DID may identify the required sections of a management plan. The CDRL can then tailor the requirement for the specific acquisition. According to the Defense Acquisition University CDRL Planning Tool, acquisition teams should develop CDRLs through a deliberate cross-functional process instead of copying requirements from an unrelated contract.
Not every data item relies on a standard repetitive-use DID. The contract may cite another authorized source or a properly developed one-time data requirement. Therefore, teams must read the authority identified for each individual CDRL item.
The CDRL defines delivery administration
The CDRL states how and when the contractor must submit the data. Depending on the item, it may specify:
- A unique exhibit line item number
- The data item title and subtitle
- The applicable DID or other authority
- The related SOW or contract reference
- The requiring office
- Whether Government approval is required
- The frequency of submission
- The first and subsequent delivery dates
- Distribution recipients and quantities
- Electronic format or media instructions
- Tailoring, draft-review cycles and other remarks
In simple terms, the SOW answers what work must be performed, the DID describes what the resulting data must contain, and the CDRL states how and when the contractor must deliver it.
A CDRL Is a Contract Exhibit, Not Just a Tracking Log
A CDRL may resemble an administrative register, but it has contractual significance. Under DFARS Subpart 204.71, DD Form 1423 is an exhibit rather than an attachment. An exhibit establishes requirements for deliverables.
This distinction matters during execution. A working spreadsheet may help the contractor track submissions, but that spreadsheet does not replace the contract exhibit. Likewise, an email from a technical representative does not automatically revise a contractual delivery date. Changes to the requirement must follow the contract’s authorized change process.
CDRL exhibit line items also differ from Contract Line Item Numbers (CLINs). A CLIN identifies a separately structured supply or service in the contract schedule. In contrast, the CDRL organizes data deliverables associated with one or more contract requirements. See what a CLIN means in government contracting for a fuller comparison.
Why CDRLs Matter to Schedulers and Program Controls
CDRL dates often create real schedule drivers. A test procedure may need customer approval before testing begins. A design review package may be due several weeks before the review. An Integrated Master Schedule may require monthly delivery shortly after the status date.
However, copying only the final submission date into the Integrated Master Schedule (IMS) provides limited control. When a deliverable affects program execution, the schedule should normally represent the work required to create and release it.
A practical schedule sequence may include:
- Develop the deliverable.
- Receive inputs from engineering, supply chain, finance or other functions.
- Complete an internal quality review.
- Obtain program management approval.
- Submit the draft or final product to the customer.
- Support the contractual review period.
- Resolve comments and prepare revisions.
- Receive approval when approval is required.
This schedule detail is a recommended program-controls practice, not a universal regulatory requirement. The appropriate level of detail depends on risk, duration, customer dependency and the significance of the data item. A routine recurring report may not need a fully developed network. In contrast, a test plan that gates a major event should have clear logic and ownership.
Teams that deliver an IMS under an Integrated Program Management Data and Analysis Report requirement should also distinguish the live scheduling process from the delivered file. The IPMDAR schedule dataset is a contractual submission when required, while the IMS remains the contractor’s time-phased model for managing the work.
Fictional Example: Managing a Review Package CDRL
Assume the fictional Falcon Ridge radar modernization contract includes CDRL item A003, a Test Readiness Review package. The contract requires delivery 20 working days before the Test Readiness Review. It also requires Government approval and allows ten working days for review.
The scheduler should not create a single milestone called “Submit TRR Package” and stop there. Instead, the IMS could include activities for completing test procedures, collecting safety evidence, integrating subcontractor inputs, conducting an internal review and submitting the package.
The schedule should also model customer review and comment resolution if those steps affect the review date. Therefore, the planned Test Readiness Review should remain logically connected to package approval rather than merely sharing a similar calendar date.
If the customer later requests delivery 25 working days before the review, the team should first determine whether the request changes the contractual requirement. The scheduler can model a proposed date for planning purposes. However, the baseline should preserve traceability to the authorized contract direction and the program’s change-control process.
For broader context on acquisition events, see SRR, PDR, CDR, TRR and PRR explained.
CDRL Delivery Does Not Determine Data Rights
A requirement to deliver data does not, by itself, establish unlimited Government rights in that data. Delivery requirements and license rights are related, but they answer different questions.
- The CDRL identifies what data must be delivered and the delivery conditions.
- The applicable contract clauses, assertions and license terms establish the Government’s rights to use, reproduce, modify, release or disclose that data.
DFARS Subpart 227.71 requires DoD acquisition teams to identify necessary technical data, delivery schedules, acceptance criteria and applicable restrictions. It also emphasizes acquiring only the technical data and associated rights needed to satisfy agency needs.
Consequently, program teams should coordinate CDRL development with engineering, contracting, data management, logistics, cybersecurity and intellectual-property specialists. A technically complete CDRL can still leave a major sustainment gap if the Government does not obtain the license rights needed for its planned use.
Common CDRL Failure Modes
Copying a legacy list without validating the need
Teams sometimes reuse a prior program’s CDRLs without confirming the current acquisition strategy. As a result, the contract may demand unnecessary reports or omit data needed for testing, sustainment or future competition.
Conflicting SOW and CDRL instructions
The SOW may require one submission frequency while the CDRL specifies another. The documents may also use different event names or delivery triggers. These conflicts create proposal assumptions and execution disputes.
Using ambiguous relative dates
Instructions such as “before the review” are incomplete unless the contract defines the lead time. A clearer requirement identifies a measurable number of calendar or working days and addresses the applicable calendar when necessary.
Ignoring draft and approval cycles
A final due date may become unachievable when the CDRL also requires a draft, Government review and comment incorporation. Preparers should confirm that the sequence provides enough turnaround time.
Confusing submission with acceptance
Delivery records when the contractor submitted the item. Acceptance or approval records the Government’s contractual disposition. These dates may differ, so schedule logic and performance reporting should not treat them as interchangeable.
Leaving subcontractor data out of the plan
The prime contractor remains responsible for its contractual deliveries. Therefore, the integrated plan should identify supplier inputs that support prime CDRLs and place them early enough for integration and quality review.
Failing to price and resource the work
Data development consumes engineering, editing, analysis, configuration management and review effort. Proposal teams should estimate that effort instead of treating every CDRL as cost-free administration. DFARS 215.470 also addresses estimated data prices and warns against unnecessary duplicate data requirements.
Practical CDRL Review Checklist
Before proposal submission, baseline approval or a major contract modification, the program team should review each data item and ask:
- What contractual task produces this deliverable?
- Does the cited DID or authority match the requested product?
- Has the Government tailored the requirement clearly?
- Are the initial, recurring and final delivery dates measurable?
- Does the requirement distinguish drafts, final copies and revisions?
- Is Government approval required, or is the item submitted for information?
- Are review and comment-resolution periods defined where needed?
- Do the SOW, CDRL, CLIN structure and proposal assumptions agree?
- Does the IMS contain the significant development and delivery events?
- Have subcontractor inputs been planned?
- Are format, media, security and distribution instructions clear?
- Do the contract’s data-rights terms support the intended Government use?
- Has the proposal included the labor, tools and management effort needed to produce the data?
This review should involve more than the scheduler or data manager. CDRLs cross functional boundaries, so contracting, technical, logistics and program-controls personnel should resolve inconsistencies before award whenever possible.
Frequently Asked Questions
Is a CDRL the same as a DID?
No. A Data Item Description defines the content, format and intended use of a data product. The CDRL applies that instruction to a specific contract and establishes delivery details.
Does every internal report belong on the CDRL?
No. Internal working documents are not automatically contract deliverables. For DoD acquisitions, DFARS 215.470 directs use of DD Form 1423 when the contract requires data delivery. The acquisition team should identify minimum essential needs rather than demand every artifact the contractor creates.
Can a CDRL be not separately priced?
Yes, depending on the contract structure. A data item may be separately priced or its price may be included in another priced line item. However, the solicitation and contract should make the treatment clear, and proposal teams should still estimate the resources needed to produce the deliverable.
Should every CDRL appear in the IMS?
Not necessarily. Significant, risk-bearing or event-driving deliveries should usually appear in the IMS with appropriate supporting logic. Low-risk administrative submissions may be controlled in a separate CDRL register. The contract, scheduling instructions and program management needs determine the final approach.
The Bottom Line
A Contract Data Requirements List turns a general need for information into a defined contract deliverable. It connects the work described in the SOW to the content instructions in a DID and the delivery conditions stated on DD Form 1423.
For schedulers and program-controls teams, the central lesson is straightforward: do not manage a CDRL as a detached paperwork list. Identify the work that creates each significant deliverable, model its dependencies, preserve contractual traceability and distinguish submission from customer approval. That approach makes the CDRL useful for execution rather than merely compliant at delivery time.