Data Processing Addendum

This addendum applies where Captain Expo processes personal data on behalf of an organizer in the course of providing the service. For that data the organizer is the controller and Captain Expo is the processor.

Captain Expo is a controller in its own right for a narrow set of data described in the Privacy Policy - organizer account records, billing, and security logs. This addendum does not govern those.

Where the law of a particular jurisdiction uses different words for these roles - “business” and “service provider”, for instance - the equivalent role applies.

• Subject matter. Providing table mapping, vendor applications, booking, admission ticket sales, door check-in, and payment coordination for the organizer’s events.
• Duration. For as long as the organizer’s account is open, plus the deletion window in clause 9.
• Nature and purpose. Collection, storage, organization, retrieval and transmission of vendor and ticket buyer details so the organizer can sell tables and admission tickets, decide applications, check tickets in at the door, and communicate with vendors and ticket buyers about their events.
• Categories of data subjects. Vendors who apply for or purchase a table at the organizer’s events, any contact the organizer imports, and ticket buyers who buy admission tickets to the organizer’s events. Only the buyer is named on an order. Tickets carry no name, so the people a buyer brings with them are not data subjects here.
• Types of personal data about vendors. Name, email address, phone number, Instagram handle, city, state, selling categories, the tables taken and amounts paid, the date and text of the rules accepted, correspondence sent through the service, and a salted hash of the IP address used to hold a table, kept for rate limiting.
• Types of personal data about ticket buyers. Name, email address, and whether they ticked “Email me about [the organizer]’s next show”. Which tickets they bought and what they paid - the ticket price, our service fee and any processing fee - and whether the order was paid, refunded or never completed. The random code in each ticket’s QR code. When each ticket was checked in, and which member of the organizer’s team or which of the organizer’s labelled check-in links admitted it; a ticket admitted past a warning is also written to the organizer’s activity log, which names the buyer. A salted hash of the IP address used to hold the tickets, kept for rate limiting.
• Special category data. None. The service does not ask for it and organizers should not put it in free-text fields.

We process vendor and ticket buyer personal data only on the organizer’s documented instructions. Using the product is an instruction: creating an event, approving an application, putting tickets on sale, checking a ticket in, issuing a refund, sending an announcement.

We will not use vendor or ticket buyer personal data for our own purposes, and specifically we will not use it to market to vendors or ticket buyers, to build a cross-organizer directory of either, or to train machine learning models. A ticket buyer’s request to hear about the organizer’s next show is recorded for the organizer, and we do not email buyers on the strength of it. If we are required by law to process this data otherwise, we will tell the organizer first unless the law forbids that.

Everyone we permit to access vendor or ticket buyer personal data is bound by confidentiality obligations, and access is limited to those who need it to operate or support the service.

We maintain technical and organizational measures appropriate to the risk, including:

• encryption of all traffic in transit;
• tenant isolation enforced in the data layer - every tenant-owned record carries an organization identifier, and queries are constrained to one organization by a seam the build will not compile without;
• authenticated encryption of any third-party credential an organizer stores, with the key held outside the database;
• no card data in scope - payment details are captured by Stripe and never reach our systems;
• IP addresses hashed with a secret salt before storage, so no raw address is retained;
• booking and ticket order access links, ticket codes and check-in links treated as credentials - never logged and never placed in outbound web addresses;
• a check-in link can check tickets in and download a door list without buyer emails, and nothing else. It can be revoked at any time and stops working 24 hours after the show ends;
• the door scanner reads QR codes on the phone itself, so camera images are never sent to us or stored.

The organizer authorises Captain Expo to engage subprocessors. Each is bound by data protection obligations no less protective than these, and we remain responsible for their performance.

• Stripe (United States) - payment processing for tables and tickets, and connected account onboarding. Handles ticket buyer data: we pass it the buyer’s email address, what they are buying and the amounts, and the buyer gives their card details to Stripe directly.
• Clerk (United States) - organizer authentication and organization membership. Receives no vendor or ticket buyer data.
• Resend (United States) - transactional and announcement email. Handles ticket buyer data: it sends each buyer’s confirmation and any refund or cancellation notice, so it receives their name, email address, ticket codes and the link to their order.
• Vercel (United States) - application hosting, floor plan image storage, the automated-traffic check on checkout and vendor applications, and the page-view count (Vercel Web Analytics). Handles ticket buyer data as our host, because every request passes through it. The page-view count sets no cookie and receives the address of each page viewed with any private link removed, and no vendor or ticket buyer details.
• Neon (United States) - managed Postgres database. Stores all vendor and ticket buyer data.
• Sentry (United States) - error reports. It is set not to collect IP addresses or cookies, and query strings and private links are removed from every report before it is sent. It is not sent vendor or ticket buyer details on purpose, but a report can include a value that was part of the error it describes.
• Anthropic (United States) - automatic floor plan detection. Receives only the venue plan image an organizer submits for a detection run, and no vendor or ticket buyer personal data.

We will give at least 30 days’ notice before adding or replacing a subprocessor that processes vendor or ticket buyer personal data. An organizer who objects on reasonable data protection grounds may terminate the affected part of the service.

The product gives the organizer direct access to the vendor and ticket buyer data it holds, so most requests can be answered without involving us. The console cannot yet correct or delete a ticket buyer’s details, so an organizer who needs that done asks us, and we make the change on their instruction.

If a vendor or a ticket buyer comes to us directly, we will not respond substantively on the organizer’s behalf. We will tell them to contact the organizer and, where we can identify the organization, pass the request on. Where an organizer needs help to respond, we will provide reasonable assistance.

We will notify the organizer without undue delay, and in any case within 72 hours, after becoming aware of a personal data breach affecting their vendor or ticket buyer data. The notice will describe what we know, what we are doing, and what we recommend.

We will also give reasonable assistance with data protection impact assessments and with any consultation of a supervisory authority that follows from one.

The organizer can export their vendor roster, the door list of paid ticket orders, and the ticket buyers who opted in to hear from them, at any time while the account is open.

On termination, we delete vendor and ticket buyer personal data within 90 days, except where retention is required by law. Backups age out on their own schedule and are not restored except to recover from a failure.

We will make available the information reasonably necessary to demonstrate compliance with this addendum, and will contribute to audits carried out by the organizer or an auditor they mandate. Audits are at the organizer’s expense, no more than once in any twelve months absent a security incident, on reasonable notice, and conducted so as not to disrupt the service or expose another organizer’s data.

The service and all of the subprocessors in clause 6 operate in the United States, and vendor and ticket buyer personal data is processed there.

Captain Expo is built for United States markets. An organizer selling to vendors or ticket buyers in a jurisdiction with a consent-in regime - the EU, the UK, or Canada, for example - is responsible for satisfying the requirements that apply to them, including the transfer mechanism and any consent their vendors or buyers must give before being contacted. Tell us if you need standard contractual clauses and we will discuss it.

This addendum forms part of the Terms of Service and lasts as long as we process vendor or ticket buyer personal data for the organizer. Where it conflicts with the Terms of Service on the processing of personal data, this addendum governs.

Questions, or a request for standard contractual clauses, go to legal@captainexpo.com.