Privacy Policy

This policy explains how VenueOra Ticketing Limited uses personal data in the VenueGo verification service, also called Protect Events. It is effective on 7 October 2026. Version 1.0.

It sits alongside the Terms of Service and the Data Processing Agreement. It does not describe VenueOra ticketing, memberships, payouts, or LockVault.

1. Who we are

1.1 VenueOra Ticketing Limited is a company registered in England and Wales, number 17098285. The registered office is 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ. For the verification service you can reach us at dpo@venueora.com or hello@venuego.co.uk.

1.2 A controller must pay the data protection fee unless an exemption applies. The public register is at ico.org.uk.

2. Two different roles

2.1 For a business customer and its staff, we are the controller of account, billing, support, and security data. This policy is the notice for that data.

2.2 For a guest who completes a check, the business that sent them (the venue, promoter, or operator) is the controller. We are that business’s processor. We use the images only to run the check the business asked for, and to keep the decision record described below. If you completed a check on a page branded as an event, start with that event’s privacy notice. You can still write to us, and we will pass the request to the controller or help them answer it.

2.3 A white-label page shows the customer’s name and colours. That branding does not make us the controller of the guest’s check.

3. If you are completing a check

3.1 The operator who sent you the link decides why the check is required and which minimum age applies. On the page you will be asked to:

• record a short video of your face, with stills, including a turn and a closer view;
• photograph a passport or a driving licence issued in the United Kingdom, Ireland, or the United States, and the back of a licence; and
• photograph yourself holding that document.

3.2 We read those images. We compare the face with the portrait on the document. We read the date of birth and compare it with the minimum age. We do not send the document to the passport office, the DVLA, or any other issuer, and we do not read a chip inside a passport.

3.3 The page can also receive:

• your IP address and, from our network provider, a coarse location derived from it;
• a location you choose to share from the phone, which you can refuse; and
• technical details of the browser and device, used to spot repeat devices and obvious automation.

3.4 The result is approved, declined, or waiting for a person at the operator to review. The operator can also ask a person to reconsider an automated result. The operator decides what happens next, such as whether a ticket stands.

3.5 Face images are used to check that the person in front of the camera matches the portrait on the document. That is biometric data. The operator must tell you this before you start and must have a lawful condition for using it. You can refuse. If you refuse, the operator decides whether you can carry on without the check. We do not use these images to train a model.

4. Account data we control

When a business opens and uses an account, we collect:

• the organisation name, the minimum age on the account, and the names and email addresses of users;
• a password, stored as an argon2id hash, and an authenticator secret if multi-factor authentication is turned on;
• login records, including IP address and time, for security;
• billing contact details, the plan, invoices, card brand, and the last four digits of the card;
• support emails and the contents of those conversations; and
• API token identifiers. A token is shown once and then stored only as a hash. Webhook signing secrets are stored encrypted, because we need them to sign each delivery.

We use this data to provide the account, take payment, keep the service secure, answer support requests, and meet tax and accounting duties.

5. Guest data we process for the operator

5.1 Depending on what the images contain and what the operator sends, a check can include:

• face video and stills, and a photo of the person holding the document;
• images of the document;
• fields read from the document, which can include name, date of birth, age, sex, nationality, document number, issuing country, address, and issue and expiry dates;
• the minimum age, the outcome, the reason codes, the review flags, and any note a reviewer writes;
• a reference or other metadata the operator attaches to the session;
• IP address, coarse network location, any location the guest shares, and device and browser details; and
• a keyed hash of the device and of the network, kept so a later check for the same operator can be linked to an earlier device.

5.2 Document fields can reveal nationality and, indirectly, racial or ethnic origin. We do not use them for that purpose. We use them to read the document the guest presented.

5.3 We do not sell guest data. We do not use it for our own marketing. We do not use it to train models.

6. Why we use data, and the lawful basis

Where we are the controller, we rely on these bases under the UK GDPR:

What we do	Basis
Provide the account, the portal, and support	Contract, Article 6(1)(b)
Take subscription payments and keep invoices	Contract, and legal obligation for tax records, Articles 6(1)(b) and 6(1)(c)
Keep logs, device hashes, and security records, and investigate misuse	Legitimate interests, Article 6(1)(f). The interest is keeping the service secure. You can object.
Send service emails about the account, billing, and changes to these documents	Contract and legitimate interests
Send marketing about the verification service	Consent, or the soft opt-in where PECR allows it. You can opt out in the message or by emailing us.
Respond to a court, the ICO, or another authority	Legal obligation or legitimate interests

Where we are the processor, the operator chooses the basis. Our instructions are in the Data Processing Agreement. A typical operator will need both an Article 6 basis and an Article 9 condition, because face images are used to identify a person. Consent of the guest is the condition most operators will be able to use. We do not decide that for them.

7. Who we share data with

We use the following providers to run the verification service. They may act as our processors or, for payments, as an independent controller of the payment data they need for their own regulatory duties.

