Security & data protection

A company that handles verification data has to earn this page.

KeyProof asks hirers to prove who they are. That only works if the proof itself is handled carefully. This page explains how we design for that, what protects the site today, and what we will not do with the data. Plain English, and honest about what is live versus still being built.

The register

CompanyKeyProof Ltd, no. 17333773Check it

ICO registerZC195906Check it

InsuranceProfessional indemnity and cyber, Hiscox, in force Details below

Sub-processorsEvery provider named, published The list

Evidence sealsCheckable by anyone holding a pack, no account Check a seal

Phone0330 122 5455

Data protectionprivacy@keyproof.co.uk

Every line above is a public record or a working contact. Before you trust any verification provider with your hirers, yours or anyone else’s, ask for their company number, their ICO registration and their insurance. If they cannot show you all three, that is your answer.

Verifying a hirer is not the same as keeping their ID

The usual way of checking a hirer leaves the firm holding a folder of passport and licence photos it now has to protect. KeyProof is built the other way round. You get a verified result and a dated record; the raw identity documents are never yours to keep, because they were never ours to keep either. That is the selling point, not a footnote: you prove who your hirer is without becoming the thing a data breach is looking for.

  • You stay the controller, we are the processor. Each hire firm is the controller of its own hirers and decides why their data is collected. KeyProof processes it only on that firm’s written instructions, under an agreement that meets Article 28 of the UK GDPR. The full split between the two roles is in the privacy notice.
  • Stripe holds the ID, we hold the result. Photo ID and the live selfie run through Stripe as the regulated provider. KeyProof stores the pass-or-fail outcome and a session reference, not the passport or licence image.
  • The signed terms are sealed, not just stored. At the moment the hirer signs, the exact text of your agreement is snapshotted and hashed with SHA-256, and the hash is kept with the booking. That makes the terms tamper-evident: any later change to the words is detectable, by anyone holding the record. It does not make the rest of the record tamper-proof, and nothing here claims it does.
  • Hirer data deletes on a schedule, in code. A DVLA share code is erased 30 days after signing; the booking record is deleted in full 24 months after the hire ends, unless a dispute, a claim or a fine on that hire is still open. Deletion runs on its own rather than waiting for anyone to remember.
  • Registered, and named. KeyProof is operated by KeyProof Ltd, company no. 17333773, registered with the ICO under ZC195906. Registration is a legal duty met, not a badge of approval: nobody has certified or audited KeyProof, and this page does not claim they have.

The design principle: hold less

The safest data is data we never store. KeyProof is designed around outcomes, not documents:

  • Results, not ID documents. Identity checks run on Stripe Identity, on every hirer link. Stripe is the regulated provider: it holds the photo ID and the live selfie and matches one to the other. KeyProof records the outcome (verified or not, licence valid or not), not a copy of the passport or licence for the operator to keep.
  • The operator sees a result, not a file of IDs.At handover the operator can view the hirer’s verified live selfie to confirm the person collecting the car is the person who verified. The view is bounded: it works only where the hirer’s recorded consent named that view, only within the 48-hour window after the check in which Stripe releases the image, and only for the firm the booking belongs to, and every view is logged on the hire’s record. The image is fetched live from Stripe for the view and is never stored by KeyProof. It stays switched off until its own data protection impact assessment is co-signed by both founders in the product, which is the gate rather than a promise about one. There is no downloadable pile of identity documents sitting in a portal.
  • Retention is a promise with code behind it. Our privacy notice sets out how long each kind of data is kept, and deletion runs automatically rather than relying on someone remembering.

What protects the site today

The personal data KeyProof handles is what you send through our forms and what hirers submit through the live check-in. That is protected by:

  • Encryption in transit. The whole site is HTTPS only, and the non-www and www addresses resolve to one canonical origin.
  • Encryption at rest. The data we store sits on our database and file-storage providers, which encrypt it at rest on their infrastructure. The providers, and what each holds, are on the sub-processors page.
  • A UK/EU database region for enquiry and signup data, with access limited to the two founders.
  • Rate limiting and abuse controls on every public form, so they resist automated abuse.
  • Separate authenticated access for the founders’ HQ, which holds no hirer verification data.
  • A short list of vetted providers. Every third-party service we use, what it handles and where, is published on our sub-processors page. Nothing is added there before it is actually in use.
  • One firm cannot read another firm’s data, and that is machine-checked. Every query is pinned to the firm the signed-in person belongs to. The boundary is not asserted in a comment: a test suite seeds two firms in a real database, calls the real API routes as each of them, and asserts both that the other firm’s record comes back as not found and that the other firm’s row did not move. Those suites are required to run before anything ships.
  • Production can only be reached through the pipeline. The hosting provider’s own deploy-on-push trigger is switched off, so pushing code does not release it. The one route to production type-checks, runs the full test suite including the isolation suites against a real database, applies the schema and only then deploys. A failing suite is not a live change.

How the live checks are protected

The hirer check-in (identity, licence share code, e-signature and the deposit record) was built with its paperwork already in place: a data protection impact assessment per flow, a data-processing agreement with each provider, and the privacy notice and sub-processor list updated in the same release. Identity verification runs on Stripe's hosted pages, so ID documents are handled by Stripe and are not stored by KeyProof; we keep the outcome of the check, not the documents. The one deliberate exception is the handover selfie viewer described above, which cannot be switched on until its own impact assessment is co-signed and the hirer consent wording names that view. The consent wording shipped; the co-signature is the remaining gate. The order is deliberate: the paperwork exists before the data does, not after.

Insured

KeyProof Ltd carries professional indemnity and cyber and data protection insurance with Hiscox (Hiscox Insurance Company Limited), in force from 30 July 2026. It is the company’s own cover, not a policy that insures hirers or hire firms directly.

Professional indemnity backs the work KeyProof does; the cyber and data policy backs the systems that hold verification data. The cover is with Hiscox.

£1mProfessional indemnity
£500kCyber and data

Who is accountable

KeyProof is operated by KeyProof Ltd, registered in England & Wales, the data controller for the site. The full detail, including your rights and how to exercise them, is in the privacy notice. Data-protection enquiries go to privacy@keyproof.co.uk.

Found a security problem?

If you believe you have found a vulnerability in keyproof.co.uk, email security@keyproof.co.uk with enough detail to reproduce it. We read every report, we will not take legal action against good-faith research, and we ask that you give us a reasonable window to fix the issue before publishing anything.