Privacy Policy

Setout is operated by [SETOUT LEGAL ENTITY NAME] (“Setout”, “we”, “us”, “our”), a company registered in [JURISDICTION OF INCORPORATION] under company number [COMPANY NUMBER], whose registered office is at [REGISTERED OFFICE ADDRESS].

• General enquiries: [GENERAL CONTACT EMAIL]
• Privacy and data-protection enquiries, and data-subject requests: [PRIVACY CONTACT EMAIL]
• Data protection officer: [DPO NAME AND CONTACT, OR “we have not appointed a DPO because we are not required to under Art. 37”; LEGAL TO CONFIRM WHICH]
• UK ICO registration number: [ICO REGISTRATION NUMBER, IF UK-ESTABLISHED]
• Art. 27 representative: [EU REPRESENTATIVE IF UK-ESTABLISHED AND OFFERING SERVICES INTO THE EEA / UK REPRESENTATIVE IF EU-ESTABLISHED AND OFFERING SERVICES INTO THE UK; LEGAL TO DETERMINE WHETHER ONE IS REQUIRED]

If you want to exercise a data-protection right, section 11 explains how. If you booked something through an operator using Setout, it also explains who to ask.

Data-protection law distinguishes the controller (who decides why and how personal data is used) from the processor (who acts on the controller's instructions). Setout is one or the other depending on whose data it is.

This section covers our own website and our relationship with operators. It does not cover booking data; that is section 4.

When an operator uses Setout to take bookings, they decide what to collect and why. We process it on their documented instructions, as their processor. Depending on how that operator has configured their account, this can include:

• Customer identity and contact details: name, email address, telephone number.
• Booking records: what was booked, when, for how many people, at what price, and its history including changes, cancellations and refunds.
• Participant details: where the operator collects them, the details of the people taking part. The platform stores these as a free-form set of attributes the operator defines, so what goes in them is the operator's choice: commonly a height, a weight, a frame or clothing size, or an experience level, where that is needed to allocate equipment safely.
• Waivers and consents: the fact and time of a waiver signature or acceptance of the operator's booking terms, the version accepted, and, for an acceptance made by the customer online, the source IP address recorded as evidence of it.
• Payment records: amounts, currency, status and the payment references needed to reconcile and refund. Not card numbers, which go directly to Stripe.
• Credit, gift-card and account balances held with that operator, as an append-only ledger.
• Messages we send on the operator's behalf (booking confirmations, reminders, balance requests and sign-in links), and the delivery outcome.
• Email preferences: the recipient's email address, the category of message it applies to, and whether they have opted out, so that an opt-out is honoured on every later send.

These are the bases we rely on as controller. For booking data we are the processor, and the lawful basis is the operator's to establish, not ours.

Where we rely on legitimate interests we have to balance them against your rights. [LEGAL TO PREPARE a Legitimate Interests Assessment for each row above that relies on it, and to record the outcome. None has been carried out.] You can object to processing based on legitimate interests. See section 11.

Setout uses first-party cookies only, and only ones that are strictly necessary to operate the service. As built today, that is: the cookies our sign-in provider sets to keep an operator signed in to the console, and the signed session cookie that lets a customer return to their booking from a link we emailed them.

We protect form submissions against cross-site request forgery by checking, from headers the browser sends, that the request came from our own pages. That check sets nothing and stores nothing on your device.

We do not use advertising cookies, third-party analytics trackers, social-media pixels or cross-site tracking of any kind. There is no such tracker in the product at the time of writing, which is why this policy offers no cookie banner and no consent toggles: under both PECR and the ePrivacy rules, strictly necessary cookies do not require consent.

We do not sell personal data, and we do not share it for anyone else's marketing. We use the following service providers, each under a written contract and only for the purpose stated:

We may also disclose personal data to professional advisers, to a buyer or successor if the business is sold or reorganised, and to law enforcement, regulators or courts where we are legally required to. In that case we will tell the affected controller unless we are prohibited from doing so.

Systems an operator connects to their own account. An operator can switch on integrations that send their booking data onward. There are two, and we cannot list the destinations here, because each operator sets their own and they differ from account to account. They are that operator's recipients, chosen and controlled by them, and not service providers of ours. Where your data travels next is accounted for by the operator's privacy notice, not this one.

The platform's database and application compute run in the EU: the AWS Europe (Ireland) eu-west-1 region. That is a deliberate design commitment, not a default, and primary storage stays there.

Some providers above necessarily operate globally: a card payment crosses the card networks, and support or monitoring may be reachable from outside the UK and EEA. Where personal data is transferred outside the UK or EEA, we rely on an adequacy decision where one covers the destination, and otherwise on Standard Contractual Clauses (with the UK Addendum or the UK International Data Transfer Agreement for UK transfers), together with any additional safeguards the transfer risk assessment identifies.

[LEGAL TO VERIFY, per provider: the transfer mechanism actually in place, the current adequacy position for each destination, and whether transfer risk assessments have been completed. This has not been done.]

We keep personal data for as long as we need it for the purpose it was collected for, and then delete it. Some of that is automated: the platform runs a scheduled retention job whose current defaults are:

• Abandoned checkouts (a booking started and never completed): the reservation is released within minutes, and a stuck one is released after 30 days at the latest. The order itself is marked expired and kept as a record of the attempt, not deleted, so it falls under the schedule the note below calls for rather than under this list.
• Waitlist entries, and the email address on them: deleted 180 days after the entry was created, once it is no longer live because the person either took a place or the entry lapsed. An entry still waiting is not deleted by this job however old it is.
• Sign-in and confirmation tokens: deleted after 7 days, having already expired fifteen minutes after they were issued.

Beyond those, the periods that matter most are: booking and payment records, kept while the operator's account is open and afterwards for as long as tax, accounting and limitation periods require; audit log entries, kept for the life of the account because their purpose is to remain a complete record; and prospect and enquiry records, kept while the conversation is live and for a reasonable period afterwards.

When an operator closes their account, we delete or return their booking data on the terms set out in our agreement with them.

Security measures we can describe without weakening them:

• Each operator's data is isolated from every other operator's, enforced in the database itself by row-level security rather than only in application code, and tested continuously, including by tests written specifically to try to break the isolation.
• Card details never reach our servers. Payments are taken on Stripe-hosted pages; the platform never renders a card field.
• Data in transit is encrypted (TLS), and data at rest is encrypted by the managed database and storage services.
• Access to production is restricted, and the application connects to the database as a limited-privilege role that the isolation rules apply to, never as an administrative one.
• Secrets are never committed to source control, and the platform is built not to write secrets or full personal details into its logs.
• Security- and payment-significant actions are recorded in an append-only audit log.

No system is perfectly secure. If a personal data breach occurs, we will notify the relevant supervisory authority and affected controllers as required. For booking data that means telling the operator, promptly, so they can meet their own obligations. [LEGAL/OPS TO CONFIRM the documented incident response and breach notification procedure, and the notification timescale committed to in the DPA.]

Under the UK GDPR and the EU GDPR you have the right to access your personal data, to have it corrected, to have it erased, to restrict or object to its processing, to data portability, and, where we rely on consent, to withdraw that consent at any time without affecting processing already carried out.

We will respond within one month, extendable by a further two months for complex requests, and we will tell you if we need the extension. We do not charge a fee unless a request is manifestly unfounded or excessive.

An access request tells you who received your data, by name. Section 7 sets out the categories up front, but a category is not the answer to a request. When an operator answers one, the export the platform produces for them lists the recipients your data actually reached: the payment processor if a card payment was taken, the email provider if messages were sent to you, and, for the two integrations an operator can switch on, the host of the webhook endpoint their events went to and the calendar provider their bookings were written into. We name the host rather than the full address, and never the credentials used to sign the request.

Some rights have limits, and we would rather state them than surprise you with them. Erasure is not absolute: where a record must be kept to establish, exercise or defend a legal claim, or to meet a legal obligation (a completed transaction, an accounting record, an audit-log entry recording a payment action), we may retain it and will explain why. In that case we will still restrict its use to that purpose.

What erasure does to those records. It does not delete them. It strips the personal data out of them where they stand, so the booking, the payment and the ledger entry survive as accounting facts that no longer identify anybody: the name, the telephone number, the participant details and the profile are cleared, and the email address is replaced with an unusable one. Doing it a second time changes nothing, which is deliberate.

What erasure cannot reach. If an operator has connected their own systems to their account, a copy of the data may already have been sent there. We can erase what is on the platform. We cannot recall what has left it, and that copy is the operator's to account for under their own privacy notice. See section 7.

Complaints. If you think we have handled your data badly, please tell us first. You also have the right to complain to a supervisory authority: in the UK, the Information Commissioner's Office (ico.org.uk); in the EU, the authority in the country where you live, work, or where the issue arose.

We do not make decisions producing legal or similarly significant effects about you by automated means alone, and we do not profile you for that purpose. The platform automates booking mechanics (whether a bike is free at 9am, whether a session has a seat left), which are decisions about inventory, not about people.

Stripe carries out automated fraud screening on payments as part of providing payment services. [LEGAL TO CONFIRM how Stripe's fraud tooling should be described here, and whether any operator-configurable feature amounts to Art. 22 automated decision-making.]

Setout is a business tool, sold to and used by adults. We do not knowingly collect personal data from children through our own website or accounts.

We will update this policy when what we do changes. The version and effective date are at the top. For a change that materially affects how we use personal data we will give notice in advance (to operators, by email to the account's administrators), rather than relying on you to notice a new date.