Provider	What they do	Data	Where
Amazon Web Services	Hosting, database, file storage, and the application that runs the checks	Account data, images, and check records	London (eu-west-2)
Amazon Rekognition	Compares the live face with the portrait on the document. The images are not added to a stored face collection.	The face image and the document image for that comparison	London (eu-west-2)
OpenAI	Checks a capture for synthetic-image marks from OpenAI’s own image tools. A clear result does not prove the image is real.	The capture sent for that check	United States
Cloudflare	Delivers the site and provides the network location of a visitor	IP address and request data	Cloudflare’s network, under its UK GDPR terms
Resend	Sends our account and billing emails	Staff name and email address, and the content of the email	United States
Ryft	Takes the subscription card payment	Billing identity, amount, and card data entered in Ryft’s form. We do not receive the full card number.	United Kingdom

We may also share data with a professional adviser, an insurer, or an authority where the law requires it, and with a buyer of the business if they accept the same duties. The operator receives the result, and any fields the product returns to them, because they asked for the check.

We will give the operator notice before we add a provider who will see guest images, as the Data Processing Agreement describes.

8. Transfers out of the UK

8.1 The application, the stored images, and the face comparison run in London.

8.2 The synthetic-image check sends a capture to OpenAI in the United States. Account email is handled by Resend in the United States. Cloudflare may process connection data outside the UK.

8.3 Where personal data leaves the UK and there is no adequacy regulation, the transfer is made only with a UK GDPR Chapter V safeguard in the provider’s data processing terms. That safeguard is the UK International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses. You can ask us which one applies to a named provider.

9. How long we keep it

Data	How long
Face video, document images, the photo of the person holding the document, and the identity fields read from the document	Deleted 30 days after the check, or 30 days after a person decides a check that was in review. They are kept while a check is still waiting for review, so the reviewer can see them.
Precise location and the detailed device record	Same 30-day period.
Webhook payloads that contain those fields	Cleared after 30 days. The delivery log, without the body, is kept for 90 days.
The outcome, reason codes, review flags, reviewer notes, document type, country, minimum age, and the operator’s reference	Kept for up to six years from the decision, so that there is a record if a result is disputed, and then deleted or stripped of identifiers.
Device and network hashes	Kept with that decision record, for the same period, so a returning device can be recognised.
Account and user records	For the life of the account, and for up to six years after it closes.
Invoices and payment records	Six years, for tax.
Support emails	Three years from the last message in the thread, unless we need them for a claim.

Six-year periods follow the ordinary time limit for a contract claim in England and Wales. Where a legal claim or a legal duty requires a longer hold, we keep the relevant record for that claim or duty and then delete it.

10. Security

We encrypt guest identity fields, location, and device details at the application layer, as well as using the storage provider’s encryption. The portal is served over HTTPS. Passwords are hashed with argon2id. Access inside an account is split by role. We may require an authenticator app. No method of transmission or storage is perfectly secure.

11. Children

The service exists so an operator can apply a minimum age. A person under 18 may therefore complete a check, for example where the minimum age is under 18, or where someone under the minimum age attempts a check and is declined. We do not market the service to children. The operator is responsible for considering the Age Appropriate Design Code where their service is likely to be accessed by a child, and for not using a check to profile a child beyond the age decision.

12. Automated decisions

The rules can approve or decline a check without a person. That can affect whether the operator sells a ticket or allows entry. UK GDPR Article 22 can apply to that kind of decision. The operator must offer a way for the guest to have a person review it. The product supports that: uncertain checks wait for review, and an authorised user can change an automated approval or decline. Where our staff review a check, the operator can still change the outcome.

13. Your rights

If we are the controller, you can ask us to:

• confirm whether we hold your data and for a copy of it;
• correct it;
• delete it, or restrict it, in the cases the law allows;
• receive data you provided, in a portable form, where the basis is contract or consent;
• object to processing based on legitimate interests, and object to direct marketing at any time; and
• withdraw consent, where consent is the basis. Withdrawal does not undo processing that has already happened lawfully.

We respond within one month, or we tell you why we need longer. We may need to confirm it is you. If we are only the processor, we will refer you to the operator or act on their instruction.

You can complain to the Information Commissioner’s Office at ico.org.uk. We would like the chance to put things right first.

14. Cookies and similar storage

The marketing site does not use advertising or analytics cookies.

The portal uses a session cookie that is strictly necessary to keep you signed in. The guest flow stores a token in the browser’s local storage so the same phone can resume a session that is still open. That storage is part of providing the check the guest was sent to complete. The guest flow also reads technical device details for the security signals described above. Those details are sent to our servers. They are not an advertising profile.

You can block cookies and local storage in the browser. The portal and an in-progress check will not work without the session storage.

15. Changes

We will post changes on this page and, where the change is material and we have your email as a customer, we will email you before it applies. The date at the top of the page is the date of the current version.

16. Contact

VenueOra Ticketing Limited, 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ.

Data protection: dpo@venueora.com. Product: hello@venuego.co.uk.