Enlist

Data processing agreement

Last updated

pursuant to Article 28(3) of Regulation (EU) 2016/679 (the General Data Protection Regulation) between

  • The controller: the customer, meaning the person or business that holds an Enlist account and has accepted the terms of service, and
  • The processor: Mike Hagen Eggertsen, a private individual with no CVR number, Peder Hjorts Vej 7, 2500 Valby, Denmark ("Enlist"). A natural person may be a processor (Article 4(8)).

1. Preamble

  1. This agreement sets out the rights and obligations of the parties when Enlist processes personal data on the customer's behalf.
  2. The agreement is designed to comply with Article 28(3) of the General Data Protection Regulation.
  3. The processing takes place as part of providing Enlist, waitlist infrastructure offered as an API, SDK, MCP server and dashboard, under the terms of service.
  4. This agreement takes precedence over similar provisions in other agreements between the parties.
  5. The agreement has four appendices. Appendix A describes the processing, Appendix B the sub-processors, Appendix C the customer's instructions and the security measures, and Appendix D the parties' other terms, including deletion on termination.
  6. This agreement does not relieve Enlist of the obligations that apply directly to processors under the General Data Protection Regulation.

2. The customer's rights and obligations

  1. The customer is responsible for ensuring that the processing complies with the General Data Protection Regulation and other applicable data protection law.
  2. The customer has the right and the obligation to decide the purposes and means of the processing.
  3. Among other things, the customer is responsible for having a legal basis for the signups it collects and the emails it has Enlist send, and for informing the people on its waitlists about the processing.
  4. The customer does not store national identification numbers, special categories of personal data (Article 9) or data about criminal offences (Article 10) in Enlist, including in custom fields and metadata.

3. Enlist acts on instructions

  1. Enlist processes personal data only on documented instructions from the customer, unless required by EU or Danish law. The instructions are set out in Appendices A and C. The customer's use of Enlist through the API, SDK, MCP server or dashboard is also an instruction.
  2. Enlist immediately informs the customer if, in Enlist's opinion, an instruction infringes data protection rules.

4. Confidentiality

  1. Only people at Enlist who need access to provide the service have access to the customer's data. They are bound by confidentiality. Today that is the person named above.
  2. Access is reviewed regularly and removed when no longer needed.

5. Security of processing

  1. Enlist implements appropriate technical and organisational measures under Article 32, taking into account the risk to the rights of the people on the customer's waitlists. The measures are described in Appendix C.
  2. Enlist assists the customer in meeting the customer's own obligations under Article 32.

6. Use of sub-processors

  1. By this agreement the customer gives general prior authorisation for Enlist to use sub-processors. The authorised sub-processors are listed in Appendix B and on the Sub-processors page.
  2. Enlist notifies the customer by email, at the account's email address, of any intended addition or replacement of sub-processors at least 30 days in advance, so the customer can object. If a sub-processor gives Enlist shorter notice, Enlist notifies the customer as soon as possible.
  3. If the customer objects on reasonable grounds and the parties cannot find a solution, the customer may terminate the agreement by deleting its account before the change takes effect. Fees paid for a period after the change takes effect are refunded.
  4. Enlist imposes the same data protection obligations on sub-processors as in this agreement and remains fully liable to the customer for their performance.
  5. Services the customer itself connects to its account (outbound webhooks, Slack, Discord, Loops, Kit, PostHog, or its own email provider account) are not sub-processors of Enlist. Sending data to them is an instruction from the customer, and the customer's own agreement with each service applies. See Integrations you connect.

7. Transfers to third countries

  1. Personal data is transferred to countries outside the EU/EEA only on instructions and in accordance with Chapter V of the General Data Protection Regulation.
  2. The customer authorises the transfers and transfer bases set out in Appendix B. Enlist's servers run in the USA.

8. Assistance to the customer

Enlist assists the customer in responding to requests from data subjects exercising their rights (Chapter III). Among other things, Enlist provides these tools:

  • look up a signup by email address through the API, SDK or MCP server
  • export a whole waitlist as CSV through the API or the dashboard, on every plan
  • delete a signup through the API, SDK or MCP server. The signup is deleted from the database at once, and a signup.removed event is sent to the integrations the customer has connected
  • delete a whole waitlist, or the whole account, which deletes its signups at once

Enlist also assists with security, breach notification, impact assessments and prior consultation under Articles 32 to 36, to a reasonable extent.

9. Notification of personal data breach

  1. Enlist notifies the customer without undue delay and no later than 48 hours after becoming aware of a personal data breach, so the customer can meet its own 72-hour deadline towards its supervisory authority (Article 33).
  2. As far as possible, the notification contains the information the customer needs to notify the supervisory authority under Article 33(3).

10. Erasure and return of data

  1. On termination, Enlist deletes the customer's personal data as described in Appendix D, unless EU or Danish law requires storage. Before then, the customer can export its waitlists as CSV.

11. Audit and inspection

  1. Enlist makes available the information needed to demonstrate compliance with Article 28 and this agreement, and allows for audits, including inspections, by the customer or an auditor the customer has authorised.
  2. At the customer's request, Enlist provides a written statement on the processing and the security measures, at most once a year unless there is a specific reason for more.
  3. Physical inspections are agreed with at least 30 days' notice. Enlist has no server rooms of its own; processing takes place at the sub-processors, and they are supervised on the basis of their own audit reports and certifications, which Enlist makes available on request where the sub-processor allows it.
  4. The customer bears its own costs and those of any auditor it authorises. Enlist bears its own costs.

12. The parties' agreement on other terms

  1. The parties' other terms are set out in Appendix D.

