Data Processing Agreement

Version: Draft 0.1 · 30 September 2026 · In force from [EFFECTIVE DATE]

This Data Processing Agreement ("DPA") is part of the contract between [COMPANY LEGAL NAME], [REGISTERED ADDRESS], [CHAMBER OF COMMERCE / CRO NUMBER] ("Otto", the processor) and the business that uses Otto ("the Client", the controller) under Otto's Terms of Service. It meets the requirements of Article 28 of the General Data Protection Regulation (EU) 2016/679 ("GDPR"). The Client accepts it together with the Terms; no separate signature is needed. A signed copy is available on request from [PRIVACY EMAIL].

1. Roles and scope

1.1 This DPA applies to personal data that Otto processes on the Client's behalf while providing Otto: the personal data in the Client's website, materials, social and ad accounts, and in the content Otto makes for the Client ("Client Personal Data"). Annex I describes it.

1.2 For Client Personal Data, the Client is the controller and Otto the processor. If the Client is itself a processor for someone else (for example an agency acting for its own clients), Otto is the Client's sub-processor, and the Client confirms that its own controller has authorised this.

1.3 Otto is a controller, not a processor, for the data it processes for its own purposes: the Client's account and sign-in data, billing, security and audit logs, statistics about its own website, and combined usage statistics that identify neither the Client nor any person. Otto's Privacy Policy covers that data. Review: check these controller/processor edges, in particular sign-in and approval data, and the use of combined, de-identified statistics to improve Otto.

1.4 GDPR terms used here (personal data, processing, controller, processor, data subject, personal data breach, supervisory authority) have their GDPR meaning.

2. Instructions

2.1 Otto processes Client Personal Data only on the Client's documented instructions. The instructions are: the Terms and this DPA; the Client's setup answers, settings, approvals and requests in the Otto app, by e-mail or in Telegram; and any other written instruction the Client gives that fits the service.

2.2 Otto tells the Client straight away if, in its opinion, an instruction breaks the GDPR or other data protection law, and may pause that instruction until the Client confirms or changes it.

2.3 Otto may process Client Personal Data other than on instructions only where EU or member-state law requires it, and then tells the Client first unless that law forbids it.

3. Confidentiality

Everyone at Otto who can access Client Personal Data is bound by confidentiality, by contract or by law, and has access only as far as their work needs it.

4. Security

4.1 Otto takes the technical and organisational measures in Annex II. They take into account the state of the art, the cost, the nature of the processing and the risks to people.

4.2 Otto may change the measures, as long as the overall level of protection does not go down.

5. Sub-processors

5.1 The Client gives Otto general authorisation to use sub-processors. The current list is in Annex III and on Otto's Sub-processors page.

5.2 Otto tells the Client at least 30 days before adding or replacing a sub-processor, by e-mail to the account address and by updating that page. The Client may object within that time on reasonable data-protection grounds. If Otto cannot meet the objection, the Client may end the affected part of the service before the change, and Otto refunds fees paid for the time after the end.

5.3 Otto puts each sub-processor under a written contract with data protection obligations at least as strict as this DPA, and remains responsible to the Client for its sub-processors' performance.

6. Transfers outside the EU

6.1 Otto stores Client Personal Data on servers in Germany. Some sub-processors process it outside the European Economic Area (Annex III). Otto makes such transfers only with a valid safeguard under Chapter V GDPR: an adequacy decision (including the EU–US Data Privacy Framework for certified companies) or the EU standard contractual clauses (Commission Decision 2021/914, module 3 between Otto and its sub-processor), together with a transfer impact assessment and extra measures where needed.

6.2 Review: if the contracting Otto entity is established outside the EU (for example in Israel, which has an EU adequacy decision), confirm how the Client-to-Otto transfer is covered and whether module 2 or 4 clauses are needed anywhere.

7. Helping the Client

7.1 Data subject requests. Otto passes any request it receives from a data subject about Client Personal Data to the Client within five business days and does not answer it itself unless the Client asks. Otto helps the Client answer requests for access, correction, deletion, restriction, portability and objection, as far as the service allows.

7.2 Other obligations. Otto helps the Client with security, breach notification, data protection impact assessments and prior consultation of a supervisory authority (Articles 32 to 36 GDPR), taking into account the information Otto has. Help beyond what the service normally provides may be charged at reasonable cost, agreed in advance.

8. Personal data breaches

8.1 Otto informs the Client without undue delay, and at the latest within 48 hours, after becoming aware of a personal data breach affecting Client Personal Data.

8.2 The notice describes, as far as known then: what happened, the categories and approximate number of people and records concerned, the likely consequences, what Otto has done or proposes to do, and a contact person. Otto sends more information as it learns it.

8.3 Otto records every breach, its effects and the measures taken. Telling the Client about a breach is not an admission of fault.

9. End of the service

9.1 While the plan is active, and for 90 days after it ends, the Client can ask for an export of its data (Terms, section 17).

9.2 90 days after the plan ends, Otto deletes Client Personal Data from its live systems. It leaves Otto's encrypted backups as they roll over, within about 8 weeks after that. Where EU or member-state law requires Otto to keep some data, Otto keeps only that data, only for as long as required, and keeps it confidential. On request, Otto confirms the deletion in writing.

