What is a compliance matrix in a proposal?

A compliance matrix is a table that lists each requirement in a request for proposal (RFP) and shows where in the proposal that requirement is answered. The proposal team uses it as a checklist and work plan so nothing is missed, and evaluators use a version of it to find each answer quickly. The APMP Body of Knowledge recommends building one for every bid, regardless of size or deadline.

When should you build a compliance matrix?

Before writing starts, at the same time as the proposal outline. The matrix should follow the structure of the RFP, and building it early turns it into a plan for writers, a way to assign requirements to owners and a guard against missed requirements. Building it after the draft is finished only produces an index of what happens to be there, and gaps found at that stage are expensive to fix.

How do you shred an RFP into a compliance matrix?

Read the RFP line by line and put every requirement on its own row, typically each sentence containing "shall", "must" or "will", and each instruction verb such as identify, describe or provide. A paragraph that contains three demands becomes three rows. Keep the RFP's own numbering and wording in each row, and also capture requirements stated only in narrative text, which may not appear in any list the customer provides.

What columns should a compliance matrix have?

At minimum: the RFP reference (section number), the requirement text in the customer's words, the proposal section that answers it, the owner responsible for writing it, and a status. Many teams add a compliance level (full, partial, non-comply) with a justification, the page limit, and the evaluation criterion the requirement relates to. A spreadsheet works well because the rows can be re-sorted by RFP section, proposal section, owner or status.

Is a compliance matrix the same as a cross-reference table?

They are closely related. The compliance matrix is the team's full working document, with owners, status and compliance notes. The version submitted to the customer, often called a response matrix or cross-reference table, keeps only what the evaluator needs: each requirement and the proposal page or section that answers it. If the customer supplies its own format, follow it exactly; if not, you can add a column that highlights your benefits, which turns the table into a selling tool.

Compliance Matrix: The Blueprint Behind Every Compliant Proposal

Here is this episode's question: can you point to the exact page where your proposal answers each requirement in the RFP?

Picture an evaluator with your proposal on one side and the RFP on the other. They reach requirement 4.3.2 and start flipping pages. The answer is probably in there somewhere, maybe split across two sections and phrased in your words instead of theirs. If they can't find it, they can't score it. The tool that prevents this moment is the compliance matrix: a table that lists every requirement and points to the place in the proposal where it is answered. For your team it is a checklist and a work plan; for the evaluator it is a map.

This series works through the APMP Body of Knowledge as summarized in the APMP Foundation Study Guide. Episode 1 explained the difference between compliance and responsiveness and introduced the compliance and response matrices side by side. This episode opens a new part of the guide, Create Deliverables, where strategy turns into documents, and it starts with the matrix itself: what goes in it, when to build it, who uses it and how to keep it true.

Illustration: a proposal manager stands beside a five-row table; orange lines run from lines in an RFP document on the left, through each checked row, to tabs in a proposal binder on the right — Every line of the RFP, one row in the matrix, one place in the proposal.

What a compliance matrix is, and who it serves

The Body of Knowledge describes the compliance matrix as a tool with two jobs. It helps you manage the preparation of the response, and it helps you demonstrate compliance to the customer. Both jobs rest on one simple structure: requirement on the left, location of the answer on the right.

That makes it a checklist for two audiences at once:

Your team uses it to make sure every requirement has an answer, an owner and a place in the outline.
The evaluator uses it to go straight from a requirement to your response without hunting.

The second audience is easy to underestimate. Evaluating proposals is rarely anyone's only job, and many evaluators are not experts in the technical subject of your bid. The guide's advice is to make their work as quick and easy as you can, and to include a version of the matrix even when the RFP doesn't ask for one. Place it in the response before the first section that refers to RFP requirements, so the evaluator meets the map before the territory.

Sometimes the customer hands you a matrix of its own as part of the RFP package. Treat the items in it as the customer's must-haves. But don't treat it as complete, a point we return to below.

The three layers of compliance a matrix should cover

"Compliance" often gets reduced to "did we answer the requirements?" The Body of Knowledge takes a wider view. When a proposal is compliant, the customer reads it as the work of an experienced, professional bidder that will be easy to deal with. That impression depends on three layers:

