Where your data lives, and who can reach it
Written for the people who have to sign off on a platform before anyone uses it. Everything below is what the product does today — not a roadmap, and not a list of aspirations.
Where attendee data goes, and on what legal basis
EEA · UK · anywhere
The organizer decides which fields the form asks for, and can add a consent box and their own privacy notice.
GCP · asia-southeast1
Organizer accounts, event records, and attendee registrations are all held in Singapore.
per request
Deletion is built in rather than bolted on, and the organizer stays the controller throughout.
Singapore has no EU adequacy decision, so transfers from the EEA and the UK run on the European Commission's Standard Contractual Clauses. A Data Processing Agreement is available on request, and sub-processors are listed in full on the sub-processors page.
Where your data lives
One region, one hosting provider, and a published list of everyone else who touches the data.
- Hosting
- Google Cloud Platform, Singapore (asia-southeast1). Organizer accounts, event records, and attendee registrations are all held there.
- EEA and UK transfers
- Singapore has no EU adequacy decision, so those transfers run on the European Commission's Standard Contractual Clauses.
- Singapore law
- The PDPA applies to our own processing, including the standard we require of any onward transfer.
- GDPR and PDPA
- For attendees in the EEA and the UK, GDPR applies and the organizer is the controller; bagevent processes on their instructions. Registration forms can carry a consent box and the organizer's privacy notice, organizers can export or erase an attendee's data from the attendee record, a Data Processing Agreement is available on request, and transfers run on Standard Contractual Clauses. Singapore's PDPA applies to our own processing. bagevent holds no GDPR certification.
- Sub-processors
- Published in full on the sub-processors page — hosting, network, email, SMS, payments, AI features, support chat, push notifications, the maps and videos embedded on event sites, and analytics on this marketing site.
- Cookies on this website
- None until you choose. Analytics and the chat widget, which set cookies, are asked for once, default to off, and are never loaded if you decline; the page-view counter that runs either way sets nothing. Your choice can be changed from any page.
- In transit
- bagevent.io, account.bagevent.io, and app.bagevent.io are served over HTTPS, with HSTS, behind Cloudflare, which terminates TLS and is listed as a sub-processor.
Money never routes through us
The 0% platform fee is a consequence of the architecture: your ticket revenue is never in our custody to take a cut from.
- Ticket revenue
- Collected into your own Stripe account. It does not pass through a bagevent account on the way to you.
- Card details
- Handled by the payment provider. bagevent does not store card numbers, for ticket sales or for your own subscription.
- Several legal entities
- Each organization connects one Stripe account. If several legal entities sell tickets, each runs as its own bagevent organization with its own Stripe account.
What runs on the devices at your event
An offline check-in pack is your attendee list on a machine that leaves the office. These are the controls around that, rather than a claim that it is not true.
- What is in a ticket QR
- An opaque token and nothing else. Scanning a ticket with any other app reveals nothing about the attendee.
- The attendee list on a phone
- Held in an encrypted database. Sign-in credentials go to the operating system's secure storage — Keychain on iOS, Keystore on Android. Signing out or leaving the event removes both.
- The camera
- Used for scanning QR codes only. Frames are processed on the device and are never uploaded or retained.
- Third-party code in the app
- Two components, both from Google: Firebase, for push notifications, and Sign in with Google, used only if you choose it. No analytics SDK, no crash-reporting SDK, no advertising or attribution SDK, and no advertising identifier.
- An offline pack on a laptop
- Carries a lease — seven days by default — after which the machine has to reach the backend again, which re-checks the account in the same step. Winding the system clock back does not extend it.
- Signing in to a desk with no network
- The password is never stored on the machine, only a verifier, sealed by DPAPI on Windows and the Keychain on macOS. Five wrong attempts locks it for five minutes.
- Check-ins that have not uploaded
- Never discarded. Anything that fails to upload stays in the queue with the reason attached, and a duplicate created while two devices were offline is raised for a person to adjudicate rather than resolved silently.
Who can act in your account
Scanning staff, team members, and the assistant all operate inside permissions you set.
- Staff at the door
- Join a device with a short code you approve from your own account. They never get a login of their own, and one device can be revoked without touching the others.
- Your team
- Team members act within their own permissions. What a check-in point is allowed to do is set on the server, so a device is only ever offered the actions that point permits.
- The AI assistant
- Proposes; you confirm. Every change runs under your own account and permissions, so it can never do something your role could not do by hand.
- Signing in
- Email and password, a one-time code sent by email, or a Google account. Changing the password signs out every other device. SSO and SAML are not available yet.
- Two-step verification
- Optional, and turned on by each person for their own account: a code from an authenticator app (TOTP) is asked for after the first step when signing in on the web, with one-time recovery codes in case the phone is lost. There are no SMS codes and no passkeys, an organization cannot yet require it of every member, and the mobile app does not support the second step yet.
How long things are kept, and what deletion does
The same retention notice goes out with every personal data export.
- When a trial or subscription ends
- Nothing is deleted. Events and registrations are kept and stay exportable; editing and paid ticket sales pause until a plan is chosen.
- Closing an account
- A 30-day grace period, during which the account keeps working and the closure can be reversed. After it passes, the account holder's personal data is anonymised and cannot be recovered. One person closing their account does not delete the organization's events or attendee records.
- Attendee data
- Kept until an erasure request is actioned or the organizer asks for it to be deleted; there is no fixed expiry. Organizers can action a deletion request directly from the attendee record.
- What outlives an erasure request
- Invoices and payment records, for the period tax law requires — typically 7 to 10 years. And security logs, kept as an append-only record.
- Telling you about an incident
- If a security incident affects personal data we process for you, we notify you without undue delay after becoming aware of it — with what is known at the time, rather than waiting for a complete picture. The DPA sets out the mechanics.
- Uptime
- We do not offer an uptime SLA, and there is no public status page yet.
Questions security reviews ask
On Google Cloud Platform in Singapore (asia-southeast1). Organizer accounts, event records, and attendee registrations are all held in that one region. Singapore has no EU adequacy decision, so transfers from the EEA and the UK run on the European Commission's Standard Contractual Clauses.
The organizer is the controller and bagevent is the processor, working on the organizer's instructions. Registration forms can carry a consent box, organizers can export or erase an attendee's data, a Data Processing Agreement is available on request, and sub-processors are published in full. For attendees in the EEA and the UK, transfers to Singapore run on the European Commission's Standard Contractual Clauses. bagevent holds no certification and claims none.
No. Card details are handled by the payment provider, and bagevent does not store card numbers — for ticket sales or for your own subscription. Ticket revenue is collected into your own Stripe account and does not pass through a bagevent account on the way.
None. The QR code holds an opaque token and nothing else, so scanning a ticket with any other app reveals nothing about the attendee.
On a phone, the attendee list is held in an encrypted database and sign-in credentials sit in the operating system's secure storage. Each door device joins with a code you approve and can be revoked on its own. An offline pack on a laptop carries a lease, seven days by default, after which it must reach the backend again.
Yes, on request. Email us and we will send the DPA for your organization to review. Sub-processors are published in full on the sub-processors page.
Not today. People sign in with email and password, an emailed one-time code, or Google, and each person can add two-step verification with an authenticator app; SSO and SAML are not available yet. There is no uptime SLA and no public status page.
Yes, as an option each person turns on for their own account. Signing in on the web then asks for a code from an authenticator app (TOTP) after the password, emailed code, or Google step, and one-time recovery codes cover a lost phone. There are no SMS codes and no passkeys, an organization cannot yet require it of every member, and the mobile app does not support the second step yet.
Closing a person's account starts a 30-day grace period, during which the account keeps working and the closure can be reversed. After that, bagevent anonymises that person's personal data and it cannot be recovered. The organization's events and attendee records are not deleted by this; they are deleted when the organization asks. Ending a subscription deletes nothing. Invoices and payment records are kept for the period tax law requires, typically 7 to 10 years.
Documents, and how to reach us
Data Processing Agreement
Available on request for business customers. What it covers and how to ask for it.
About the DPASub-processors and data flows
The current list, what each one does, and where the data goes.
See the sub-processorsReporting a vulnerability
Email us with the details and we will come back to you. Please do not disclose it publicly first.
milo@bagevent.ioFilling in a security questionnaire? Send it over — it is quicker than guessing from this page, and anything it turns up that belongs here gets added.
Field guides
- What does GDPR actually require of an event organiser?You are the controller; the platform is the processor. DPA clauses, dietary fields as special-category data, deadlines.
- What should you look for in event registration software?A demo shows the happy path. Check cost, billable regs, self-serve control, event-day support, the door, and exit.
Questions your security team needs answered?
Send them to us before you commit to anything — we would rather answer them now than at renewal.