Federal contracting glossary
CDRL
What is a CDRL in a government contract?
A CDRL (Contract Data Requirements List) is the contractual list of every data product a contractor must deliver to the government. A DD Form 1423 records each item with its own identifier, governing Data Item Description, delivery schedule, and format.
A CDRL (Contract Data Requirements List) is the contractual list of every data product a contractor must deliver to the government. A DD Form 1423 records each item with its own identifier, governing Data Item Description, delivery schedule, and format. The spoken form is "see-drill."
If the contract owes the government a report, plan, drawing, manual, or test result, that item appears on the CDRL. An item that the CDRL does not list is generally not a deliverable.
What is on a CDRL?
Each CDRL item is one row, and the row is the contract. A typical item carries:
- A CDRL item number. Sequential identifiers such as A001, A002, and A003. Some programs use B, C or D series to separate deliverable categories.
- A DID reference. The Data Item Description (a
DI-XXXX-NNNNNnumber, for example DI-MGMT-81861) that states the content and format of the deliverable. - A title. "Contractor's Progress, Status and Management Report," "System Safety Program Plan," and other names of that kind.
- A frequency. Monthly, quarterly, annually, one-time, or as-required.
- A delivery schedule. Either a recurring cadence or an event trigger. Triggers include "30 days after contract award," "NLT" a stated date, or delivery tied to a program review (SRR, SDR, PDR, CDR, TRR, FCA, PCA).
- A distribution and approval regime. Who receives the item, in what format, and whether the government approves it or only receives it for information.
Where does a CDRL appear in a bid?
The CDRL is usually an attachment, not part of the body of the solicitation. The Statement of Work (SOW) or Performance Work Statement (PWS) states the work. The CDRL attachment states what paper the work produces. Different people often write the two documents separately, so the two routinely disagree. Generally they are reconciled during the proposal, not after award.
The mistake that makes this term matter
The CDRL rarely arrives with the solicitation body. It comes as an attachment, often a spreadsheet, often near the end of a long file list. It does not read like scope. It reads like administrative paperwork, so it goes to whoever owns the compliance matrix rather than to the people who build the estimate.
By the time someone reads it closely, the team has finished the technical volume and nearly closed the cost volume. Then someone notices that a monthly report means a monthly report for the whole period of performance, each one with its own government review cycle. Nobody costed the labor to produce them. The work is real, the obligation is contractual, and the bid is already with the government. That is the expensive way to learn that a CDRL is scope.
What goes wrong with CDRLs in practice
Teams price them last, or not at all. A monthly status report over a five-year period of performance is 60 deliverables. Each one carries a review-and-revise cycle. Teams that estimate the technical work carefully, then treat data deliverables as overhead, systematically underbid.
The SOW and the CDRL do not agree. The SOW requires a test plan, and no CDRL item covers it. Or the CDRL lists a deliverable that the SOW never asks anyone to produce. Both are real risks. The first one is scope with no price against it. The second one is scope that the contract may still require you to deliver.
The delivery schedule disagrees with itself. One paragraph says quarterly. An attachment says monthly. A third reference ties delivery to a milestone. Submit a question and settle this before proposals are due, not at the first delivery.
Teams ignore the DID. A DID is not a suggestion about formatting. It states required content. A document that omits a mandated section is a rejectable deliverable, even when the technical substance is sound.
What to do
- Extract every CDRL item into its own line during the bid.
- Cross-reference each item to the SOW paragraph that generates it.
- Price the recurring items across the full period of performance, including option years.
- Flag any deliverable that one document lists and the other omits.
- Raise each flagged deliverable as a clarification question.
- Finish this mapping before you price the bid, because the answers change the number.
What a CDRL is not
A CDRL is not a schedule of the work, and it is not the WBS. It governs deliverable data, which means the documents. The contract delivers hardware, software, and services under other parts. A CDRL also does not establish data rights by itself. The data rights clauses and the assertions of the contractor govern what the government may do with a delivered document.
Silas™ reads the SOW and the CDRL attachment together and surfaces the deliverable list, the DID references, and the places where the two documents disagree.
Last reviewed .
This page is reference material about federal contracting terminology. It is not legal advice, not a compliance determination, and not a substitute for professional judgement or for the authoritative text. Regulations change; verify any citation against the current FAR/DFARS text before relying on it. See our Terms of Service.