Layer	What it covers	Questions to check
Submittal instructions	How the response must be delivered	Did we use the requested format and packaging? Did we answer every question and fill in every form and attachment? Is it going to the right person, at the right address, before the deadline?
Requirements	What the customer needs done	Can we actually deliver this service? Are the people we propose really available? Have we answered the need behind each requirement? Is there anything we cannot meet?
Internal compliance	Your own organization's rules	Have legal and other internal requirements been met? Was the opportunity logged where it should be, for example in the CRM? Were the right people and management levels involved? Is the proposal approved for submission?

A matrix that tracks only the second layer will still let you lose on the first, through a missing form or a late upload, or on the third, through a bid nobody was authorized to send. Many teams keep submittal instructions and internal approvals as their own rows or a separate tab of the same workbook, so there is one place to check before submission.

Build it before anyone writes

The single most important rule in this part of the Body of Knowledge is timing. The compliance matrix should mirror the structure of the RFP, just as the outline does, and it should be built alongside the outline, before content planning and writing begin. Making it after the draft is done is like drawing the floor plan once the walls are already up: you will learn where the problems are, but too late to move anything cheaply.

Illustration: two panels; in the panel labeled Before, an architect unrolls an orange-edged blueprint next to an empty foundation; in the panel labeled After, a puzzled builder tries to draw a plan in front of a finished house — A matrix made after writing is an index. A matrix made before writing is a plan.

Built early, the matrix does work that no index can:

It becomes the writers' plan of action. Each writer can see exactly which requirements their section must answer.
It breaks the RFP into bundles. Requirements can be grouped and routed to the right people, including the ones who need them for costing and pricing.
It creates accountability. Every requirement has a name next to it, which makes follow-up much easier for the bid or proposal manager.
It lowers the odds of missing something. Gaps show up as empty cells while there is still time to fill them.

Questions worth asking for every row while the outline is still being drawn: Which section will answer this? Who will write it? Where will a reviewer check it? How will we know it is done?

A compliance matrix is not the index you add at the end. It is the blueprint you build from.

Shred the RFP line by line

Building the matrix starts with what proposal people call shredding: reading the RFP one line at a time and separating every requirement into its own row. The usual signals are obligation words such as shall, must and will, and instruction verbs such as identify, describe, provide, demonstrate and discuss.

Requirements often travel in groups. Here is a paragraph written for this article, of the kind many service RFPs contain:

RFP 3.4 Transition. The contractor shall identify the key personnel who will lead the transition and shall describe its plan for moving services from the incumbent without interruption. Offerors must provide a completed Form C (Transition Schedule) and will deliver a weekly status report during the transition period.

Left as one row, this paragraph is easy to answer partially. A writer covers the plan in detail, mentions the team in passing and forgets the form. Shredded, it becomes four rows that can each be assigned, written and checked:

RFP ref.	Requirement (customer's words)	Proposal section	Owner	Status
3.4 (a)	Identify the key personnel who will lead the transition	2.1 Transition team	HR lead	Draft
3.4 (b)	Describe the plan for moving services from the incumbent without interruption	2.2 Transition approach	Solution architect	In review
3.4 (c)	Provide a completed Form C (Transition Schedule)	Attachment C	Bid coordinator	Open
3.4 (d)	Deliver a weekly status report during transition	2.4 Governance and reporting	Delivery manager	Draft

Illustration: a dense page of RFP text goes into a cutting machine and comes out as separate strips tagged shall, must and will, which a team member stacks neatly on a table — One requirement, one row. A paragraph with four demands becomes four rows.

The guide points out two further benefits of shredding. Writers get a precise list of what to address, and reviewers get a precise list to check against. And because each requirement stands on its own row, an RFP amendment or an outline change means editing a few cells rather than rebuilding the whole table.

Look for requirements the lists leave out

Never assume the RFP's numbered requirements, or a matrix the customer supplied, contain everything. The Body of Knowledge warns that some requirements are never labeled as such; they sit inside narrative text, such as a background section, a description of current problems or a sentence in the scope of work. A line like "staff currently spend much of each month reconciling reports by hand" may be the customer's real reason for buying.

Finding these and answering them does more than close a compliance gap. It shows the customer that you read the whole document and understood it, which is a step toward the responsiveness discussed in Episode 1.

Illustration: a short checklist with three ticked items on the left; on the right a hand holds a magnifying glass over a long page of text, revealing one line highlighted in orange — The customer's checklist and the customer's needs are not always the same length.

Keep it in a spreadsheet you can sort

The Body of Knowledge recommends a spreadsheet application, and the reason is practical: the matrix changes constantly. When a section is renumbered or an amendment rewrites a requirement, you edit the cell and re-sort. Sorting also lets one table answer different questions for different people:

Sort by	Question it answers	Who usually asks
RFP section	Is every customer requirement tracked, in the customer's order?	Bid manager, final compliance reviewer
Proposal section	What must each part of our outline answer?	Writers, volume leads
Owner	What is each person responsible for, and by when?	Bid manager, each contributor
Status	What is still open, in draft or in review?	Bid manager, management

Episode 1 suggested a basic set of columns. In practice, many teams add the page or word limit for each section and the evaluation criterion each requirement relates to, so writers can see both what they must say and how it will be scored.

Follow the customer's numbers and words

Two habits make a matrix far easier for an evaluator to use.

Use the RFP's numbering, in the matrix and in the proposal itself. The guide admits this can fight with the narrative order you would choose, but it lets an evaluator work through their checklist and score without jumping back and forth. If your story needs a different flow, tell it within the customer's structure, not instead of it.

Use the customer's words. Don't paraphrase requirements into your own terms in the matrix. And begin each row with the action verb the RFP uses, because the verb tells the writer what kind of answer the evaluator expects:

If the RFP says…	The evaluator expects to see…
Identify	Specific names, items or roles, not a general description
Describe	How something works: steps, sequence, responsibilities
Provide	A deliverable: a form, a plan, a certificate, attached or included
Demonstrate	Evidence that it works, such as results, references or a proof point
Discuss	Your reasoning, including options and trade-offs

Rewritten in our terms

"2.2 Our Seamless Migration Methodology" — the evaluator has to work out that this is the answer to RFP 3.4 (b).

In the customer's terms

"2.2 Transition Plan Without Service Interruption (RFP 3.4 b)" — the evaluator sees the requirement, in their own words, and its number.

One matrix, five readers

A matrix that only the bid manager opens is underused. The Body of Knowledge lists how different members of the team read the same document:

Role	How they use the matrix
Bid or proposal manager	The master plan for proposal content, and the tool for routing each requirement to whoever must cost, price or answer it
Volume lead	A checklist that every requirement in their volume is covered
Writers	A guide to what each section must contain
Reviewers	An evaluation tool that defines what should appear in each section
Management	A one-page overview of the plan and the strategy behind it

In the guide's summary, this is why the matrix doubles as a response assignment matrix: it is how the bid manager hands out work to many contributors and follows up on each piece.

Illustration: a large shared table with an orange header row; around it one person points at rows to assign them, one ticks a clipboard, one writes on a laptop, one inspects with a magnifying glass and a senior executive watches with arms crossed — The same rows, read five ways: assign, check, write, review, oversee.

Keep it current until submission

Building the matrix is planning; keeping it right is a job that lasts until the proposal goes out. The Body of Knowledge lists the changes that should trigger an update:

The outline: a section's name, number, order or page allocation changes.
The team: a section changes author.
The RFP: instructions, evaluation criteria, requirements or addenda change.

Give one team member the explicit responsibility of keeping the matrix up to date. An out-of-date matrix is worse than none, because the team keeps trusting it. Reviews, color team checks and the final compliance check are only as good as the table they check against.

Illustration: an envelope labeled Amendment flies toward a monitor showing a table; two rows turn orange as a team member updates them under an orange refresh arrow — Every amendment, outline change or new author is a reason to touch the matrix.

Watch the disqualifiers and the partial rows

Two kinds of rows deserve extra attention before the matrix is final. First, requirements marked as disqualifiers: if you miss one, the proposal may not be evaluated at all, so mark them clearly and check them first. Second, any row marked "partially comply" or "non-comply". Review each one against the customer's requirement and ask whether the solution or the answer can move closer to full compliance. Episode 1 covered how to explain the gaps that remain honestly.

The submitted version: response matrix, cross-reference table, selling tool

The matrix you work from and the table you hand in are not the same document. The submitted version, called a response matrix in the Body of Knowledge and often a cross-reference table in practice, drops the owners and statuses and keeps what the evaluator needs: the requirement, its RFP reference and where you answer it. When page limits leave no room for a separate table, the same references can live in your section headings, as Episode 1 described.

If the RFP prescribes a format for this table, follow it exactly. But the guide notes that most RFPs don't, and that opens an opportunity: the table can do more than point. For example, a short column stating the benefit to the customer next to each key requirement turns a dry index into one more place where your win themes appear:

RFP ref.	Requirement	Where answered	What it means for you
3.4 (b)	Describe the plan for moving services without interruption	§2.2, pp. 14–17	Site-by-site cutover with a rollback at every step, so front-line services stay open
5.1	Provide service desk coverage 24 hours a day	§3.1, pp. 22–24	One team covers days and nights, so calls are not handed to a separate night crew

Keep the extra column short and factual. It sits in the one table every evaluator is sure to use, so it is valuable space, but it must not make the table harder to scan.

Common mistakes

Building the matrix at the end. By then it can only record gaps, not prevent them.
Trusting the customer's list. The RFP's numbered requirements and any matrix the customer supplies may not match the number of real requirements. Read the narrative too.
Letting it go stale. An amendment arrives, the outline shifts, an author changes, and nobody updates the table. From that moment the team is working to the wrong plan.
Paraphrasing the customer. Your terms may be better, but they make the evaluator's checklist harder to match.
Stopping at compliance. The Body of Knowledge is clear that compliance and responsiveness matter, but they are not all customers weigh. A fully compliant proposal still needs discriminators, benefits and a winning price.

Checklist for your next proposal

Read the whole RFP, including background and scope narrative, before you build anything.
Shred it line by line: one row per "shall", "must", "will" or instruction verb, with the RFP's number and wording.
Add the hidden requirements you found in the narrative, and mark disqualifiers.
Build the matrix with the outline, before writing starts: every row gets a proposal section, an owner and a status.
Cover all three layers: submittal instructions, requirements and internal approvals.
Keep it in a spreadsheet and share the sorted views each role needs.
Name one owner to update it after every outline, team or RFP change.
Before finalizing, review every partial or non-comply row and close what you can.
Submit a response matrix (or headings with RFP references) before the first section that answers requirements, in the customer's format if one is given, with a short benefit column if not.

Where Contrl fits

The slowest part of a compliance matrix is the first pass: shredding the RFP and deciding where each requirement will be answered. In Contrl, you upload the RFP and it extracts the requirements, the required outline and the evaluation criteria, then maps each requirement to a section of that outline, so the matrix exists before any page is written. When the slides are written, each page cites the RFP requirements it answers, which means the link from requirement to page is kept on the page itself instead of in a separate table someone has to remember to update.

Diagram: an uploaded RFP is split into five requirements, one of them found in narrative text; each requirement is linked to a section of the required outline, each section to a page that cites the requirement IDs it answers, and a bar confirms five of five requirements mapped with none unmapped — Requirement to section to page, with a check that nothing is left unmapped.

Next in the series

The matrix tells you where every requirement will be answered, including the ones that ask for numbers. Episode 13 covers Cost and Pricing Data: what sits behind your price, why government and commercial buyers ask to see it so differently, and how showing your pricing logic makes the whole proposal more credible.

This article is an independent study companion based on the APMP Foundation Study Guide, version 4.2 (© 2025 APMP), which summarizes the APMP Body of Knowledge. It paraphrases and comments on that material and is not endorsed by APMP. The sample RFP paragraph and its shredded rows, the sort-view and action-verb tables, the heading comparison, the hidden-requirement sentence and the benefit-column example were written for this article and are illustrative. For the authoritative text and certification information, see apmp.org.