Data Processing Agreement

This agreement is the contract required by Article 28 of the UK GDPR. It is between the customer named on the verification account (you, the controller) and VenueOra Ticketing Limited (we, the processor) for guest personal data. It is effective on 7 October 2026. Version 1.0.

It is part of the Terms of Service. If this agreement and the Terms conflict on a point of data protection, this agreement prevails on that point. The Privacy Policy explains the same processing in plain language, including where we are a controller of account and billing data. That account data is outside this agreement.

1. What this agreement covers

1.1 We process personal data about guests on your behalf when you use the verification service: the hosted check, the portal, the API, and webhooks.

1.2 This agreement lasts for as long as we process that data for you. It starts when you accept the Terms.

1.3 We process guest data to provide the check you asked for. We do not use it for marketing or to train a model. Account, billing, and security logs about your users are outside this agreement. For that data we are the controller, as the Privacy Policy explains.

2. Definitions

Words defined in the UK GDPR, including personal data, processing, controller, processor, and personal data breach, have the same meaning here.

Applicable law means the UK GDPR, the Data Protection Act 2018, and the Privacy and Electronic Communications Regulations 2003.

Guest data means the personal data described in Schedule 1.

Sub-processor means a third party we engage to process guest data for us.

3. Our instructions

3.1 We will process guest data only on your documented instructions, unless UK law requires something else. If the law requires something else, we will tell you before processing unless the law forbids that notice.

3.2 The Terms, this agreement, your settings in the portal, and the API calls you make are your instructions. Those instructions are to host the check, read the images, produce a result, show it to your authorised users, send it to the webhook you configure, and delete it on the timetable in Schedule 1.

3.3 We will tell you if we believe an instruction breaks applicable law. We may suspend the affected processing until you confirm or change the instruction. We are not your legal adviser, and a failure to raise a concern is not confirmation that the instruction is lawful.

3.4 We will not use guest images, document images, or identity fields to train or improve a machine-learning model. A setting in the product that would copy images for training stays switched off, and it does not become an instruction under this agreement. Training would need a separate written agreement and a lawful Article 9 basis of its own, which a toggle on your account does not provide.

4. Your duties as controller

4.1 You decide the purpose of each check and the minimum age. You confirm that you have an Article 6 basis and, because face images are used to identify a person, an Article 9 condition. For most events the Article 9 condition will be the guest’s explicit consent, given before the capture starts. You will not instruct us to process guest data without that basis.

4.2 You will give the guest a privacy notice they can read before they are asked for a face or a document. The notice will say that they will be asked for a face capture and a photograph of an identity document, that biometrics are used to compare the face with the document, that the check is automated with a human review available, how long the images are kept, and how to contact you. White-label branding does not remove this duty.

4.3 You will carry out a data protection impact assessment before you rely on the service, and you will consult the ICO first if the assessment says you should. We will provide the information about our processing that you reasonably need for that assessment. Schedule 1 is written to support it.

4.4 Where a result has a legal or similarly significant effect on a guest and it was reached by automated rules, you will provide the safeguards in Article 22, including a way for a person to review the result, for the guest to state their view, and for the guest to contest it. The portal lets an authorised user change an automated approval or decline.

4.5 You will not describe a result as proof that a document is genuine, that we queried an issuer, or that the guest’s identity or age is certain. The Terms, clause 4, are part of your instructions to your own staff.

4.6 You are responsible for the lawfulness of any metadata you attach to a session and of any brand materials you upload.

5. Our duties as processor

5.1 We will process guest data for the subject matter, duration, nature, and purpose in Schedule 1, and only for the categories of people and data listed there.

5.2 We will make sure that people we authorise to process guest data are bound by confidentiality.

5.3 We will apply the security measures in Schedule 3, and we will review them when the risk changes.

5.4 We will assist you, taking into account the nature of the processing, with requests from guests to exercise their rights. If a guest contacts us directly, we will pass the request to you promptly and will not answer it on the merits except on your instruction or where the law requires us to.

5.5 We will assist you with your duties on security, breach notification, impact assessments, and prior consultation, to the extent the processing we do makes that assistance relevant and you do not already have the information.

5.6 At the end of the service we will delete guest data as Schedule 1 describes, unless UK law requires us to keep it. You may export a decision record through the portal or the API before the account closes, while we still hold it.

5.7 We will make available the information reasonably necessary to show that we comply with Article 28, and we will allow the audits in clause 10.

6. Sub-processors

6.1 You give us general written authorisation to use sub-processors. The ones in place at the date of this agreement are listed in Schedule 2.

6.2 We will tell you before we add or replace a sub-processor that will process guest images or identity fields. Notice will be by email to the account, at least 14 days in advance, unless the change is needed sooner to contain a security incident. You may object on reasonable data-protection grounds within that period. If we cannot reasonably run the check without that sub-processor, and we cannot offer an alternative, you may stop using the service and we will end the affected processing.

6.3 We will impose data-protection terms on each sub-processor that are no less protective than this agreement. We remain responsible to you for a sub-processor’s performance of those terms.

6.4 Amazon Rekognition is used to compare faces. Images are submitted for the comparison and are not enrolled in a face collection. OpenAI is used only for the synthetic-image check described in the Terms. A capture is sent for that check and is not used by us for any other purpose.

7. International transfers

7.1 Storage and face comparison run in the United Kingdom.

7.2 Where a sub-processor processes guest data outside the UK and there is no adequacy regulation, we will put in place a UK GDPR Chapter V safeguard before the transfer, and we will tell you the safeguard if you ask. At the date of this agreement the guest-data transfer of this kind is the synthetic-image check, which sends a capture to OpenAI in the United States. We do not send that capture unless OpenAI’s data processing terms include the UK Addendum or the International Data Transfer Agreement.

