GDPR

Summary#

If you use LaunchList to collect an audience in the EU or the UK, you are the data controller and we are your processor. That means the obligations are shared, and this page is about which are ours and which are yours.

What is actually built and running:

• Erasure that destroys personal data in place, distinct from merely removing a signup.
• A CSV export of your audience, so the data is portable and yours to take.
• A retention clock, off by default, that erases rather than hides.
• A consent banner on your hosted page that genuinely withholds tags rather than only hiding them.
• Double opt-in, on by default for the forms that build an audience (waitlist and marketing; a survey does not ask, because the respondent is answering a question rather than joining a list). Confirmation requires a deliberate click that a mail scanner cannot make on someone's behalf, so consent is evidenced rather than assumed. A contact who was never asked is recorded as never having proved anything, rather than as verified.
• The security measures in §7, each of which is a thing in the code rather than an intention.

What does not exist yet, stated plainly because you need to know before you buy:

• A published Data Processing Agreement. Ours is a draft, unreviewed by counsel (§5).
• A sub-processor list at a permanent, versioned URL with change notification (§5).
• EU-only data residency (§6).
• A per-person subject-access package. You assemble one from the contact record and the export today (§3).
• Any certification or external audit (no SOC 2, no ISO 27001, no penetration-test report), and no Article 27 representative in the EU or the UK.

We would rather list those than let you assume otherwise and find out at renewal.

1. Who is the controller#

This is the distinction the whole regulation turns on, and it is different for the two kinds of data LaunchList holds.

For your own account data we decide the purposes, so we answer to you directly and the Privacy Policy describes it.

For your audience, you decide what to collect and why, and we only act on your instructions. You are the one who has to have a lawful basis, publish a privacy notice, and answer a data subject who writes in. We give you the tools to do it.

2. Your lawful basis#

We cannot choose this for you, and any tool that claims to is selling you a false sense of safety. The usual bases for a waitlist are consent (the person asked to hear from you) or legitimate interests (they asked about your product and expect a reply).

Two practical things the product does about it:

• Double opt-in is on by default. A signup has to confirm their address before they count as verified, which is the strongest evidence of consent a waitlist can produce. You can turn it off per form; we do not recommend it if your audience is in the EU or the UK.
• A consent checkbox field exists. You can add an explicit consent checkbox to any form, and the answer is stored with the signup rather than assumed.

3. Data subject rights#

Someone in your audience has the right to access, correct, erase, restrict, object and port their data. The request is yours to answer, because you are their controller. The product does the work:

• Access and portability. The contact's record shows everything held about them, and the audience export is a plain CSV you can filter down to that person. There is no one-click subject-access package yet, so assembling the response is still a couple of manual steps.
• Erasure. Erasure is deliberately distinct from removal. Removing a contact takes them off your list; erasing them destroys their personal data while keeping the referral graph intact, so the people they referred do not silently lose their positions. That distinction is why we built two operations rather than one. The one thing kept is the email address on your project's do-not-email list, so that a later import cannot email that person again.
• Rectification. Contact fields are editable.
• Objection to marketing. Every marketing email carries a working unsubscribe, including one-click support in mail clients that offer it, and a suppressed address stays suppressed.

If a request reaches us instead of you, we will pass it on rather than act on it, because acting on it would mean overriding the controller.

4. Storage limitation#

The default is to keep your audience until you say otherwise. We do not apply a retention limit to a customer's list on our own initiative, on any plan, because deleting it is not our decision to make.

Each workspace can set a retention clock (180 days, or 1, 2 or 3 years) that applies to every project in it, measured from each signup's own creation date. It is off by default. When it runs it erases rather than hides, because the point of storage limitation is not holding the data any more.

5. The Data Processing Agreement#

A DPA is what Article 28 requires between a controller and a processor. Ours covers the subject matter and duration of processing, the categories of data and data subjects, our obligations of confidentiality and security, our use of sub-processors, our assistance with data subject requests and breach notification, and what happens to your data when you leave.

The same is true of the sub-processors list: the working version is reproduced in §4 of the Privacy Policy, last checked against the product on October 11, 2026, but it does not yet live at a permanent versioned URL with a change-notification commitment.

6. International transfers#

Our infrastructure and our sub-processors operate in more than one country, and our main database and application run in the United States, so personal data is processed outside the EEA and the UK. Where that happens we rely on the transfer terms our sub-processors publish, which for the major ones incorporate the standard contractual clauses. To be exact about what that is and is not: we have accepted our vendors' standard terms, not negotiated bespoke transfer agreements, and we have not carried out or published a transfer impact assessment.

7. Security#

The measures behind the Article 32 obligation, concretely:

• Passwords are hashed, and signup IP addresses are hashed rather than stored.
• Traffic is served over TLS, with HSTS and a Content Security Policy.
• API keys are stored hashed, scoped to what they may do, and revocable.
• Team access is by role, and every write is authorized on the server against that role.
• Public endpoints carry rate limits and layered anti-abuse checks.
• Tenant scoping is automatic rather than remembered, and an isolation test guards it.

Each of those is a thing in the code, not a policy we intend to write. What is missing is the paperwork around them: no external penetration test, no security certification, and no independently audited controls. Our own review is internal, and we are not going to describe that as more than it is.

8. Breach notification#

If we become aware of a personal data breach affecting data we process for you, we will notify you without undue delay and give you what you need to make your own notification within your 72-hour window: what happened, which categories of data and roughly how many people are affected, the likely consequences, and what we have done about it.

Where we are the controller (your own account data), we notify the relevant supervisory authority ourselves as the law requires.

9. Cookies and consent#

Our own cookies and browser storage are listed in §3 of the Privacy Policy. We run no advertising cookies. We do use PostHog and Google Analytics for our own analytics, in the app and on our marketing site. Neither loads on your hosted page.

On your hosted page, the analytics and ad tags are your choice and your responsibility. If you turn on the consent banner, tags that need consent are genuinely withheld until the visitor accepts; they are not loaded-and-hidden. The banner links to your privacy policy, because those vendors are your sub-processors, engaged by you.

10. Contact#

Data protection questions, DPA requests and data subject requests: contact@getlaunchlist.com.

We have not appointed a Data Protection Officer. Article 37 does not require one for processing at our scale, and naming a title nobody holds would be worse than saying so. That address reaches the people who actually run the systems this page describes.

You also have the right to complain to your supervisory authority.