Make the identity-provider contract usable in an incident
A contract should connect the service you evaluated to the service you can actually operate. Use this checklist after requirements and supplier evidence have been reviewed. It covers operational questions to settle with your commercial and legal advisers, not model legal clauses.
Attach the service that was selected
Name the product, modules, integration model, regions, supported methods, configuration responsibilities and release policy. Identify the documents that describe acceptance and the order in which conflicting documents apply. A proposal can lose practical meaning if the contract refers only to a broad product family.
Link material commitments to evidence from the RFP response sheet and the data worksheet. If a capability remains planned, make its status and consequence explicit. Avoid treating a roadmap slide as a delivered acceptance condition.
Define what the service level measures
| Term | Question to settle |
|---|---|
| Availability | Which customer operation is measured, over what period and from which observation point? |
| Latency | Which percentile, transaction type and load apply? Are retries included? |
| Exclusions | How are maintenance and dependency failures recorded and reported? |
| Support | Who assigns severity, when does the clock start and what hours are covered? |
| Remedy | What happens after repeated or material failure, beyond a service credit? |
For illustration, a 30-day month contains 43,200 minutes. A 99.9% availability target leaves 43.2 minutes outside the target before any agreed exclusions. This calculation does not tell you whether the provider measures successful checks, an API endpoint or something else. A responsive endpoint can still leave customers unable to complete the intended journey.
Define the operation that matters to your business and preserve the supporting measurements. Keep technical availability separate from a customer's eligibility result. A legitimate rejection should not automatically count as downtime; a technical error should not be disguised as a rejection.
Agree an incident handover
Ask what the first notification contains, who receives it, how follow-ups arrive and who can authorise a fallback. Distinguish acknowledging a support ticket from restoring service or providing an investigation report. Have a route for incidents affecting data as well as ordinary service disruption.
The DPC's controller/processor guidance explains required processing-contract provisions, including assistance, audit information and deletion or return. It also distinguishes additional negotiated provisions. Have your advisers determine the applicable obligations and contract wording; this operational checklist does not set a universal notification deadline or liability position.
Protect the configuration you accepted
Discuss notice and review arrangements for changes to capture components, thresholds, document coverage, SDK support and processing locations. Identify who decides whether a change requires renewed testing. Your operating team should be able to connect a changed outcome to a known release rather than discovering it through a run of customer complaints.
For example, if a previously supported phone version is deprecated, establish when notice arrives, what the alternative journey is and who updates customer guidance. This is an operational dependency to agree before signing, not an assumption that all product changes can be prevented.
Rehearse a small exit before a large dependency
- List the decision records and configuration information your organisation needs to retain.
- Agree a usable export format and identify what cannot be transferred.
- Test an authorised sample export against the receiving team's needs.
- Clarify transition support, charges and timing.
- Document deletion or return, retained exceptions and evidence of completion.
Portability of records is different from portability of the whole verification service. A new supplier may use different evidence or result semantics. Give engineering and support time to assess that gap rather than assuming a CSV export removes every switching cost.
Final operational acceptance
Ask the service owner, support lead, engineering lead and privacy reviewer to confirm their parts of the handover. Keep unresolved terms in the decision record with the consequence of accepting them. Use the implementation guide for project ownership and the pilot plan for release criteria. The contract should make the agreed service understandable when the original buying team is no longer in the room.
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