13. Commencement and termination

  1. The agreement takes effect when the customer accepts the terms of service, by creating an account or using Enlist.
  2. The agreement applies for as long as Enlist processes personal data on the customer's behalf.
  3. Enlist gives at least 30 days' notice of material changes to the agreement by email. If the customer does not want the changes, it may terminate the agreement by deleting its account before they take effect. Changes to Appendix B follow clause 6.

14. Contacts

  • The customer: the email address registered on the Enlist account.
  • Enlist: support@enlist.dev

Appendix A: Information about the processing

Purpose

To provide Enlist to the customer: collecting signups to the customer's waitlists, assigning positions, sending signup emails and tracking their delivery, tracking referrals, reporting statistics, and forwarding events to the integrations the customer connects.

Nature of the processing

Collection through the API, storage, organisation, searching, display, statistics, export, sending emails, forwarding to the customer's integrations, and erasure.

Categories of data subjects

  • people who join one of the customer's waitlists, or whom the customer adds to one

Types of personal data

  • Signup: email address, the waitlist, position, and time of signup.
  • Source: the source tag (utm_source) and the referring page (referrer), if the customer sends them.
  • Language: the signup's preferred language (locale, a tag such as "da"), if the customer sends it. It decides which language the signup email is sent in.
  • Referrals: the signup's own referral code, which signup referred them, and how many people they have referred.
  • Custom fields: values for the fields the customer defines on the waitlist (text, number or yes/no, at most 20 per waitlist). The customer decides the content, see clause 2.4.
  • Metadata: up to 10 text key/value pairs the customer's server attaches to a signup. The customer decides the content, see clause 2.4.
  • Signup email: the email is built from the customer's template, in the signup's language where the customer has written one, and the signup's data when it is sent, and sent with the from and reply-to addresses the customer sets, so a reply from the signup goes to the customer, not to Enlist. Enlist stores the provider's message ID and the delivery status, and, where email event tracking is on, when the email was delivered, opened and clicked. Enlist does not keep a copy of each sent email.
  • Integration delivery log: for each event forwarded to an integration the customer has connected, the event's content (which contains the signup's data), the time and the result.
  • Technical data: the IP address a signup request comes from, kept in a rate-limit counter, see Appendix C.

Special categories of personal data (Article 9), data about criminal offences (Article 10) and national identification numbers are not covered, see clause 2.4.

Duration

For as long as the customer uses Enlist, and thereafter as described in Appendix D.

Appendix B: Sub-processors

On entering into this agreement, the customer authorises the sub-processors listed on the Sub-processors page with name, purpose, location and transfer basis. The list forms part of this agreement. Services the customer connects itself are not sub-processors, see clause 6.5.

Appendix C: Instructions and security

C.1 Subject matter and instructions

Enlist processes the customer's data to provide the features the customer uses, see Appendix A. The customer's requests to the API, SDK and MCP server and its actions in the dashboard (for example adding or deleting a signup, choosing an email provider or connecting an integration) are instructions.

C.2 Security measures

  • Encryption in transit: all traffic to the API, the dashboard and the site uses HTTPS (TLS).
  • Separation between customers: every waitlist and signup belongs to one account, and every query is limited to that account. A request for another account's waitlist is answered as if it did not exist.
  • API keys: keys are generated randomly and shown once, at creation. Enlist stores only a SHA-256 hash and the first characters, compares keys in constant time, and checks on every request whether the key has been revoked. Each key has scopes that limit what it can do.
  • Dashboard sign-in: only through GitHub, which releases only a verified email address. There are no passwords. Sessions expire after 30 days.
  • Credentials for other services: API keys and signing secrets the customer gives Enlist for its email provider and integrations are encrypted with AES-256-GCM, using a key held only in the application's environment, not in the database. The dashboard shows only a hint of them.
  • Webhooks: outbound webhooks are signed with an HMAC-SHA256 secret, so the receiver can verify them. Incoming webhooks from email providers are accepted only with a valid signature. Destinations the customer enters are checked so that Enlist cannot be made to call internal network addresses.
  • Rate limits: each account has a request limit per minute that follows its plan, and the public signup endpoint is also limited per IP address. The counters hold the IP address for the current one-minute window and are deleted after one hour by a routine cleanup.
  • Logging: the application's logs redact API keys, authorization headers and cookies.
  • Backups and encryption at rest: the database runs at Neon, which encrypts it at rest with AES-256 and all connections with TLS. Neon keeps the database's restore history for no longer than 30 days.

C.3 Place of processing

Processing takes place at the sub-processors and locations listed in Appendix B. Enlist's server functions run in Washington, D.C., USA (Vercel region iad1), and its database in N. Virginia, USA (Neon, AWS US East 1). Enlist is run from Denmark.

Appendix D: Other terms and deletion on termination

D.1 Deletion

  1. The customer can delete a signup, a waitlist or its whole account at any time. The data is deleted from Enlist's database at once.
  2. Deleting a signup does not remove it from the integration delivery log. Log entries are deleted when the customer deletes the integration, points it at a new destination, or deletes its account.
  3. If Enlist ends the service for a customer, Enlist gives at least 30 days' notice by email, so the customer can export its waitlists, and deletes the customer's personal data no later than 30 days after termination.
  4. Data in Neon's restore history is deleted when it ages out, no later than 30 days after deletion.
  5. On request, Enlist confirms the deletion to the customer in writing.
  6. Data the customer has sent to integrations it connected is not deleted by Enlist. It is under the customer's agreement with that service.

D.2 Liability

Liability and limitation of liability follow the terms of service. The limitation does not apply to Enlist's liability towards data subjects under Article 82 of the General Data Protection Regulation.

D.3 Governing law

This agreement is governed by Danish law. Disputes are settled by the Danish courts.