An identity-verification RFP that produces comparable answers
Start with agreed requirements, then ask every shortlisted supplier to answer the same questions about the exact service it is offering. This page provides a response sheet and scoring method. It is intended for comparing proposals, after the procurement checklist has defined the job.
Give suppliers one response format
For each requirement, request: requirement ID; proposed capability; product and configuration; evidence reference and date; limitations; delivery status; commercial dependency; and the person who can clarify the answer. Require suppliers to distinguish available production functionality from a pilot, a configurable option and a roadmap item.
Use a stable requirement ID in follow-up discussions. When an answer changes, keep the previous answer and date the revision. This makes it possible to check whether the contracted proposal still matches the solution that won the comparison.
| ID | Question to issue | Evidence to request |
|---|---|---|
| R1 | Which evidence and user populations does this configuration support? | Coverage list, validation depth and exclusions |
| R2 | What does each successful result establish? | Result schema and a worked decision example |
| R3 | Which attack and genuine-user cases were tested? | Scoped results, versions, thresholds and limitations |
| R4 | How do unsupported users, errors and appeals proceed? | Demonstrated fallback and support journey |
| R5 | What data moves through the proposed service? | Completed data worksheet and relevant contractual terms |
| R6 | What will operation and change cost? | Attempt, retry, review, minimum-volume and exit pricing |
Score capability and evidence separately
First mark each mandatory requirement as met, unresolved or not met. Then record confidence in the supporting evidence. A suggested evidence scale is: 0 for no support; 1 for an untested assertion; 2 for scoped documentation or a relevant demonstration; and 3 for current, reproducible evidence that fits the proposed configuration. This is a MyID working example, not a certification scheme.
Do not let an attractive total score cancel a failed mandatory requirement. Agree any weighting before opening proposals. Have the appropriate specialist review their field: a commercial reviewer can check price clarity, while a security reviewer assesses the relevance of attack-test evidence. Preserve disagreements and the evidence needed to resolve them.
Example: turn a marketing answer into a testable one
A weak answer to R3 says, “Our platform uses advanced liveness and is highly accurate.” It does not identify a configuration, attack population or result. A usable answer names the capture component and version, states which categories were tested, links the dated report and describes exclusions. It also identifies any difference between the tested service and the quoted offer.
That answer can still reveal a gap. If only a mobile SDK was tested but your service uses web capture, record the mismatch and request relevant evidence. Do not silently extend the result to the browser journey. Our deepfake controls guide gives a practical worksheet for this review.
Use a short clarification session well
- Send the unresolved requirement IDs in advance.
- Ask the supplier to demonstrate one normal and one failed journey in the offered configuration.
- Compare the application response with the claim made in the proposal.
- Record what was observed, what was only reported and what still needs evidence.
- Set an owner and due date for each material clarification.
Keep personal data out of a routine procurement demo where appropriate test data will do. Do not ask a presenter to expose another customer's documents, tokens or internal systems as proof. A redacted report can be useful if the scope and limitations remain clear; confidentiality does not turn a missing answer into a confirmed capability.
Write the recommendation a reviewer needs
The final recommendation should explain the selected configuration, mandatory gaps, material trade-offs, expected cost and conditions that must be satisfied before launch. Include a declined or deferred option where that explains the decision. A one-page summary backed by the response sheets is more useful than an unexplained leaderboard.
Use the data worksheet for processing questions and the contract checklist for accepted commitments. The procurement guide remains the starting point for requirements. For primary technical context, consult NIST SP 800-63A-4; for processor relationships, consult the DPC's guidance. The scoring example above is editorial guidance, not a legal or compliance determination.
Reviewed 23 September 2026. Worked examples and worksheets are MyID editorial guidance. Check the linked primary material and your service requirements before making a consequential decision.
In this topic: Buying, privacy and implementation
How should a buyer define, procure, pilot and govern identity services?
View all 12 pages in this topic
Next useful pages
Follow the Irish evidence
Get the business briefing when Irish wallet, verification and age-assurance evidence changes.
Join the business briefing