7.3 You authorise those transfers, provided the safeguard is in place.

8. Personal data breaches

8.1 We will tell you without undue delay after we become aware of a personal data breach affecting guest data, and in any event within 48 hours where that is practicable. The notice will describe, so far as we know them, the nature of the breach, the categories and approximate number of people and records, the likely consequences, and the measures we have taken or propose.

8.2 You are responsible for deciding whether to tell the ICO and the guests, and for making those notifications within the statutory time. We will give you the further information you reasonably need as it becomes available.

8.3 A failed webhook, a guest who abandons a session, or a check that returns needs review is not by itself a personal data breach.

9. Biometric data

9.1 Face images compared with a document portrait are biometric data processed for the purpose of uniquely identifying a natural person. They are special category data. Document images and the fields read from them are guest data, and they can also reveal nationality or ethnic origin. We process them only as part of the check.

9.2 We will not retain biometric images beyond Schedule 1, will not combine them with data from other customers for our own purposes, and will not use them to recognise a person across different customers. A device hash is scoped to your account. It links a returning device to earlier checks you ran. It is not a face template.

9.3 You will not instruct us to run a check on a person who has not been asked to complete it, and you will not use the service as covert surveillance.

10. Audits

10.1 We will, on request, provide a summary of the security measures in Schedule 3 and answers to reasonable written questions about our compliance with this agreement, no more than once in any 12 months unless you have a justified suspicion of a breach or a regulator asks you to.

10.2 If a written report is not enough, you may, on at least 30 days’ notice, inspect the parts of our operation that process guest data. The inspection will be during working hours, will not disrupt the service, and will be subject to confidentiality. You will pay your own costs and any reasonable cost of staff time we incur. Access to another customer’s data, to our models, and to security details that would weaken the service can be refused, with an alternative that still lets you assess compliance.

10.3 We will cooperate with the ICO in relation to the processing we do for you.

11. Liability

11.1 Each party’s liability under this agreement is subject to clause 16 of the Terms, except that nothing limits liability for a fine or a compensation claim to the extent the law does not allow that limit.

11.2 Where both parties are responsible for the same damage under Article 82, liability between us follows Article 82. This clause does not affect a guest’s rights against either party.

11.3 You will indemnify us against a claim by a guest or a regulator to the extent it arises from your instructions, your lack of a lawful basis, or your failure to provide a privacy notice or an Article 22 safeguard. We will indemnify you against a claim to the extent it arises from our processing outside your instructions or our failure to apply Schedule 3. Clause 16.1 of the Terms still applies.

12. General

12.1 This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction.

12.2 Notices under this agreement go to dpo@venueora.com and to the email on your account.

12.3 A change to Schedule 2 or Schedule 3 that does not reduce the protection of guest data may be made by the notice in clause 6.2 or by posting an updated version of this agreement. Any other change follows clause 19 of the Terms.

Schedule 1. The processing

Item	Detail
Subject matter	Hosted age and identity checks on images the guest captures.
Duration	The subscription, plus the retention periods below.
Nature	Collect, store, read, compare, transmit to you, and delete.
Purpose	Produce a result for the minimum age and the document and face checks you configured, and keep a record of that result.
Data subjects	Guests you invite to a check. They may include people under 18 where the check is an age check.
Categories of data	Face video and stills; document images; a photo of the guest holding the document; identity fields read from the document (name, date of birth, age, sex, nationality, document number, address, issue and expiry dates, issuing country); outcome, reasons, flags, and reviewer notes; your reference; IP address; network location; location the guest chooses to share; device and browser details; device and network hashes.
Special category data	Biometric face data used to identify the guest against the document. Document data may reveal racial or ethnic origin.
Recipients	Your users, the webhook endpoint you name, and the sub-processors in Schedule 2.
International transfers	Synthetic-image check to OpenAI in the United States, under clause 7. All other guest-data processing in this schedule is in the United Kingdom.
Retention	Images, identity fields, precise location, device details, and webhook bodies: 30 days, extended while a check waits in review and for 30 days after a manual decision. Outcome and decision record, including device and network hashes: up to six years, then deleted or stripped of identifiers.
What the check does not do	No query to an issuer or government database. No passport chip read. No face collection. No model training on guest images.

Deletion of images and identity fields on the 30-day clock is automatic. A check that is still in review is excluded so that a person can see the evidence.

Schedule 2. Sub-processors

Sub-processor	Processing	Location
Amazon Web Services	Application hosting, database, and storage of images and records	United Kingdom (London)
Amazon Web Services, Rekognition	Face comparison for a single check. Images are not stored as a face collection.	United Kingdom (London)
OpenAI	Synthetic-image check on a capture	United States
Cloudflare	Delivery of the guest page and network location	As described in Cloudflare’s UK GDPR terms
Resend	Email to your users about the account. Guest images are not included.	United States
Ryft	Subscription payments for your organisation. Guest images are not included. Ryft is an independent controller of the card data it needs for its own duties.	United Kingdom

Schedule 3. Security

We maintain measures appropriate to the risk of processing biometric and identity-document data, including:

• hosting and storage in the London region;
• encryption in transit (HTTPS) and encryption at rest, with additional application-layer encryption of identity fields, location, and device details;
• access to the portal split by role, with the option or requirement of an authenticator app;
• passwords stored only as argon2id hashes, API tokens stored only as hashes after they are shown, and webhook signing secrets stored encrypted;
• private storage for images, not public buckets;
• automatic deletion of images and identity fields on the Schedule 1 clock;
• separation between customers, so one account cannot read another account’s checks;
• logging of administrative access and of decisions; and
• a process for investigating a suspected personal data breach and notifying you under clause 8.

We do not promise that a particular certification badge is held unless we have told you that certification in writing.