# 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`).

<!--
Guidance: How to use this template
- Start the matrix on the day the RFP arrives, before anyone writes prose. The matrix is the
  outline of the response, the work allocation and the final compliance check in one table.
- One row per atomic requirement. Split sentences that contain two obligations; never merge two
  requirements into one row.
- Never edit the issuer's requirement text. Quote it or cite its clause; put your interpretation
  in the response column and, when it is uncertain, raise a clarification question (section 14).
- If the RFP provides its own response form, that form wins: keep this matrix as the internal
  working copy and transfer the final answers into the issuer's form.
- A "Not compliant" on a mandatory requirement usually means disqualification. Escalate it to the
  bid decision owner at once (Opportunity Qualification, `business/opportunity-qualification`).
- Related: Request for Proposal (`business/rfp`), RFP Technical Response
  (`business/rfp-technical-response`), Vendor Evaluation Scorecard
  (`business/vendor-evaluation-scorecard`), Traceability Matrix (`requirements/traceability-matrix`),
  NFR Catalogue (`requirements/nfr-catalogue`), Statement of Work (`business/statement-of-work`).
-->

## Document control

<!-- Guidance: Pin the exact RFP version and addenda. A matrix built on a superseded version is the most common cause of a late, silent non-compliance. -->

| 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](#1-purpose-and-rules)
2. [Source documents and addenda](#2-source-documents-and-addenda)
3. [Requirement extraction method](#3-requirement-extraction-method)
4. [Status legend and response rules](#4-status-legend-and-response-rules)
5. [Matrix columns](#5-matrix-columns)
6. [Instructions to bidders](#6-instructions-to-bidders)
7. [Mandatory and pass or fail requirements](#7-mandatory-and-pass-or-fail-requirements)
8. [Functional requirements](#8-functional-requirements)
9. [Non-functional requirements](#9-non-functional-requirements)
10. [Security, privacy and accessibility](#10-security-privacy-and-accessibility)
11. [Implementation, service and support](#11-implementation-service-and-support)
12. [Commercial, contractual and legal](#12-commercial-contractual-and-legal)
13. [Deviations, exceptions and alternatives](#13-deviations-exceptions-and-alternatives)
14. [Clarification questions log](#14-clarification-questions-log)
15. [Evaluation criteria mapping](#15-evaluation-criteria-mapping)
16. [Coverage summary and metrics](#16-coverage-summary-and-metrics)
17. [Compliance review and sign-off](#17-compliance-review-and-sign-off)
18. [Glossary and references](#18-glossary-and-references)

## 1. Purpose and rules

<!-- Guidance: State what the matrix is for and the rules every contributor follows. Questions: who owns the matrix, who may change a status, and when is it frozen? Pitfall: several people editing statuses without review, so the final matrix promises things the solution does not do. -->

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

<!-- Guidance: List every document that can contain a requirement, including the draft contract, forms, Q&A answers and addenda. Questions: which version of each, when received, and what changed? Pitfall: forgetting that answers to other bidders' questions often change requirements for everyone. -->

| 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

<!-- Guidance: Describe how requirements were found so that a reviewer can repeat the work. Questions: which words signal an obligation, how are compound requirements split, how are implied requirements recorded? Pitfall: extracting only the numbered requirement tables and missing obligations buried in instructions, the contract or the evaluation section. -->

### 3.1 Process

Run the extraction once per source document and again for every addendum and answer round.

```mermaid
flowchart LR
  A[Receive RFP and addenda] --> B[Register sources]
  B --> C[Shred: extract each obligation]
  C --> D[Classify type and category]
  D --> E[Assign owner and response location]
  E --> F[Draft status and answer]
  F --> G[Review: solution, delivery, legal]
  G --> H{Gaps or doubts?}
  H -->|Yes| I[Clarification question or deviation]
  I --> F
  H -->|No| J[Freeze and transfer to issuer form]
```

### 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

<!-- Guidance: Agree the legend before drafting. Use the issuer's legend if the RFP prescribes one and map these codes to it. Pitfall: writing "Compliant" when the requirement is met only through configuration that has not been tested, or only in a future release. -->

### 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

<!-- Guidance: Keep one master sheet with every column below for all rows, so it can be sorted, filtered and counted as one table. The section tables that follow show only the columns that matter most for each category. Pitfall: columns filled in for some sections only, which breaks the coverage counts. -->

| 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

<!-- Guidance: Record every submission rule as a requirement. Questions: format, page limits, file names, number of copies, portals, deadlines, mandatory forms and declarations? Pitfall: treating instructions as administration rather than requirements; breaking one can exclude the bid unread. -->

| 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

<!-- Guidance: Collect every gate the issuer applies before scoring: eligibility, certifications, insurance, financial standing, exclusion grounds, minimum experience. Questions: can we prove each one with a document dated before the deadline? Pitfall: assuming a group company's certificate covers the bidding entity. -->

| 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

<!-- Guidance: Answer each functional requirement with status and fit, and point to the narrative in the technical volume. Questions: is the capability demonstrable, and in which demo scenario? Pitfall: "Compliant, standard" on every row; evaluators test the doubtful ones in demonstrations. -->

| 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

<!-- Guidance: Group non-functional rows by quality characteristic so gaps show. The characteristics of ISO/IEC 25010:2023 make a good checklist even when the issuer groups them differently. Pitfall: accepting a target such as zero data loss everywhere without stating what it costs or proposing a sensible alternative. -->

| 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

<!-- Guidance: When the RFP attaches a security questionnaire, answer it in its own form and keep only overarching rows here, with a pointer. Questions: where is data stored and processed, who can access it from where, which certifications cover which scope? Pitfall: answering the questionnaire from a sales template that contradicts the architecture in the technical volume. -->

| 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

<!-- Guidance: Cover delivery, migration, training, documentation, service levels, support hours and exit. Questions: does every service level here match the service schedule in the draft contract and the commercial volume? Pitfall: promising a go-live date without stating the client dependencies it rests on. -->

| 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

<!-- Guidance: Shred the draft contract like the requirements. Every clause you cannot accept is a deviation that must be declared, usually in a form the issuer prescribes. Pitfall: declaring no exceptions and then negotiating them after award, which many issuers forbid and evaluators remember. -->

| 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

<!-- Guidance: List each deviation once, with the reason and the benefit or cost to the client. Questions: is the deviation allowed by the RFP rules, does it touch a mandatory requirement, and who approved it internally? Pitfall: an alternative presented as a variant when the RFP forbids variants; read the rules on alternatives first. -->

| 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

<!-- Guidance: Ask early, before the issuer's question deadline, and phrase questions so the answer helps you without revealing your solution; answers are usually published to all bidders. Pitfall: building the response on an assumption that a clarification question could have settled. -->

| 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

<!-- Guidance: Map each evaluation criterion to the requirements and response sections that earn its points. Questions: where will the evaluator look for each criterion, and is the space we give it proportional to its weight? Pitfall: spending pages on low-weight topics because the team knows them well. -->

| 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

<!-- Guidance: Recompute this table from the matrix itself before every review. Questions: is every row answered, located and owned, and do the totals match the source register? Pitfall: a summary typed by hand that no longer matches the rows. -->

### 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

<!-- Guidance: Run the review as a separate pass by someone who did not write the answers, reading the final response against the matrix. Pitfall: checking the matrix against itself instead of against the documents that will be submitted. -->

| 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

<!-- Guidance: Define the status codes and terms the issuer and the bid team use. List only the sources used. -->

### 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.