RFP Compliance Matrix: [Bid name] for [Client name]
Line-by-line map of every requirement in a Request for Proposal to its compliance status, the
fit of the proposed solution, a short answer, the exact place in the response where it is
answered and the evidence behind it. Includes the source and addenda register, the extraction
(shredding) method, the status legend, deviations and alternatives, the clarification log, the
mapping to evaluation criteria and a coverage summary. Structure aligned with the compliance
matrix practice described in the APMP Body of Knowledge and with the acquirer's evaluation
concerns in ISO/IEC/IEEE 41062:2024 (software acquisition). Issuers can reuse sections 4 to 12 as
the requirement response sheet they send to bidders. Replace every [bracketed] value and every
row marked Example; the worked example continues the account-based ticketing bid used in RFP
Technical Response (business/rfp-technical-response).
Document control
| Field | Value |
|---|
| Document ID | [RCM-001] |
| Opportunity ID | [OPP-YYYY-NNN] |
| RFP reference | [Issuer reference], version [x] |
| Addenda included | [Addendum 1 dated YYYY-MM-DD; Addendum 2 dated YYYY-MM-DD] |
| Response volumes covered | [Technical, management, commercial, forms] |
| Requirement baseline date | YYYY-MM-DD |
| Total requirements | [n] (see section 16) |
| Version | [0.1] |
| Status | [Draft / In review / Final / Submitted] |
| Owner | [@compliance-lead or @bid-manager] |
| Approvers/reviewers | [@solution-architect], [@delivery-lead], [@contracts-manager], [@security-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Commercial in confidence] |
Approvals
| Role | Name | Decision | Date |
|---|
| Bid manager | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Solution architect | [@name] | [Decision] | YYYY-MM-DD |
| Contracts and legal | [@name] | [Decision] | YYYY-MM-DD |
| Executive sponsor (for deviations) | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First shred of RFP version [x] |
| 0.2 | YYYY-MM-DD | [@name] | Example: Addendum 1 applied: 6 requirements changed, 4 added |
| 1.0 | YYYY-MM-DD | [@name] | Example: Final compliance review passed; submitted |
Contents
1. Purpose and rules
This matrix answers three questions for every requirement: do we comply, how, and where does the
evaluator find the proof. It serves the bid team as the response outline and work allocation, and
the evaluator as a navigation aid that shows nothing was missed.
| Rule | Detail |
|---|
| Single owner | The compliance lead owns the matrix. Section owners propose statuses; only the compliance lead and the solution architect confirm them |
| Atomic rows | One requirement per row; a compound sentence becomes two or more rows with suffixes (FR-012a, FR-012b) |
| Issuer text untouched | Requirement text is quoted or cited exactly; interpretations go in the response column |
| Status from evidence | A status of Compliant needs a response location and evidence, not a belief |
| Consistent across volumes | Every answer here matches the technical, management and commercial volumes |
| Freeze point | Statuses freeze at the red team review; later changes need the bid manager's approval |
2. Source documents and addenda
| ID | Document | Version or date | Requirements extracted | Notes |
|---|
| SRC-01 (Example) | RFP main document, sections 1 to 9 | v1.0, YYYY-MM-DD | 112 | Instructions in section 4, evaluation in section 5 |
| SRC-02 (Example) | Annex A Statement of requirements | v1.0, YYYY-MM-DD | 96 | Functional and non-functional |
| SRC-03 (Example) | Annex B Draft contract and service schedule | v1.0, YYYY-MM-DD | 18 | Commercial and legal obligations |
| SRC-04 (Example) | Annex C Security questionnaire | v1.0, YYYY-MM-DD | 4 | Questionnaire answered in its own form; 4 overarching rows here |
| SRC-05 (Example) | Addenda 1 and 2 and clarification answers round 1 | YYYY-MM-DD | 10 (6 changed, 4 new) | New rows marked with source SRC-05 |
| [SRC-NN] | [Document] | [Version] | [n] | [Notes] |
Example check: 112 + 96 + 18 + 4 + 10 = 240 rows, the total in section 16. The six changed
requirements replace their earlier rows, so they are counted once, under SRC-05.
3. Requirement extraction method
3.1 Process
Run the extraction once per source document and again for every addendum and answer round.
3.2 Obligation signals
Read the RFP's own definitions first; many issuers define these words in their instructions. Where
they do not, use this default reading and record it so that everyone classifies the same way.
| Signal in the text | Default classification | Treatment |
|---|
| "shall", "must", "is required to" | Mandatory | Pass or fail; any doubt goes to a clarification question |
| "should", "is preferred", "will be scored" | Scored or desirable | Answer to maximise the score; partial answers allowed |
| "may", "optional", "can" | Optional | Answer if it helps a win theme; mark Not applicable otherwise |
| "will" in a sentence about the issuer | Issuer statement | Usually informational; check whether it implies a bidder duty |
| Evaluation criterion text | Scored | Map to response sections in section 15 |
| Form, template or attachment to return | Mandatory deliverable | Row in section 6 |
3.3 Identifiers
| ID prefix | Category | Matrix section |
|---|
| INS- | Instructions to bidders and submission rules | 6 |
| MAN- | Mandatory pass or fail requirements | 7 |
| FR- | Functional requirements | 8 |
| NFR- | Non-functional requirements | 9 |
| SEC- | Security, privacy and accessibility | 10 |
| IMP- | Implementation, service and support | 11 |
| COM- | Commercial, contractual and legal | 12 |
Keep the issuer's own reference in the "RFP ref" column. When the issuer numbers requirements,
reuse the number inside the ID (RFP 6.3.2 becomes NFR-632) only if it stays unique after addenda.
4. Status legend and response rules
4.1 Compliance status
| Code | Status | Use when | Required in the row |
|---|
| C | Compliant | The proposal meets the requirement in full, as written | Response location and evidence |
| PC | Partially compliant | Part of the requirement is met; the gap is stated | Gap, plan to close it, any cost |
| ALT | Alternative proposed | The intent is met in a different way | Link to a DEV row in section 13 and the benefit |
| NC | Not compliant | The requirement is not met and will not be | Reason; link to a DEV row; escalation if mandatory |
| NA | Not applicable | The requirement does not apply to the proposed solution | Reason; confirm with a clarification if doubtful |
| N | Noted | Informational statement; nothing to deliver | Acknowledgement only |
4.2 Fit level
| Fit | Meaning |
|---|
| Standard | Available in the current product release without change |
| Configured | Delivered by configuration, rules or templates without code |
| Extended | Delivered through the product's supported extension points |
| Custom | New code built and maintained for this client |
| Third party | Delivered by a named partner product or service |
| Roadmap | Planned in a dated release; state the date and whether it is a contractual commitment |
4.3 Response rules
- Answer the requirement first, in one sentence, then say how. Evaluators skim.
- Never mark Compliant a requirement met only by Roadmap; use PC and give the date.
- Cite the place in the response by section and page, not just by volume.
- Evidence is something an evaluator can check: a certificate, a demonstration scenario, a
reference, a document in an appendix, a test report.
- When the same requirement appears twice in the RFP, answer it identically and cross-reference.
5. Matrix columns
| Column | Content |
|---|
| ID | Internal requirement ID from section 3.3 |
| RFP ref | Issuer's clause, table row or page reference |
| Requirement | The issuer's text, quoted, or a reference when it is long |
| Type | M (mandatory), S (scored or desirable), O (optional), I (informational) |
| Status | C, PC, ALT, NC, NA or N from section 4.1 |
| Fit | From section 4.2; blank for non-solution requirements |
| Response summary | One or two sentences: the answer, then how |
| Location | Volume, section and page where the full answer is |
| Evidence | Certificate, demonstration, reference, appendix |
| Owner | Person who drafts and defends the answer |
In the tables below, the requirement text of example rows is a short paraphrase marked Example;
in a real matrix quote the issuer.
6. Instructions to bidders
| ID | RFP ref | Requirement | Type | Status | Response summary | Location | Owner |
|---|
| INS-001 (Example) | 4.1 | Submit through the e-tendering portal before the deadline | M | C | Upload planned two working days early | Portal receipt | [@bid-manager] |
| INS-002 (Example) | 4.2 | Technical volume no longer than 40 pages, A4, 11-point minimum | M | C | 39 pages, 11-point | Volume 2 | [@bid-manager] |
| INS-003 (Example) | 4.3 | Return Form A acknowledging all addenda | M | C | Form A lists addenda 1 and 2 | Forms volume | [@compliance-lead] |
| INS-004 (Example) | 4.6 | Prices only in the commercial volume | M | C | No prices in volumes 1 and 2 | Volumes 1 and 2 | [@bid-manager] |
| [INS-NNN] | [Ref] | [Requirement] | [M/S/O/I] | [Status] | [Summary] | [Location] | [Owner] |
7. Mandatory and pass or fail requirements
| ID | RFP ref | Requirement | Type | Status | Response summary | Evidence | Owner |
|---|
| MAN-001 (Example) | 3.2 | Certified information security management system covering the service | M | C | ISO/IEC 27001:2022 certificate, scope covers operations in both regions | Certificate, Appendix C | [@security-lead] |
| MAN-002 (Example) | 3.3 | Professional indemnity insurance of at least the amount stated | M | C | Policy in force to YYYY-MM-DD | Insurance certificate | [@contracts-manager] |
| MAN-003 (Example) | 3.4 | Two references of similar scope in the last five years | M | C | CS-001 and CS-002 | Volume 2 section 15 | [@bid-manager] |
| MAN-004 (Example) | 3.5 | Card payments handled by a PCI DSS validated service provider | M | C | PSP holds a current PCI DSS v4.0.1 attestation | PSP AOC, Appendix C | [@solution-architect] |
| [MAN-NNN] | [Ref] | [Requirement] | M | [Status] | [Summary] | [Evidence] | [Owner] |
8. Functional requirements
| ID | RFP ref | Requirement | Type | Status | Fit | Response summary | Location | Evidence |
|---|
| FR-012 (Example) | A-2.4 | Apply a daily fare cap across all modes | M | C | Configured | Cap rules configured per mode and concession | Vol 2, 6.2, p. 14 | Demo D-02 |
| FR-013 (Example) | A-2.5 | Apply a weekly fare cap | M | C | Configured | Weekly cap on a rolling or fixed week, as the authority chooses | Vol 2, 6.2, p. 14 | Demo D-02 |
| FR-019 (Example) | A-2.11 | Re-price journeys when late offline taps arrive | S | C | Standard | Taps re-ordered by device time and journeys re-priced | Vol 2, 6.2, p. 15 | Reference CS-001 |
| FR-041 (Example) | A-3.9 | Riders request refunds online with approval workflow | S | PC | Extended | Online request standard; two-step approval extended; multi-level approval in release 2 | Vol 2, 6.1, p. 13 | Demo D-03 |
| FR-064 (Example) | A-5.3 | Apportion revenue between operators by agreed rules | M | C | Custom | Rules engine extension built for the authority's operator agreements | Vol 2, 6.1, p. 13 | Design note, Appendix E |
| [FR-NNN] | [Ref] | [Requirement] | [Type] | [Status] | [Fit] | [Summary] | [Location] | [Evidence] |
9. Non-functional requirements
| ID | RFP ref | Characteristic | Requirement | Type | Status | Response summary | Location |
|---|
| NFR-021 (Example) | A-6.1 | Performance efficiency | Journey visible to the rider within 60 seconds of the tap | S | C | Median under 10 seconds in reference production; load test planned | Vol 2, 7, p. 18 |
| NFR-030 (Example) | A-6.4 | Reliability | Tap ingestion available 99.9% per month | M | C | Active-active in two regions | Vol 2, 7, p. 18 |
| NFR-034 (Example) | A-6.9 | Reliability | Recovery point objective of zero for all data stores | M | ALT | Zero for tap and payment stores; five seconds for the reporting store (DEV-001) | Vol 2, 16, p. 38 |
| NFR-036 (Example) | A-6.12 | Interaction capability | Rider web and app meet WCAG 2.2 level AA | M | C | Accessible design system; conformance report | Vol 2, 7, p. 18 |
| NFR-038 (Example) | A-6.15 | Flexibility | Add a new operator without code changes | S | C | Operator defined as configuration | Vol 2, 7, p. 19 |
| [NFR-NNN] | [Ref] | [Characteristic] | [Requirement] | [Type] | [Status] | [Summary] | [Location] |
10. Security, privacy and accessibility
| ID | RFP ref | Requirement | Type | Status | Response summary | Location | Owner |
|---|
| SEC-003 (Example) | A-7.2 | All personal data processed and stored in the country | M | C | Two in-country regions; support with production access in-country only | Vol 2, 8.3 | [@security-lead] |
| SEC-007 (Example) | A-7.5 | Customer-managed encryption keys | S | ALT | Keys in an in-country cloud HSM under the authority's control instead of the authority's on-site HSM (DEV-003) | Vol 2, 8.2 | [@security-lead] |
| SEC-012 (Example) | Annex C | Complete the security questionnaire | M | C | Answered in Annex C form; consistent with volume 2 | Annex C | [@security-lead] |
| SEC-015 (Example) | A-7.9 | Independent penetration test before go-live and yearly | M | C | CREST-accredited tester; reports shared with the authority | Vol 2, 8.2 | [@security-lead] |
| [SEC-NNN] | [Ref] | [Requirement] | [Type] | [Status] | [Summary] | [Location] | [Owner] |
11. Implementation, service and support
| ID | RFP ref | Requirement | Type | Status | Response summary | Location | Owner |
|---|
| IMP-002 (Example) | 2.3 | Pilot live on two routes within nine months of contract start | M | C | Pilot live in week 30 (month 6.9), subject to dependency DEP-001 | Vol 2, 9.1 | [@delivery-lead] |
| IMP-006 (Example) | B-4.1 | Priority 1 incident response within 15 minutes, 24 by 7 | M | C | Service desk 24 by 7; matches the service schedule | Vol 2, 12.1 | [@service-manager] |
| IMP-009 (Example) | B-4.6 | Exit assistance for 12 months with full data export | S | NC | Exit assistance offered for 6 months; data export in open formats at any time (DEV-004) | Vol 2, 12 | [@delivery-lead] |
| IMP-011 (Example) | 2.7 | Train 40 customer service agents before pilot | S | ALT | Train-the-trainer for 6 authority trainers plus e-learning (DEV-005) | Vol 2, 9 | [@delivery-lead] |
| [IMP-NNN] | [Ref] | [Requirement] | [Type] | [Status] | [Summary] | [Location] | [Owner] |
12. Commercial, contractual and legal
| ID | RFP ref | Requirement | Type | Status | Response summary | Location | Owner |
|---|
| COM-001 (Example) | 6.1 | Prices fixed for the first three years | M | C | Fixed for three years; indexation from year four as per clause 9 | Commercial volume | [@commercial-lead] |
| COM-004 (Example) | B-12.2 | Supplier liability uncapped for data protection breaches | M | PC | Accept a cap at [n] times annual charges for data protection breaches (DEV-002) | Form F exceptions | [@contracts-manager] |
| COM-007 (Example) | B-15 | Authority owns intellectual property in custom deliverables | M | C | Authority owns the apportionment extension; product remains licensed | Commercial volume | [@contracts-manager] |
| [COM-NNN] | [Ref] | [Requirement] | [Type] | [Status] | [Summary] | [Location] | [Owner] |
13. Deviations, exceptions and alternatives
| ID | Requirement | Status | What we propose instead | Reason and effect on the client | Allowed by RFP rules? | Approved by |
|---|
| DEV-001 (Example) | NFR-034 | ALT | Five-second recovery point for the reporting store only | Reporting rebuilds from the event store; zero loss stays for taps and payments; lower running cost | Yes, alternatives allowed if the intent is met (RFP 4.9) | [@executive-sponsor] |
| DEV-002 (Example) | COM-004 | PC | Liability cap at [n] times annual charges for data protection breaches | Uncapped liability cannot be insured; the proposed cap is backed by cyber and professional indemnity cover of at least that amount | Exceptions to be listed on Form F | [@executive-sponsor] |
| DEV-003 (Example) | SEC-007 | ALT | In-country cloud HSM under authority control | Same key custody with no hardware on the authority's site | Yes (RFP 4.9) | [@security-lead] |
| DEV-004 (Example) | IMP-009 | NC | Six months of exit assistance; open-format export at any time | Longer assistance offered as a priced option | Scored, not a gate; declared on Form F | [@executive-sponsor] |
| DEV-005 (Example) | IMP-011 | ALT | Train-the-trainer and e-learning | Authority keeps the training capability for new staff | Yes (RFP 4.9) | [@delivery-lead] |
| [DEV-NNN] | [ID] | [Status] | [Proposal] | [Reason and effect] | [Rule] | [Approver] |
Every row with status ALT or NC in sections 6 to 12 must appear here, and every DEV row must point
back to at least one requirement ID.
14. Clarification questions log
| ID | Requirement | Question as submitted | Asked | Answer received | Effect on the matrix |
|---|
| CQ-001 (Example) | NFR-034 | Does the zero recovery point apply to reporting replicas rebuilt from source data? | YYYY-MM-DD | "Alternatives meeting the intent will be considered" | DEV-001 kept as ALT |
| CQ-002 (Example) | IMP-011 | Is the authority's training team available to deliver agent training? | YYYY-MM-DD | Yes, six trainers | IMP-011 answered as ALT with DEV-005 |
| CQ-003 (Example) | FR-041 | Is multi-level refund approval needed at pilot or at full service? | YYYY-MM-DD | At full service | FR-041 stays PC; release 2 date stated |
| [CQ-NNN] | [ID] | [Question] | [Date] | [Answer] | [Effect] |
15. Evaluation criteria mapping
| Criterion | Weight (Example) | Requirement IDs that feed it | Response sections | Pages | Share of pages |
|---|
| T1 Solution fit | 30% | FR-001 to FR-120, MAN-004 | Vol 2, 4 to 6 | 12 | 30% |
| T2 Quality and security | 20% | NFR-001 to NFR-038, SEC-001 to SEC-030 | Vol 2, 7 and 8 | 8 | 20% |
| T3 Delivery and risk | 20% | IMP-001 to IMP-005, IMP-010 to IMP-011 | Vol 2, 9, 10, 13, 14 | 10 | 25% |
| T4 Team and service | 15% | IMP-006 to IMP-009, IMP-012 to IMP-015 | Vol 2, 11 and 12 | 6 | 15% |
| T5 Experience | 15% | MAN-003 | Vol 2, 15 | 4 | 10% |
| Total | 100% | | | 40 | 100% |
Share of pages is pages divided by the 40-page limit. In the Example, T3 receives more space than
its weight and T5 less; that is a deliberate choice because delivery risk is the client's main
concern, and it is recorded here so reviewers can challenge it.
16. Coverage summary and metrics
16.1 Status by category
| Category | C | PC | ALT | NC | Total |
|---|
| Instructions (INS) | 12 | 0 | 0 | 0 | 12 |
| Mandatory (MAN) | 15 | 0 | 0 | 0 | 15 |
| Functional (FR) | 105 | 11 | 3 | 1 | 120 |
| Non-functional (NFR) | 31 | 4 | 2 | 1 | 38 |
| Security, privacy, accessibility (SEC) | 27 | 2 | 1 | 0 | 30 |
| Implementation and service (IMP) | 13 | 0 | 1 | 1 | 15 |
| Commercial and legal (COM) | 9 | 1 | 0 | 0 | 10 |
| Total | 212 | 18 | 7 | 3 | 240 |
All counts are Example values. Column totals: C 12 + 15 + 105 + 31 + 27 + 13 + 9 = 212; PC 11 +
4 + 2 + 1 = 18; ALT 3 + 2 + 1 + 1 = 7; NC 1 + 1 + 1 = 3; rows 212 + 18 + 7 + 3 = 240, which equals
the source register total in section 2. Rows marked NA or N get their own columns, are excluded
from the denominator of the full compliance rate, and their count is stated; the Example has none.
16.2 Quality metrics
| Metric | Formula | Target | Example value |
|---|
| Completeness | Rows with status, summary and location divided by all rows | 100% | 240 / 240 = 100% |
| Full compliance rate | C rows divided by all rows except NA and N | Report, no fixed target | 212 / 240 = 88.3% |
| Mandatory compliance | Type M rows that are C or NA, or ALT or PC as the RFP rules permit, divided by all type M rows | 100% | [n] / [n] |
| Deviation traceability | ALT and NC rows with a DEV row, divided by all ALT and NC rows | 100% | 10 / 10 = 100% |
| Evidence coverage | C rows with an evidence entry, divided by C rows | At least [90]% | [n] / 212 |
| Open clarifications | CQ rows without an answer at the question deadline | 0 | 0 |
The deviation traceability Example is 7 ALT plus 3 NC = 10 rows. Five DEV rows are shown in
section 13 as examples; a real matrix needs one DEV row for each of the ten, or a DEV row that names
several requirement IDs. One deviation (DEV-002) concerns a PC row, which is allowed: declare every
partial acceptance of a contract clause as an exception.
17. Compliance review and sign-off
| Check | Reviewer | Done |
|---|
| Every source in section 2 has been shredded, including addenda and published Q&A | [@compliance-lead] | [ ] |
| Every row has a status, a summary, a location and an owner | [@compliance-lead] | [ ] |
| Every location exists in the final documents at the stated section and page | [@reviewer] | [ ] |
| No mandatory requirement is NC; any ALT or PC on a mandatory row is permitted by the RFP (alternatives clause or exceptions form) | [@bid-manager] | [ ] |
| Every ALT and NC row is in section 13 with internal approval | [@bid-manager] | [ ] |
| Statuses match the technical, management and commercial volumes and the exceptions form | [@solution-architect] | [ ] |
| Service levels and dates match the draft contract schedules and the plan | [@delivery-lead] | [ ] |
| Final answers transferred to the issuer's response form without truncation | [@compliance-lead] | [ ] |
When every check is ticked, the approvers in Document control sign the matrix and the bid manager
freezes it as the submitted version.
18. Glossary and references
18.1 Glossary
| Term | Meaning |
|---|
| Shredding | Breaking an RFP into individual obligations, one per row, with their source |
| Atomic requirement | A requirement that contains one obligation and can be verified on its own |
| Mandatory requirement | A pass or fail condition; failing it usually excludes the bid |
| Scored requirement | A requirement that earns points under an evaluation criterion |
| Deviation | Any departure from a requirement or contract clause, declared by the bidder |
| Alternative (variant) | A different way of meeting the intent of a requirement, allowed only where the rules permit |
| Response location | Volume, section and page where the evaluator finds the full answer |
| [Term] | [Meaning] |
18.2 References
| ID | Reference | Version / date |
|---|
| REF-01 | Client RFP [reference], annexes and addenda (section 2) | YYYY-MM-DD |
| REF-02 | APMP Body of Knowledge (Association of Proposal Management Professionals), compliance matrix topic, online at bok.apmp.org | Current online edition |
| REF-03 | ISO/IEC/IEEE 41062:2024, Software engineering: Life cycle processes: Software acquisition | Edition 2, 2024-10 |
| REF-04 | ISO/IEC 25010:2023, SQuaRE: Product quality model | Edition 2, 2023-11 |
| REF-05 | US Federal Acquisition Regulation 15.204 (uniform contract format: Section C description, Section L instructions to offerors, Section M evaluation factors), for US federal solicitations | FAC 2026-01 (check acquisition.gov) |
| REF-06 | Directive 2014/24/EU on public procurement, Articles 45, 56 and 67 to 69 (variants, general principles of award, award criteria, life-cycle costing, abnormally low tenders), for EU public tenders | Check the consolidated text on EUR-Lex |
| REF-07 | RFP Technical Response (business/rfp-technical-response) | [x.y] |
Standard and licence note
Structure aligned with the compliance matrix practice described in the APMP Body of Knowledge and
with the acquirer's evaluation concerns in ISO/IEC/IEEE 41062:2024 and the product quality model of
ISO/IEC 25010:2023. These sources are copyrighted: only general concepts and names are used; all
text, legends, tables and examples are original and no definitions or checklists are reproduced.
Public procurement rules are cited by number only: for US federal bids check FAR Part 15 and any
agency deviations at acquisition.gov (Part 15 is being restructured), and for EU public tenders
check the consolidated text of Directive 2014/24/EU and the national law that transposes it. Always
follow the issuer's own legend, forms and rules over this template, and check the current editions
of the cited standards. This is a documentation format, not legal advice. APMP is a trademark of
its owner; this template is not affiliated with or endorsed by it. Template licence: MIT.