10. Audits and information

10.1 Otto makes available the information needed to show that it meets Article 28 GDPR, starting with this DPA, its annexes and answers to reasonable security questionnaires.

10.2 If that is not enough, the Client (or an independent auditor bound by confidentiality) may audit Otto once a year, with at least 30 days' notice, during business hours, without disrupting the service, and at the Client's cost. Audits after a breach, or ordered by a supervisory authority, are not limited to once a year.

11. Liability and term

11.1 The limits of liability in the Terms apply to this DPA, to the extent the law allows. Review: whether data protection claims should share the general cap.

11.2 This DPA lasts as long as Otto processes Client Personal Data. If the Terms and this DPA conflict about personal data, this DPA prevails. It is governed by the same law, and disputes go to the same court, as the Terms.

Annex I — The processing

Annex II — Technical and organisational measures

These are the measures Otto takes today, as built into its server and software. Review: items marked Engineering are not in place yet; each must be done, or its sentence removed, before publishing.

Where the data is

• One dedicated Otto server at Hetzner in Germany (Nuremberg or Falkenstein). Hetzner runs its data centres under ISO/IEC 27001 and provides their physical security. Verify: current certificate.
• Clients' data lives in one place on that server (/var/lib/otto); the code is a separate, read-only checkout; secrets are in a separate directory readable only by the Otto service account.

Network

• Every request reaches the server through Cloudflare. The server's firewall refuses all incoming traffic except web traffic from Cloudflare's published address ranges (updated automatically) and SSH.
• SSH: keys only, password login switched off, connection attempts rate-limited and repeat offenders blocked (fail2ban); optionally limited to our own addresses.
• Encrypted connections everywhere: browser to Cloudflare, and Cloudflare to our server with an origin certificate in "Full (strict)" mode; HTTP Strict Transport Security. The server calls Meta, Google, Stripe and the AI providers over HTTPS.
• Rate limits for the public addresses (website scan, statistics, onboarding, payment notifications) at Cloudflare and again inside the API, plus request size limits.

Who can get in

• Clients sign in to the app with Google (OpenID Connect: Otto checks Google's signed answer, stores no password, and keeps sign-in sessions only as one-way hashes that expire after 30 days unused). Our owner console is behind Cloudflare Access: a one-time code sent to an allowed team e-mail address. Nobody shares a password.
• The owner console is limited to named members of the Otto team. Every action taken there (pausing, approving a campaign on a client's written request, changing a plan) is logged with who did it and when.
• Our web server removes any identity headers a browser tries to send; the API accepts the signed-in identity only from our web server, which proves itself with a secret key.
• Meta and Google are connected through their own sign-in (OAuth). Otto never sees the Client's passwords. Access tokens are stored per brand in files readable only by the Otto service account, and the Client can revoke them in Meta or Google at any time.
• Payment notifications from Stripe (and, for the legacy founding seats, Whop) are accepted only with a valid signature, only if less than 5 minutes old, and each only once. Card and bank details are entered in Stripe's own form inside Otto's Billing page and never reach Otto's server.

Keeping clients apart

• Every record is tied to its brand. The API shows a signed-in person only the brands they are a member of. Setup without an account can only create a new brand, never change an existing one.
• Pages served to clients never carry other clients' data. Owner-side information (billing, plan history, sales notes) is kept in separate files that never reach the client app.
• All clients share one server and one data store: the separation is logical, not physical.

Software and changes

• Strict Content Security Policy on every page; no third-party scripts in the client app.
• Website scans only fetch public web addresses; every fetch checks that the address does not point into a private network.
• Every change goes through an automated pipeline: the full test suite (including security tests) runs on a clean copy of the code, then the release is switched in, health-checked, and rolled back automatically if anything fails. Every deploy is logged.
• The server gets security updates automatically. Otto's services run as an unprivileged user in a restricted sandbox (read-only system, no privilege escalation, private temporary files).

Encryption and backups

• Backups are compressed and encrypted with age before they leave the server. Only the public key is on the server; the private key is kept offline by the managing director.
• Nightly off-site backup to a Hetzner Storage Box, kept 14 days (daily) and 8 weeks (weekly), with size checks; Hetzner server snapshots, kept 7 days. A tested script rebuilds a server from the latest backup.
• Data on the server's own disk is not encrypted separately at file level. Engineering: consider disk encryption for the data directory.
• Images and videos are served from public web addresses so that Meta can fetch them for publishing.

Monitoring and logs

• Every scheduled job and every backup reports a heartbeat; a failed one sends an alert to the Otto team.
• Our web server keeps no access log (no visitor IP addresses). The API logs errors without the content of requests. Logs are rotated weekly and kept 8 weeks.
• One switch pauses all publishing and all ad launches at once, and pauses live campaigns.

People and process

• Access to client data only for team members who need it for their work, bound by confidentiality. Decision: name who has server access and who has owner-console access.
• A written procedure for personal data breaches, with notice to clients within 48 hours (section 8). Engineering: write the breach runbook.
• Data minimisation: website statistics without cookies or stored IP addresses; e-mail addresses masked in the owner console; secrets never displayed.

Annex III — Sub-processors

The current list, which Otto keeps up to date on its Sub-processors page under section 5.

Back to top