> The data processing agreement for customers integrating the Check Share Code API.

Web version: https://checksharecode.co.uk/legal/dpa · Sign up: https://checksharecode.co.uk/signup?ref=md · Last updated: 2026-10-17

# Data Processing Agreement

Last updated 2026-10-25.

A countersignable PDF version is available for procurement teams:[Download PDF](https://checksharecode.co.uk/legal/dpa.pdf)

This Data Processing Agreement ("DPA") forms part of the [Terms of Service](https://checksharecode.co.uk/legal/terms) between you ("Controller") and Sharp Studios Ltd, a company registered in England and Wales with company number 15591412 ("Processor"). It governs our processing of personal data on your behalf.

## 1\. Subject matter and duration

The Processor processes, on behalf of the Controller, personal data of the people whose UK share codes or DVLA driving licence check codes the Controller checks, for the duration of the Service subscription. Processing is strictly transient: usually 5 to 40 seconds per check.

## 2\. Nature and purpose of processing

Driving a session against gov.uk's share code services (gov.uk/view-right-to-work, gov.uk/view-right-to-rent and gov.uk/check-immigration-status) to obtain the structured result on behalf of the Controller. Personal data processed includes: share code, applicant date of birth, applicant name (returned by gov.uk), nationality, photo, permission type or immigration status, conditions, expiry date, audit reference.

For driving licence checks, driving a session against DVLA's "Check a driving licence" service (viewdrivingrecord.service.gov.uk) to obtain the driver's licence record on behalf of the Controller. Personal data processed includes: the driving licence number as the Controller sends it (in full or its last 8 characters) and the check code (the last 8 characters and the code are sent to DVLA), and the record DVLA returns: the driver's name and title, driving status, licence issue number, the dates the licence is valid from and to, the vehicle categories the driver may drive (full and provisional) with their dates and restriction codes, the number of offences and penalty points, whether there are penalties or disqualifications, the date the record was viewed, and DVLA's PDF of the record. DVLA's service does not show, and the Processor does not obtain, the driver's date of birth, address or photo.

Offences and penalty points (endorsements) are personal data relating to criminal convictions and offences under Article 10 UK GDPR. Before checking a driving licence the Controller must have a lawful basis under Article 6 UK GDPR and meet a condition in Schedule 1 to the Data Protection Act 2018 (with an appropriate policy document where that Schedule requires one). The Controller must only check a driving licence with a check code the driver created and gave the Controller for that purpose, as DVLA's terms for the service require. DVLA's PDF is a record of the check, not proof of driving entitlement: DVLA does not accept printouts from its service as proof.

## 3\. Controller instructions

The Processor will only process personal data on the Controller's documented instructions, including those embedded in the API contract documented at [/openapi.json](https://checksharecode.co.uk/openapi.json). The Controller acknowledges that calling a check endpoint documented there, such as `POST /v1/check/right-to-work`, `POST /v1/check/right-to-rent`, `POST /v1/check/immigration-status`, `POST /v1/check/driving-licence` or their asynchronous versions (at either address the API answers on), with valid inputs constitutes a documented instruction to process.

## 4\. Retention

The Processor retains the inputs of each share code check (share code, date of birth, company name), and what a live request sent when the Processor refused it before sending it to gov.uk, and the pages the gov.uk service returned during it, including the result (which, for immigration status, records the checker's job title and the reason for the check), and the response the service returned for the check (without its photo and PDF files), for no more than 7 days, solely to investigate failed or disputed checks and to maintain the service. They are then deleted automatically. They are not used for any other purpose, not shared, and not accessible through the service.

The Processor retains the inputs of each driving licence check (the licence number exactly as the Controller sent it, in full or its last 8 characters, and the check code as sent), and what a live request sent when the Processor refused it before sending it to DVLA (including a check code already used), for no more than 7 days, solely to investigate failed or disputed checks and to maintain the service. They are then deleted automatically. They are not used for any other purpose, not shared, and not accessible through the service. Separately, because a check code works once, a keyed hash of the last 8 characters of the licence number and the check code (an HMAC, which cannot be turned back into either value) is kept for 21 days, the life of a check code, solely so that the same code is not sent to DVLA twice. The pages DVLA showed during every check, including the record it returned (which shows the end of the licence number and the check code), and the response the service returned for the check (without its PDF file), are kept for no more than 7 days, solely to investigate failed or disputed checks, to recover a record for the Controller, and to maintain and correct the Processor's reading of DVLA's service. When a check fails, other than DVLA refusing the code in a way the Processor's rules recognise, or needs the AI model described below (because DVLA's form or page has changed), the Processor also keeps for the same 7 days a recording of the check (screenshots, page snapshots and the network requests and responses of each step, including the form as sent and DVLA's PDF, which show the licence number and check code as entered). A page the Processor's own rules cannot read may be read by an AI model through OpenRouter (section 7), and what was sent to the model and its answer are kept with it for the same 7 days. A structural record of each check (its timings and outcome code, with no values from the check) is kept for 30 days to maintain the service.

Where the Controller uses asynchronous checks (the `/async` endpoints), the Processor also retains the result of each such check, including the PDF, encrypted, for no more than 7 days after the check finishes, solely to deliver it to the Controller and to let the Controller retrieve it again. It is then deleted automatically.

Sandbox checks retain no applicant data, other than the keyed hash of a sandbox driving licence check code, kept for 21 days as above. Audit log entries retain only request metadata (timestamp, outcome code, duration) with no identifying values. The Processor's request log, kept for 30 days, likewise holds only request metadata (time, endpoint path, response status, duration, the address used, the Controller's account and the first 16 characters of the API key), never the content of a request or response, so no applicant data.

## 5\. Confidentiality

The Processor ensures that persons authorised to process personal data are bound by confidentiality obligations.

## 6\. Security measures

-   TLS in transit for all API and dashboard traffic
-   API keys stored as SHA-256 hashes only; plaintext shown once at creation
-   No applicant PII written to logs (only timestamp + outcome + duration)
-   Service-role database credentials kept server-side; never exposed to the browser
-   Card data handled entirely by Stripe (PCI-DSS Level 1); never touches our servers
-   Applicant data held for at most 7 days in database tables with row-level security and no API access, then deleted automatically; no disk caches of applicant data
-   Results and inputs of asynchronous checks encrypted in the database (AES-256-GCM) with a key held outside it
-   Driving licence numbers and check codes held for at most 7 days, like other applicant data; after that only a keyed hash of a check code and the licence number's last 8 characters (HMAC SHA-256, with a key held outside the database), for 21 days

## 7\. Sub-processors

The Controller authorises engagement of the following sub-processors:

| Sub-processor | Purpose | Region |
| --- | --- | --- |
| Neon, LLC (a Databricks company) | Database | London (AWS eu-west-2) |
| Stripe Payments UK Ltd | Billing + Customer Portal | UK / EEA |
| Resend Inc. | Transactional email | EU |
| OpenRouter, Inc. | Reads a gov.uk or DVLA page the Processor's own rules cannot, with an AI model, only through providers that keep no data | United States |
| Fly.io Inc. | Compute + static hosting | London (LHR) |

We will notify Controllers by email of any addition or replacement of sub-processors at least 30 days in advance, allowing reasonable objection.

## 8\. International transfers

Processing takes place in the UK and EEA, with one exception listed in section 7: when the Processor's own rules cannot read a gov.uk or DVLA page during a check, its text may be read by an AI model through OpenRouter, Inc. (United States), only through providers that keep no data. Transfers within the UK and EEA rely on adequacy and need no Standard Contractual Clauses.

## 9\. Data subject rights

The Processor holds applicant personal data for no more than 7 days, apart from the keyed hash of a driving licence check code, held for 21 days. It will assist the Controller with any request for access, rectification, erasure, or portability from a data subject concerning applicant data it still holds, including by deleting that data early on the Controller's written request.

## 10\. Breach notification

The Processor will notify the Controller without undue delay (and in any event within 72 hours) of becoming aware of a personal data breach.

## 11\. Audit

The Processor will make available to the Controller all information necessary to demonstrate compliance with this DPA, and allow for audits conducted by the Controller or a mandated auditor on reasonable notice.

## 12\. Termination

On termination, the Processor will delete or return all customer personal data within 30 days. Applicant data is deleted automatically within 7 days of each check, and the keyed hash of a driving licence check code within 21 days.