What a Compliance Matrix Does
A compliance matrix maps every solicitation requirement to a specific location in your proposal. At its simplest: requirement reference, requirement text, and proposal section. In practice, an effective matrix also records who owns each requirement, which evaluation factor it supports, and whether the response is written yet.
Internally, the matrix is the project management backbone of the proposal, assigning accountability at the individual requirement level. Externally,when the solicitation asks for it, it gives evaluators a roadmap: "You asked for X in paragraph 3.2.1. We address it in Volume I, Section 4.2, page 37."
Two Kinds of Rows in One Matrix
Every mandatory instruction gets a row. Split them into two tabs so writers see a clean scoring list and the production lead still has a traceable checklist for the rules that can get a proposal rejected before it is scored.
| Scored Content Rows (Main Tab) | Submission Rows (Submission Tab) |
|---|---|
| Content requirements (shall-statements) from Sections C, H, I, and L | Font, margin, and formatting rules |
| Deliverables with DID references (CDRL/DD Form 1423) | File naming conventions |
| Section M evaluation elements as sub-rows | Page and volume limits |
| Owner: the responsible writer | Packaging, delivery, and electronic portal instructions |
| Verified at Pink, Red, and Gold Team | Owner: the production lead; verified against the final files at Gold Team |
Where Requirements Live in the Solicitation
Solicitations that follow the Uniform Contract Format in FAR 15.204-1 put the instructions to offerors in Section L and the evaluation factors for award in Section M. Those two sections are the backbone of the matrix, but they are not the only source of requirements.
| Section | What It Holds | What It Adds to the Matrix |
|---|---|---|
| Section C | Description, specifications, or statement of work (SOW/PWS) | Performance requirements and standards the technical and management volumes must answer |
| Section H | Special contract requirements | Obligations such as key personnel, security, or transition terms that proposals often must address |
| Section I | Contract clauses | FAR and DFARS clauses with technical or reporting implications |
| Section J | List of attachments | CDRLs (DD Form 1423), exhibits, and technical attachments |
| Section L | Instructions, conditions, and notices to offerors | The primary source: every instruction becomes a row, as scored content or as a submission row |
| Section M | Evaluation factors for award | Sub-rows under each Section L instruction for every element the evaluators will score |
The Section L/M Alignment Trap
How to Build the Matrix, Step by Step
Building a compliance matrix is a structured process, not a creative exercise. Every step has a specific input, output, and failure mode.
Extract Every Requirement from the Full Solicitation
Read the entire document, not just L and M. Requirements appear in the SOW/PWS, CDRLs, Section H, Section I, Section J attachments, and amendments. Each needs a row in your matrix.
Overlay Section M Evaluation Criteria
For each Section L requirement, check the corresponding Section M language. Where M names more specific elements, add them as sub-rows so each scored element gets its own owner and destination.
Categorize by Type and Volume
Group into technical, management, past performance, cost/price, and administrative. This determines volume assignment and writer allocation. Miscategorization leads to gaps.
Map Each Requirement to a Proposal Section
Follow the solicitation's prescribed outline if provided. Evaluators appreciate when your proposal mirrors their evaluation checklist sequence.
Assign Ownership to Individual Writers
Every requirement needs a single responsible author, not a team, not 'shared,' not 'TBD.' Shared ownership leads to gaps where each writer assumes the other covered it.
Resolve Cross-References and Dependencies
Trace every cross-reference: 'as described in Attachment J-4,' 'per DFARS 252.204-7012.' Each points to additional requirements that may need their own rows.
Track Compliance Status Through Submission
Update status as writers complete sections and reviewers verify them. By Gold Team, every row should show a final disposition backed by written content.
The compliance matrix is built once but maintained continuously. Every amendment can modify requirements. Every outline change shifts mappings. A matrix built in week one and not touched until Gold Team is a liability, not an asset.
Worked Example: From Solicitation Excerpt to Matrix Rows
The excerpts below come from a sample solicitation for IT service desk support, written for this guide. The agency, paragraph numbers, and owners are illustrative. Follow the six excerpts through to the finished rows.
Step 1: The Solicitation Excerpts
| Reference | Solicitation Text |
|---|---|
| C-3.4 (PWS) | The contractor shall resolve Priority 1 incidents within 4 hours of ticket creation. |
| C-3.7 (PWS) | The contractor shall deliver a monthly service performance report in accordance with CDRL A003. |
| J-2, CDRL A003 | Monthly Service Performance Report. Due the 10th business day of each month. |
| L-2.3 | Proposals shall use 12-point Times New Roman with 1-inch margins. |
| L-4.2 | Describe your approach to quality control, including methodology, tools, and reporting. Limited to 5 pages. |
| M-2.1 | The Government will evaluate the offeror's quality control methodology, the metrics it will collect, its reporting frequency, and its process for root cause analysis and corrective action. |
Step 2: The Resulting Matrix Rows
| ID | Source | Requirement | Eval Factor | Proposal Section | Owner | Status |
|---|---|---|---|---|---|---|
| L-4.2 | L-4.2 | Describe quality control approach: methodology, tools, reporting (5-page limit) | M-2.1 | Vol II, 3.1 | QC lead | Not Yet Addressed |
| L-4.2.a | M-2.1 | Quality control methodology | M-2.1 | Vol II, 3.1.1 | QC lead | Not Yet Addressed |
| L-4.2.b | M-2.1 | Metrics collected | M-2.1 | Vol II, 3.1.2 | QC lead | Not Yet Addressed |
| L-4.2.c | M-2.1 | Reporting frequency | M-2.1 | Vol II, 3.1.3 | Program manager | Not Yet Addressed |
| L-4.2.d | M-2.1 | Root cause analysis process | M-2.1 | Vol II, 3.1.4 | QC lead | Not Yet Addressed |
| L-4.2.e | M-2.1 | Corrective action process | M-2.1 | Vol II, 3.1.5 | QC lead | Not Yet Addressed |
| C-3.4 | C-3.4 | Resolve Priority 1 incidents within 4 hours of ticket creation | Technical factor | Vol I, 2.3 | Service desk lead | Not Yet Addressed |
| CDRL-A003 | C-3.7; J-2 | Monthly service performance report, due 10th business day | M-2.1 | Vol II, 3.1.3; Vol I, 2.6 | Program manager | Not Yet Addressed |
| S-L-2.3 | L-2.3 | 12-point Times New Roman, 1-inch margins (submission tab) | None (submission rule) | All volumes | Production lead | Not Yet Addressed |
Step 3: Why Each Row Looks the Way It Does
One instruction became six rows
L-4.2 asks for one narrative, but M-2.1 names five elements the evaluators will score. Each element gets a sub-row with its own owner and its own subsection, so none can be skipped without the matrix showing the gap.
The CDRL closed a loop
C-3.7 points to CDRL A003 in Attachment J-2. The deliverable gets its own row, and its due date has to agree with the reporting frequency in L-4.2.c. The same report also belongs in the cost volume, because producing it costs labor.
The performance standard went to the technical volume
C-3.4 is a measurable standard, so it maps to the service desk approach in Volume I. Note it against L-4.2.b too: the Priority 1 resolution time is the obvious quality control metric, and the two sections must quote the same number.
The format rule became a submission row
L-2.3 is not scored, but it is mandatory. It goes to the submission tab as S-L-2.3, owned by the production lead and checked against the final files. The 5-page limit stays on the L-4.2 row and feeds the page budget, so the writer sees it while drafting.
Step 4: What the Matrix Caught at Pink Team
At Pink Team, the reviewer checks each row against the draft. L-4.2.d describes the root cause analysis process clearly, but L-4.2.e only says corrective actions "will be tracked to closure" with no process or timeline. The row moves to Partial Comply with a note naming the missing element. The QC lead adds the corrective action steps and target timelines, and at Red Team the reviewer confirms the change and marks the row Full Comply. Without the sub-row, the gap would have been one sentence inside a five-page narrative that read as complete.
Compliance Matrix Template
Copy this column set into a spreadsheet as your starting point. The first six columns are the minimum; the rest pay for themselves on large or heavily amended solicitations.
Requirement ID
Unique identifier using the source convention (for example L-4.2.a, M-3.a, C-3.4, CDRL-A003)
Source Reference
Exact section, paragraph, page number, and amendment number
Requirement Text
Verbatim language from the solicitation (do not paraphrase)
Proposal Section
Specific volume, section, and paragraph in your outline
Responsible Author
Single person accountable
Compliance Status
Full Comply, Partial Comply, Exception, Will Comply, Not Applicable, or Not Yet Addressed
Requirement Type
Technical, management, past performance, cost/price, administrative, CDRL, or submission
Obligation Level
Shall (mandatory), should (expected), or may (optional)
Evaluation Factor
Section M factor or subfactor this requirement supports
Cross-References
Other proposal sections where this is also addressed
Review Status
Pink verified, Red verified, Gold confirmed
Notes
Dependencies, reviewer comments, amendment changes, exception rationale
Copy-Ready Header Row and Sample Row
Paste these two lines into a blank sheet as comma-separated values. The sample row is L-4.2.e from the worked example after Red Team.
Requirement ID,Source Reference,Requirement Text,Proposal Section,Responsible Author,Compliance Status,Requirement Type,Obligation Level,Evaluation Factor,Cross-References,Review Status,Notes
L-4.2.e,"M-2.1, p. 58",Process for corrective action,"Vol II, 3.1.5",QC lead,Full Comply,Management,Shall,M-2.1,"Vol II, 3.1.4",Red verified,Timelines added after Pink TeamSet Up the Sheet So It Stays Honest
Template Setup
Freeze the header row and the Requirement ID column so every row stays identifiable while scrolling
Restrict Compliance Status and Review Status to a drop-down list so nobody invents a new label
Keep one tab for scored content rows, one for submission rows, one for the CDRL sub-matrix, one for the cross-reference log, and one for the amendment log
Never reuse or renumber an ID; mark deleted requirements instead of removing their rows
Filter by Responsible Author to give each writer their own list before kickoff
Filter by Compliance Status before every color team to produce the open-items list
Compliance Statuses and What They Mean
Every requirement needs a disposition that tells evaluators and your team exactly how you are addressing it. Vague or inconsistent labels create confusion and raise red flags.
| Status | Definition | When to Use | Evaluator Impact |
|---|---|---|---|
| Full Comply | Requirement addressed completely without deviation. | Response directly and fully addresses the requirement as written. | Positive. Evaluators verify by checking the referenced section. |
| Partial Comply | Addressed incompletely; one or more elements are not yet covered. | Internal status while a draft meets some, but not every, sub-element. Resolve it to Full Comply or a formal Exception before submission. | Negative if submitted. Evaluators note the uncovered elements. |
| Exception / Deviation | Formally requesting an exception to the requirement. | Compliance is infeasible, cost-prohibitive, or your alternative is superior. | Risk area. Must include rationale and proposed alternative. |
| Will Comply | Do not currently meet the requirement but will comply by a milestone. | Certifications, facilities, or capabilities in progress. | Acceptable if credible. Evaluators assess realism and risk. |
| Not Applicable | Requirement does not apply to your proposed solution. | Only when clearly demonstrable. Use sparingly. | Scrutinized carefully. Evaluators may disagree. |
| Not Yet Addressed | Internal only. Writer has not yet drafted the response. | During drafting as a progress status. Never in a submitted matrix. | N/A (internal). If this appears at Gold Team, you have a serious problem. |
Avoid 'Comply' Without Evidence
CDRL Tracking and Data Item Descriptions
Contract Data Requirements Lists (CDRLs) are one of the most commonly overlooked requirement sources in DoD procurements. Listed on DD Form 1423, usually as a Section J attachment, each CDRL specifies a data deliverable: format (referencing a DID), due date, and delivery method.
Each CDRL represents a contractual obligation evaluators expect to see addressed. Your management approach must describe how you will produce each deliverable: reporting cadence, format, tools, and QA process.
Common CDRL Failures
Treating CDRLs as post-award details
Evaluators assess your understanding of deliverables during proposal evaluation. Ignoring CDRLs signals you have not fully read the solicitation.
Ignoring Data Item Descriptions
Each CDRL references a DID that specifies exact format and content. Missing the DID means your deliverable plan is incomplete.
Failing to account for CDRL costs in pricing
Unfunded CDRLs signal scope misunderstanding. Every deliverable has a production cost that belongs in your cost volume.
CDRL Sub-Matrix
Cross-Reference Handling
Federal solicitations are interconnected documents. A single RFP can contain internal cross-references ("see Section C, paragraph 3.4.2") and external references ("per DFARS 252.204-7012"). Each is a pointer to requirements your matrix may need to capture.
| Reference Type | Examples | What to Capture | Risk if Missed |
|---|---|---|---|
| FAR Clauses | 52.219-9 (small business subcontracting), 52.222-26 (equal opportunity) | Plans, representations, or reporting the proposal must include | Administrative non-compliance |
| DFARS Clauses | 252.204-7012 (safeguarding covered defense information), 252.239-7010 (cloud computing services) | Security and technical obligations the solution must describe | Security or technical gaps evaluators will flag |
| NIST Publications | SP 800-171 (protecting CUI), SP 800-53 (federal information systems) | The controls or control families the solicitation calls out | A compliance approach that does not match the referenced standard |
| DoD Instructions | DoDI 8510.01 (Risk Management Framework) | Mandated processes for the management approach | Missing required processes |
| Military Standards | MIL-STD-882E (system safety) | Engineering and safety tasks the technical approach must cover | Incomplete engineering approach |
Cross-Reference Closure Protocol
Identify Cross-Reference
Flag every 'as described in...', 'per DFARS...', 'see Attachment...' in the solicitation.
Follow and Assess
Read the referenced document or section. Determine whether it creates proposal requirements.
Document Decision
If it creates requirements, add rows to the matrix with the source reference. If not, record the rationale in the cross-reference log.
Verify Closure
At Pink Team, confirm every cross-reference has been followed and resolved. Treat an unresolved cross-reference at Red Team as a stop-ship item.
Keeping the Matrix Current Through Amendments
Amendments can change requirements, add evaluation subfactors, or move due dates. Reconcile the matrix against every one, with changes marked and communicated to the writers they affect.
Receive Amendment
Download and log it in the amendment tab. Compare it against the solicitation to identify changed, added, and deleted requirements.
List Impacted Rows
Map each change to affected matrix rows. Flag changed evaluation criteria, new deliverables, and modified standards.
Notify Affected Owners
Send targeted notes to the writers whose rows changed. Include the specific requirement changes, not just 'amendment issued.'
Re-Assess Risk
Decide whether the changes affect win strategy, pricing, or technical approach. Escalate to the capture manager if they are material.
Update the Matrix
Modify affected rows, add rows for new requirements, and mark deleted ones. Record the amendment number in the Source Reference column.
Using the Matrix in Color Team Reviews
The compliance matrix is not just a writer's tool. It is the review checklist at every stage of the proposal.
| Review Stage | Matrix Role | What to Check | When |
|---|---|---|---|
| Pink Team | Coverage check | Every requirement captured and mapped to the outline; open cross-references listed with owners | After the outline or storyboards are ready |
| Red Team | Evaluation scoring guide | Draft content exists for each row; every Full Comply is backed by written evidence; contradictions across volumes flagged | After a complete draft |
| Gold Team | Final compliance and production check | Every row has a final disposition; every submission row checked against the final files; page references verified after pagination; all amendments reconciled | Before final production |
If your team runs these reviews inside the Shipley process, our guide to Shipley-aligned proposal management shows where each color team gate sits from proposal planning through submission.
Common Mistakes
Six Compliance Matrix Pitfalls
Missing hidden requirements
The resume format requirement buried deep in Section L or the Section 508 clause in Section I. Systematic extraction across the full solicitation is the only defense.
Dropping submission instructions
Font, margin, page limit, file naming, and portal rules are mandatory even though they are not scored. Track them as submission rows with an owner, apart from the scored content, and verify them against the final files.
Ignoring cross-references
'As described in Attachment J-4' is not decoration. It points to requirements that need their own matrix rows with source traceability.
Letting the matrix go stale
A matrix created in week one and never updated creates a false sense of security. Update it immediately when amendments, outline changes, or reassignments occur.
One-to-one mapping only
Some requirements span multiple sections. Map a primary response and note supporting references, otherwise evaluators checking other sections will not find expected content.
Ignoring shall/should/may obligation levels
'Shall' is mandatory. 'Should' is expected with flexibility. 'May' is optional. Flag the obligation level so writers know the compliance risk of each requirement.
Compliance Matrix Essentials Checklist
Run this list before kickoff and again before Gold Team.
Compliance Matrix Essentials
All requirements from Section L captured with verbatim text
Every formatting, page limit, file naming, and portal instruction tracked as a submission row with an owner
Section M evaluation criteria overlaid as sub-requirements
SOW/PWS requirements extracted and mapped to proposal sections
All CDRLs listed with DID references, delivery frequencies, and format requirements
Section H special contract requirements reviewed for proposal obligations
Section I clauses checked for technical requirements (CUI, CMMC, Section 508)
All internal cross-references resolved and traced
External references (NIST, MIL-STD, DoD Instructions) reviewed
Every requirement has a unique ID linked to source paragraph and page
Every requirement assigned to a single responsible author
Every requirement mapped to a specific proposal section and paragraph
Standardized compliance statuses used throughout
All amendments reconciled with changes clearly marked
Page references updated after final pagination
When a Spreadsheet Stops Being Enough
Everything in this guide works in a spreadsheet. The friction shows up on long solicitations with several amendments: copying requirement text out of PDFs by hand, keeping page references current, and reconciling edits from several writers. If extraction and source linking are where your team loses the most time, see how the Projectory compliance matrix builds the first draft of the matrix from the RFP, with each requirement linked to its page and paragraph, so your team spends its time on the review steps above.
Key Takeaway
Frequently Asked Questions
Frequently Asked Questions
Should the compliance matrix include formatting requirements like page limits and font sizes?
Yes. Page limits, font, margins, file naming, and portal instructions are mandatory, and missing one can make a proposal noncompliant. Track them as submission rows in their own tab, each with an ID, a source reference, and an owner (usually the production lead), and verify every one against the final files at Gold Team. Keeping them apart from the scored content rows lets writers work from a clean scoring list without losing traceability for the submission rules.
How do you handle requirements that appear in multiple sections of the solicitation?
Create a single primary row with the most specific source reference, then add cross-reference entries pointing to each additional location where the requirement appears. This prevents duplicate effort while ensuring nothing falls through the cracks. In your proposal, address the requirement fully in one section and include forward and backward references in supporting sections so evaluators can find the response regardless of where they look.
When should the compliance matrix be started relative to the proposal schedule?
Start it as soon as the solicitation is released, before the outline exists. The matrix drives outline development, writer assignments, and page budgeting, so a late matrix means writers start drafting against an outline that may not match what the evaluators will score.
Do I have to submit the compliance matrix with my proposal?
Only when Section L asks for it. Some solicitations require a cross-reference or compliance matrix as part of the submission, often with a prescribed format such as verbatim requirement text, compliance status, and page references. When it is not required, keep it as an internal tool, and check whether a submitted matrix counts against the page limit before you include one voluntarily.
Who should own the compliance matrix?
One person, usually the proposal manager or a dedicated compliance lead, owns the matrix itself: its structure, its IDs, and every change after an amendment. Individual rows are owned by the writers responsible for them. Splitting ownership of the matrix across several people is how rows get silently edited or dropped.