A Contract Data Requirements List (CDRL) identifies the data that a contractor must formally deliver to the government under a contract. It defines the deliverable, applicable Data Item Description (DID), delivery timing, recipients, approval requirements, and other submission instructions.
When someone asks, what is a CDRL?, the short answer is that it is the contractual delivery mechanism for reports, datasets, plans, drawings, software documentation, test results, schedules, and other required data. On Department of Defense contracts, CDRLs use DD Form 1423 and commonly appear as contract exhibits.
What Is a CDRL in DoD Contracting?
A CDRL converts a program office’s need for information into a defined contract deliverable. The Defense Federal Acquisition Regulation Supplement at 215.470 requires the solicitation to include DD Form 1423 when the contract will require data delivery.
The term can describe the complete Contract Data Requirements List or an individual exhibit line item. Therefore, practitioners often call a specific deliverable, such as A001 or A002, a CDRL.
In the common DD Form 1423-1 structure, each form covers one deliverable and one DID. The Defense Acquisition University CDRL planning tool identifies DD Form 1423-1 as the form most commonly used for this purpose.
A CDRL may require delivery of:
- An Integrated Master Schedule (IMS)
- A program management plan
- Cost and schedule performance data
- Engineering drawings or specifications
- Test plans and test reports
- Software documentation or source code
- Configuration management records
- Technical manuals
- Risk, quality, logistics, or cybersecurity reports
The exact requirements depend on the solicitation, contract, agency, program, and negotiated tailoring. The presence of a familiar report title does not create a standard delivery requirement by itself.
How the CDRL, DID, SOW, and CLIN Work Together
The CDRL does not operate alone. Several contract components work together to define the contractor’s obligations.
Statement of Work
The Statement of Work (SOW) or Performance Work Statement describes the work or required outcome. For example, the SOW may require the contractor to develop, maintain, and analyze an integrated schedule.
The SOW tasks the work. It should not rely on the DID alone to direct performance.
Contract Data Requirements List
The CDRL orders formal delivery of the resulting data. It states what the contractor submits, when it is due, where it goes, and what review or acceptance conditions apply.
As the DAU explanation of CDRL interrelationships describes, the CDRL acts as the data-delivery vehicle. It connects the underlying work requirement to a specific submission.
Data Item Description
The DID defines the required content, format, and intended use of a data product. The CDRL identifies the applicable DID and may tailor it for the specific contract.
For example, a DID may describe a broad report structure. Block 16 of the CDRL may delete inapplicable sections, define electronic file requirements, or add contract-specific clarification. The DAU guidance on DIDs provides a useful distinction between the DID’s content requirements and the CDRL’s delivery instructions.
CLIN and Contract Exhibit
A Contract Line Item Number (CLIN) establishes a separately identifiable item or service in the contract structure. A data CLIN may reference a CDRL exhibit containing individual exhibit line items such as A001, A002, and A003.
The DFARS Procedures, Guidance, and Information for contract exhibits states that CDRL data items may be separately priced or not separately priced. When they are not separately priced, their costs remain within another priced line item.
For more about contract line-item structure, see what a CLIN means in government contracting.
What Information Does a CDRL Control?
A properly prepared CDRL removes uncertainty from the delivery requirement. Although the exact entries vary, schedulers and program-controls teams should understand the following elements.
- Exhibit line item: The unique identifier, such as A001.
- Data item title: The name of the required report, dataset, plan, or technical product.
- Applicable DID: The document that defines the deliverable’s required content and format.
- Contract reference: The SOW or other contract paragraph associated with the data.
- Requiring office: The government organization responsible for the requirement.
- Inspection and acceptance: The locations and authorities involved in determining whether the submission meets the contract.
- Approval requirements: Whether the government must approve a draft before the contractor issues the final version.
- Frequency: Whether delivery occurs once, monthly, quarterly, upon an event, or at another defined interval.
- As-of date: The date through which the reported information must be current.
- Submission timing: The first and subsequent delivery requirements.
- Distribution: The recipients, copies, media, markings, and transmission instructions.
- Block 16 instructions: Contract-specific tailoring, review periods, file formats, and other clarification.
Teams should read the entire CDRL rather than rely on the title or delivery-frequency field. Block 16 often contains the instructions that determine the actual workflow.
Contractual Requirements Versus Good Management Practice
A CDRL incorporated into the contract creates a contractual delivery obligation. The contractor must follow its specified timing, content, format, and distribution requirements unless an authorized contract change provides otherwise.
However, a CDRL does not automatically dictate every internal management step. A contractor may use internal reviews, quality checks, working sessions, and earlier cut-off dates to support an on-time delivery. Those steps represent management practices unless the contract expressly requires them.
Likewise, the CDRL does not replace the contractor’s internal schedule, document-control process, or responsibility matrix. Instead, the program should translate each contractual delivery into executable internal work.
Teams should also avoid treating an email or meeting comment as an authorized change to a CDRL requirement. FAR 43.102 states that only contracting officers acting within their authority may execute contract modifications for the government. The exact modification method depends on the contract terms and the nature of the change.
Why CDRLs Matter to Schedulers and Program Controls
CDRLs create dates and events that often belong in the Integrated Master Schedule. They can drive engineering reviews, customer decisions, payment events, test readiness, baseline reviews, and follow-on work.
However, schedulers should model the work that produces the delivery, not just the submission milestone. A defensible schedule may include:
- Data collection and status cut-off
- Analysis and report development
- Internal functional reviews
- Program management approval
- Formal delivery
- Government review, when contractually defined or operationally necessary
- Comment resolution and final resubmission, when required
The level of detail should reflect program risk and management value. A routine monthly submission may need only a short recurring workflow. In contrast, a system design review package may require several weeks of preparation and cross-functional integration.
CDRL timing should also agree with the contract calendar and schedule logic. If the CDRL requires delivery 15 working days after the accounting period closes, the IMS should not use 15 calendar days. Likewise, a milestone labeled “monthly report” does not prove compliance if the CDRL requires specific native files, datasets, or recipients.
For programs that deliver cost and schedule performance data, the CDRL may tailor the Integrated Program Management Data and Analysis Report requirements. The schedule team should confirm which files, fields, calendars, and status dates the contract requires. See what an IPMDAR schedule dataset contains for a focused explanation.
Fictional Example: Mapping a CDRL Into the IMS
Consider the fictional Falcon Ridge Sensor Upgrade program. Its contract includes CDRL A002 for a System Design Review package.
For this example, the fictional CDRL requires a draft package 20 working days before the review. It gives the government 10 working days to return comments. The contractor must then submit the final package five working days after receiving those comments.
Entering only the System Design Review milestone would hide substantial work. Instead, the scheduler creates a short network:
- Complete subsystem design analyses
- Develop draft review package
- Perform internal engineering review
- Approve draft package
- Deliver A002 draft
- Government review period
- Resolve government comments
- Deliver A002 final
- Conduct System Design Review
The scheduler ties the first five activities to the relevant engineering work. Next, the scheduler applies the correct working-day calendar to the review and turnaround periods. Finally, the team assigns clear ownership for delivery and comment resolution.
This structure exposes risk. If engineering analyses slip, the schedule forecasts the draft delivery impact before the program misses the contractual date.
The same principle applies to an IMS delivery. The team should integrate status collection, schedule quality checks, management review, file preparation, and submission. A practical starting point is the IMS customer-delivery review checklist.
How Proposal Teams Should Review CDRLs
Proposal teams should analyze draft CDRLs before finalizing price and schedule. Data requirements can create significant recurring work, even when the contract does not price each deliverable separately.
First, create a CDRL compliance matrix. Record the item number, title, DID, SOW reference, frequency, due-date rule, required format, approval code, recipients, and responsible organization.
Next, identify the work needed to produce each item. Include data collection, authoring, integration, quality review, configuration control, security review, and delivery administration.
Then, place material deliverables and customer review cycles in the proposal schedule. This step improves traceability between the proposed technical approach and the DoD acquisition lifecycle schedule.
Finally, question ambiguous or excessive requirements before award. Ask whether each DID is current, whether Block 16 conflicts with the DID, and whether delivery dates align with major program events. Also verify that the government has defined approval and turnaround expectations clearly.
Common CDRL Mistakes
Treating the DID as the work requirement
A DID describes the data product. The SOW or another contract requirement should establish the work that produces it. Teams create gaps when they assume the DID alone defines all required performance.
Ignoring Block 16
Block 16 may tailor the DID, establish review timing, define file formats, or explain unusual frequency codes. Reading only the title and delivery date can lead to a noncompliant submission.
Confusing submission with acceptance
Sending a file does not always complete the obligation. The contract may require inspection, acceptance, approval, comment resolution, or a final version. Teams should track each condition separately.
Using inconsistent dates
The CDRL register, IMS, document-control system, and delivery portal should use the same due-date logic. A manual milestone that conflicts with the contract creates avoidable risk.
Accepting informal changes
A program office may request a different format or delivery date. The contractor should determine whether the request changes the contract and route it through authorized contract channels when required.
Failing to assign an owner
Every CDRL needs an accountable owner. That person may coordinate inputs from several functions, but the program should avoid shared responsibility with no clear delivery authority.
Practical CDRL Control Checklist
- Maintain a controlled register of all CDRLs and revisions.
- Trace each item to its SOW requirement, DID, CLIN, and exhibit.
- Record the as-of date separately from the delivery date.
- Identify draft, approval, final, inspection, and acceptance steps.
- Assign a responsible owner and supporting organizations.
- Map significant preparation work and delivery milestones into the IMS.
- Use the contract’s calendar definitions when calculating due dates.
- Confirm required native files, electronic formats, markings, and recipients.
- Retain transmittals and evidence of delivery.
- Update the register and schedule after authorized contract modifications.
For larger programs, the CDRL register should connect with the broader program-controls software stack. However, the contract remains the source of the requirement. A dashboard or workflow tool cannot override the incorporated CDRL.
CDRL FAQ
What does CDRL stand for?
CDRL stands for Contract Data Requirements List.
Is a CDRL the same as a DID?
No. The CDRL orders and schedules delivery for a specific contract. The Data Item Description defines the content, format, and intended use of the data product. Contract-specific CDRL instructions may tailor the DID.
Is every CDRL a separate CLIN?
Not necessarily. A contract may use a data CLIN that references a CDRL exhibit containing several exhibit line items. Data items may be separately priced or included within another priced line item, depending on the contract structure.
Should every CDRL appear in the IMS?
No universal rule requires every administrative delivery to appear in every IMS. However, schedulers should include CDRLs that drive contractual dates, major decisions, technical events, payment, customer reviews, or meaningful program risk. The contract and approved scheduling approach control the required treatment.
Can the program team change a CDRL delivery date by email?
An email may document a discussion, but it does not automatically modify the contract. The contracting officer must determine and execute any required contractual change within the officer’s authority.