From identity requirements to a working service
Use this guide to organise the project, rather than collect another list of supplier questions. At each stage, produce a decision someone can own: what the service must establish, which option fits, whether the pilot passed and who will operate it after launch.
Six stages with a concrete output
| Stage | Lead responsibility | Output before moving on |
|---|---|---|
| Define | Service owner with risk and privacy leads | A bounded transaction, user population and evidence requirement |
| Design | Product and engineering | A journey, data map and alternative route |
| Compare | Procurement with specialist reviewers | A shortlist supported by scoped evidence |
| Pilot | Delivery owner | Results against agreed acceptance and stop conditions |
| Agree | Commercial and legal leads | A defined service, responsibilities and exit arrangements |
| Operate | Named service and support owners | Monitoring, escalation, change review and a usable runbook |
One person may cover several roles in a small business, but every decision still needs an owner. A supplier can provide technical evidence; it cannot decide the purpose of your service or accept your organisation's residual risk on your behalf. Record unresolved dependencies with a person and a next action.
Choose the right working document
- Procurement checklist: define requirements before inviting proposals.
- RFP response sheet: request comparable answers and score their evidence.
- Vendor data worksheet: trace processing, access, retention and unresolved data questions.
- Contract and SLA checklist: turn accepted commitments into measurable operating terms.
These documents should refer to the same proposed configuration. Otherwise procurement may score a hosted service while privacy reviews an API product and engineering pilots a different SDK. Put the product, region, integration model and version or release policy on the cover of the project record.
Choose an integration your team can operate
A hosted flow can reduce the capture interface your team must build, but it creates a hand-off whose branding, return path and failure handling need testing. An SDK can fit more closely into your application, with ongoing platform and release work. A custom API integration gives more control while leaving more of the capture and error experience to your team.
Assess building, buying or using multiple providers against demonstrated requirements. A second supplier may address a real coverage gap; it also adds another contract, data path and support boundary. Before adding that complexity, establish whether the first provider's limitation matters to your actual users and whether a simpler fallback solves it.
Cost the successful outcome
Use an illustrative month to expose costs hidden by a price per check. Suppose 1,000 applicants produce 1,400 chargeable attempts at €1 each. Add 100 manual reviews at €4 and €500 in allocated support and platform costs. The total is €2,300. If 800 legitimate applicants complete the journey, that is approximately €2.88 per completion, before other costs or taxes.
These are fictional figures, not provider prices or a market benchmark. Replace them with your own volumes and quote terms. Check whether failed attempts, retries, minimum commitments and reviews are charged separately. Keep fraud losses and staff time visible rather than assuming a low transaction price captures the whole business case.
Decide what the pilot must prove
Choose a question such as whether the new journey reduces repeated data entry without excluding customers who need help. Agree the sample, devices, failure cases, measurement and decision threshold in advance. Use the pilot plan to keep an experiment from becoming an unexamined production launch.
The NIST identity-proofing guidance provides useful technical context, while the DPC explains controller and processor responsibilities. Neither replaces the organisation's decision about applicable Irish requirements, its intended population or the evidence needed for its service.
Require a handover someone can use
Before launch, have a support colleague walk through an outage, a customer appeal and a supplier change using the proposed runbook. They should be able to find the current configuration, escalation contact, approved fallback and decision owner. If the answer depends on the original project team's memory, handover is incomplete.
After launch, compare completion, retries, technical failures, reviews and complaints with the baseline. Split the results by meaningful journey differences where the data supports it. Set a review after material changes and keep the exit plan current. The project is complete when the operating team can manage the service, not merely when an integration returns a successful response.
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