For Organiser Data (the guest lists, check-in records and door-staff roster described in Annex I), the Organiser is the Controller and the Provider is the Processor. The Organiser determines the purposes and means of processing that data; the Provider processes it only on the Organiser's behalf under this DPA.

The Provider acts as an independent controller only in respect of the Organiser's own account data — the Organiser's login email and hashed password. That processing is not governed by this DPA; it is governed by the Provider's Privacy Policy. (If and when paid subscriptions are activated, the Provider will also process the Organiser's billing data as an independent controller through Stripe — see Section 6 and Section 11. Billing is not currently live, and no billing data is processed until it is.)

The Provider does not sell data, does not use tracking cookies or advertising, and never emails the Organiser's guests. Guests are never contacted by the Provider.

The Art. 28(3) particulars are set out in full in Annex I and summarised here.

Subject-matter. The Provider's processing of Organiser Data on the Organiser's documented instructions so that the Organiser can run event check-in using the Service.

Nature of the processing. Storage, hosting, structuring, retrieval, transmission to the Organiser's authorised devices, on-screen display for door check-in, recording of check-in scans, and erasure — all as performed by the Service's functionality.

Purpose. To enable the Organiser to upload its guest list, invite door staff, validate tickets/pass codes at the door, record check-ins, and manage that data through the dashboard. The Provider processes Organiser Data for no other purpose.

Duration. For as long as the Organiser uses the Service and retains Organiser Data in it. Guest data remains until the Organiser deletes it (see Section 9). This DPA continues in force for as long as the Provider processes Organiser Data on the Organiser's behalf.

Because check-in records can carry an operator name, they are not fully anonymous; they are pseudonymous audit records.

The Provider processes Organiser Data only on the Organiser's documented instructions, including as to international transfers, unless required to do otherwise by EU or Member State law — in which case the Provider will inform the Organiser of that legal requirement before processing, unless the law prohibits it on important grounds of public interest.

The Organiser's documented instructions are: (i) this DPA; (ii) the built-in functionality of the Service as used by the Organiser; and (iii) the Organiser's own configuration and use of the Service (for example, the guest data it chooses to upload, the events it creates, the door staff it invites, and the export/delete/erase actions it takes). By operating the Service in the ordinary way, the Organiser instructs the Provider to process Organiser Data as the Service performs it.

The Provider will inform the Organiser if, in its opinion, an instruction infringes the GDPR or other EU/Member State data protection law. The Provider is a solo operator and does not customise processing outside the documented functionality of the Service.

The Provider ensures that persons authorised to process Organiser Data are bound by an appropriate obligation of confidentiality, whether contractual or statutory.

The Service is operated by a single operator, who is personally bound by a duty of confidentiality with respect to Organiser Data. Access to Organiser Data is limited to what is necessary to operate, secure, and support the Service. The Organiser separately controls which of its own door staff it invites; invited door staff cannot read guest email addresses (see Section 5).

Taking into account the state of the art, the nature of the data, and the risks to data subjects, the Provider maintains the following technical and organisational measures:

• Encryption in transit (TLS). All connections between devices and the Service are encrypted using TLS.
• Encryption at rest. Organiser Data stored in the database is encrypted at rest by the hosting infrastructure (Supabase).
• Row Level Security (RLS) scoped per organiser. Database Row Level Security confines each organiser's data to that organiser's account, so one organiser cannot read another's data.
• Database-level redaction of guest email from door staff. Invited door staff have no access to the base guest table; they are served a redacted, row-gated database view in which each guest's email address is removed (returned as null) for anyone who is not the event owner. Guest name, ticket type and pass code remain visible to door staff because they are needed to validate entry at the door; only the email address is redacted. The redaction is enforced at the database level, not merely hidden in the interface.
• Hashed passwords. Organiser account passwords are stored only as salted hashes, never in plain text.
• Least-privilege access. Access rights follow the principle of least privilege: clients cannot grant themselves entitlements; privileged operations run through a controlled service-role path; door staff can insert check-ins and walk-up guests but cannot delete guests, erase data, edit the event, or manage the roster.
• Encrypted automated backups. The hosting infrastructure keeps encrypted automated backups (point-in-time / daily snapshots) for disaster recovery for a rolling retention window of up to 7 days, after which they are overwritten. Backups are not restored to live use except to recover from a failure or data-loss incident (see Section 9 on how this affects deletion).

These measures reflect the Service as built. The Provider does not offer, and this DPA does not create, any uptime, availability, insurance, or certification guarantee, and the Provider does not hold any security certification. The Organiser is responsible for keeping its own account credentials secure and for managing whom it invites as door staff.

The Organiser gives its general written authorisation for the Provider to engage the sub-processors listed in Annex II (which is dated and reproduced below), which are integral to delivering the Service. As at 8 July 2026 these are:

• Supabase — database hosting and authentication. Organiser Data (guest lists, check-in records and the door-staff roster) is hosted in the EU (Ireland, eu-west-1). Supabase is the only sub-processor that processes guest and door-staff personal data.
• Vercel — hosting and serving of the application. Guest and door-staff data is fetched client-side directly from Supabase (EU) and is not routed through Vercel's compute; the only Vercel serverless functions are the (currently inactive) billing endpoints, which handle account and billing data, not Organiser Data.
• Resend — sending of the Organiser's account emails only (confirmations, password resets). Resend never receives Organiser Data and never emails guests.

No error-tracking sub-processor is currently engaged. The application can send diagnostic error reports to Sentry (a US-based service), but only if an error-tracking key is configured; in the production deployment this key is not set, so the Sentry code is never loaded and no error data leaves the browser. If the Provider ever enables error tracking, Sentry will be added as a sub-processor by the change procedure below, disclosed as US-based in Section 11, and configured not to attach personal data by default.

Stripe is not currently a sub-processor. Paid subscriptions are not live. If and when the Provider activates paid billing, Stripe will be engaged to process the Organiser's billing data (for which the Provider is an independent controller under Section 1); Stripe would not process Organiser Data. At that point Stripe will be added by the change procedure below and disclosed in the Privacy Policy so that both documents match.

Changes and right to object. Before adding or replacing a sub-processor that will process Organiser Data, the Provider will give the Organiser at least 30 days' advance notice by email to the Organiser's account address and/or by updating Annex II, so the Organiser has a reasonable opportunity to object. Where a change is urgently required for security or service continuity, the Provider may give shorter notice with reasons. If the Organiser reasonably objects on data protection grounds, the parties will discuss in good faith; if no resolution is reached, the Organiser may stop using the affected part of the Service and, where the change is material, terminate its use of the Service and export and delete its Organiser Data (Section 9) as its remedy.

Flow-down. Where a sub-processor processes Organiser Data, the Provider imposes on it, by contract, data protection obligations that are equivalent to those in this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures under Article 28. The Provider remains fully liable to the Organiser for the performance of that sub-processor's obligations.

Taking into account the nature of the processing, the Provider assists the Organiser, by appropriate technical and organisational measures and insofar as possible, to fulfil the Organiser's obligation to respond to requests from data subjects exercising their rights under Chapter III of the GDPR (access, rectification, erasure, restriction, portability, and objection).

The Service gives the Organiser self-service tools to act on such requests immediately, without needing to ask the Provider:

• Export attendance (CSV) — to satisfy access and portability requests.
• Remove an individual guest — to satisfy an erasure or objection request for one guest.
• Erase all guest data for an event — to erase a whole event's guest list.

Because the Organiser controls its guest list and holds these tools, the Organiser is ordinarily able to respond to data subjects directly. As reflected in the Privacy Policy, guests are directed to contact their event's organiser to exercise their rights. If a data subject contacts the Provider directly, the Provider will, without undue delay, refer the request to the relevant Organiser rather than act on the data itself.

Deletion performed through these tools removes the guest and their check-in records from the live database immediately and permanently, and this is the operative erasure. Any residual copy of a deleted row that remains in the encrypted rolling backups is purged automatically within the backup-retention window stated in Section 5 and is not restored to live use in the interim except to recover from a failure.

Taking into account the nature of the processing and the information available to the Provider, the Provider assists the Organiser in ensuring compliance with the obligations in Articles 32 to 36 of the GDPR:

• Security (Art. 32). By maintaining the measures in Section 5 and making relevant information available to the Organiser.
• Personal data breach (Arts. 33–34). The Provider notifies the Organiser without undue delay after becoming aware of a personal data breach affecting Organiser Data, and provides the information reasonably available to it to help the Organiser meet its own notification duties to the supervisory authority and, where required, to affected data subjects. As Controller, the Organiser is responsible for any notifications to the supervisory authority and to data subjects.
• DPIAs and prior consultation (Arts. 35–36). The Provider provides reasonable assistance, proportionate to a solo operator, by making available the information about the Service and its processing needed for the Organiser to carry out a data protection impact assessment or a prior consultation.

At the Organiser's choice, on the Organiser ceasing to use the Service or at any time on the Organiser's instruction, the Provider deletes or returns Organiser Data, and deletes existing copies, unless EU or Member State law requires storage.

Self-service. Throughout, the Organiser retains control: it can export its attendance data (CSV) at any time and then erase individual guests or all guest data for an event directly from the dashboard. Deletion through these tools is immediate and permanent for the live database (see Section 7).

Provider-side backstop. If the Organiser cannot self-serve (for example, after it has closed its account or lost access), the Organiser may instruct the Provider by email at support@eventpassreader.com to export and/or delete its Organiser Data on its behalf. On such an instruction, or on the Organiser closing its account, the Provider will, within 30 days: (i) if requested, provide a final CSV export of the Organiser Data before deletion (this is the means by which the Provider effects return of the data); and (ii) delete the Organiser Data from the live systems. The Provider will confirm the deletion in writing on request.

Backups. Any residual copies of deleted Organiser Data in the encrypted rolling backups are purged within the backup-retention window stated in Section 5 and are not restored to live use in the interim except to recover from a failure.

Offline caches. Scanner devices keep a local copy of the guest list so check-in works without a connection. That local copy is erased when the organiser signs out of the device. The Organiser should sign out on any device it no longer controls to clear that cache.

The Provider makes available to the Organiser the information necessary to demonstrate compliance with the obligations in Article 28 and this DPA, and allows for and contributes to audits, including inspections, conducted by the Organiser or an auditor it mandates.

Given that the Provider is a solo operator of a small service, audits and information requests will be handled in a reasonable and proportionate manner: primarily by the Provider responding in writing to reasonable questions and providing available documentation about its security measures and sub-processors. On-site inspections, where genuinely necessary, will be limited to what is proportionate, arranged on reasonable advance notice, conducted no more than once per year absent a specific concern or a supervisory authority requirement, and must not compromise the security or confidentiality of other customers' data. The Provider will promptly inform the Organiser if, in its opinion, an instruction or audit request infringes the GDPR or other applicable data protection law.

Organiser Data (guest lists, check-in records and the door-staff roster) is hosted in the EU (Supabase, Ireland, eu-west-1), and guest and door-staff data is fetched client-side directly from Supabase rather than routed through non-EU compute. The Service is designed to keep Organiser Data within the EEA.

Some of the Provider's sub-processors are US-based or have US-based operations. Vercel serves the application and may route request traffic through US infrastructure, but Organiser Data is fetched directly from Supabase (EU) and does not traverse Vercel's serverless compute. Resend (which processes only the Organiser's account emails, not Organiser Data) is US-based. If Stripe is engaged when billing goes live, it would process only the Organiser's billing data (not Organiser Data), and it is US-based. If error tracking (Sentry, US-based) is ever enabled, it would be covered here at that time.

To the extent any processing involves a transfer of personal data outside the EEA, that transfer relies on the relevant provider's own transfer safeguards — in particular the Standard Contractual Clauses (SCCs) and/or GDPR-compliant data processing terms offered by that provider. The Provider does not itself export Organiser Data outside the EEA beyond what the Service's EU-hosted architecture entails. The Organiser instructs and authorises any such transfers as part of its documented instructions (Section 3) and its authorisation of sub-processors (Section 6).

Liability (self-contained). Because this DPA does not attach to a separate terms-of-service document, the following applies. Each party is liable to the other for its own breach of this DPA in accordance with the applicable law. To the maximum extent permitted by law, the Provider's aggregate liability arising out of or in connection with this DPA is limited to the greater of (a) the total fees paid by the Organiser for the Service in the twelve months before the event giving rise to the claim, or (b) EUR 100 where the Service has been provided free of charge; and neither party is liable for indirect or consequential loss or loss of profit. Nothing in this DPA limits or excludes either party's liability where it cannot lawfully be limited or excluded — including liability under Article 82 GDPR, liability for a party's own fraud, or liability that cannot be excluded under Spanish law. This DPA does not reduce data subjects' mandatory rights under the GDPR or any mandatory consumer-protection rights they may have.

Governing law. This DPA is governed by the laws of Spain, without prejudice to the GDPR and any mandatory rights of data subjects.

Effect. This DPA takes effect on the Organiser's first creation of an account for, or first use of, the Service, and remains in force for as long as the Provider processes Organiser Data on the Organiser's behalf. The English version is the binding version.

*Last updated: 8 July 2026.*

Controller: the Organiser (the event organiser using the Service).

Processor: the Provider (operator of Event Pass Reader, support@eventpassreader.com).

Subject-matter: processing of Organiser Data so the Organiser can run event check-in using the Service.

Duration: for as long as the Organiser uses the Service and retains Organiser Data in it; and thereafter until deletion/return under Section 9.

Nature and purpose: storage, hosting, structuring, retrieval, transmission to authorised devices, on-screen display for door check-in, recording of check-in scans, and erasure — to enable the Organiser to upload guest lists, invite door staff, validate tickets/pass codes at the door, record check-ins, and manage that data through the dashboard.

Categories of data subjects: the Organiser's guests; and the Organiser's invited door staff.

Special categories of data: none is required or intended by the Service.

*Last updated: 8 July 2026. Changes are notified under Section 6.*

| Sub-processor | Purpose | Data processed | Location of Organiser Data | | --- | --- | --- | --- | | Supabase | Database hosting + authentication | Guest lists, check-in records, door-staff roster, and account data (email + hashed password) | EU — Ireland (eu-west-1) | | Vercel | Hosting / serving the application | No Organiser Data routed through its compute (guest data fetched client-side from Supabase); serves the app | US-based provider; Organiser Data stays in EU (Supabase) | | Resend | Sending the Organiser's account emails (confirmations, password resets) | Organiser account email only — never guest or door-staff data | US-based provider |