Learn what a data processing addendum GDPR requires under Article 28. Compare statutory DPA templates with enterprise SaaS terms to protect your business.
TL;DR: A data processing addendum GDPR buyers can rely on binds your SaaS vendor to Article 28 duties: act on your instructions, secure the data, limit sub-processors, report breaches and delete data at exit. Enterprise terms suit buyers who accept fixed wording. Click-through terms without these commitments suit nobody.
What a data processing addendum gdpr requires
You need a signed DPA whenever an outside SaaS provider processes personal data for you. Article 28 makes that contract mandatory, and it makes the vendor liable for what it promises in it.
The DPA protects you as the controller. Customer emails, employee names and recordings stay under your binding instructions, and the vendor can't repurpose them. It also protects you from the opposite problem: vendors that rely on generic click-through Terms of Service with no Article 28 commitments. Those leave you exposed to Article 83 fines of up to €20M or 4% of global annual turnover, whichever is higher.
Every compliant DPA does four jobs:
- It binds the processor to documented controller instructions only.
- It requires technical and organisational safeguards.
- It restricts and controls sub-processors.
- It requires deletion or return of data when the contract ends.
The next sections test each of these against the GDPR.eu Model Template, the Atlassian DPA, the Semrush DPA, the Surfer SEO DPA and the DataForSEO Terms.
Data controller vs processor obligations explained
Who is the controller and who is the processor?
You are the controller because you decide why and how the data is used. The SaaS vendor is the processor and handles data only on your instructions. The GDPR.eu Model Template says this directly in section 2.1: the processor complies with data protection laws and doesn't process personal data other than on documented instructions.
Imagine your HR manager uploads staff names into a scheduling tool. The tool's vendor may store and process those names to run the service. It may not mine them for its own product analytics unless your instructions allow it.
What counts as a documented instruction?
Enterprise DPAs define instructions broadly. In the Atlassian DPA (section 2.1), the DPA itself, the main agreement, your orders and your use of the product, including configurations and settings, all count as documented instructions. Atlassian processes data solely under them.
That convenience carries a catch. You must make sure your instructions comply with applicable data protection law, and Atlassian isn't responsible for monitoring that. So switching on a feature is a legal act as well as a technical one. If you run Atlassian tools such as Jira, someone on your side should own those settings.
What must the processor do about staff and security?
Staff first. Both the GDPR.eu template (section 3) and the Atlassian DPA (section 2.2) require everyone with access to your data to be under confidentiality undertakings or statutory confidentiality duties. The template also limits access to people who need it for the contract.
Security comes next, and here the wording diverges. The template points to Article 32(1) measures appropriate to the risk. Atlassian maintains technical and organisational measures and may update them, but not in a way that materially decreases the overall security of its cloud products during your subscription term (section 3.1). Atlassian also puts part of the burden on you: you configure the product to fit the sensitivity of your data.
Subprocessor notification period and objection mechanics
How do statutory templates and commercial DPAs differ?
The gap between the two is widest on sub-processors. The GDPR.eu Model Template says the processor may not appoint any sub-processor unless you require or authorise it (section 5.1). The Atlassian DPA instead gives general written authorisation up front (section 4.1).
| Point | GDPR.eu Model Template | Atlassian DPA |
|---|---|---|
| Authorisation model | Case-by-case, by the Company | General authorisation given on signing |
| Notice of new sub-processors | Appointment needs your authorisation first | Public list with email subscription, at least 30 days before use |
| Your remedy if you object | Withhold authorisation | Terminate the affected order for convenience, as the sole and exclusive remedy |
Source: GDPR.eu template, Atlassian DPA (effective 17 August 2026), Semrush, Surfer SEO and DataForSEO legal pages, checked October 2026.
What does the notice period mean in practice?
Atlassian's notice only reaches the email addresses subscribed to its sub-processor list. If nobody on your team subscribes, the 30-day window passes unseen. Assign the subscription to a shared privacy mailbox, not to one person's inbox.
The objection right is narrower than it sounds. You can object during the notice period, but your only remedy is ending the order for the affected product. For a team locked into an annual plan, that is a business decision, not a veto.
Who is liable if a sub-processor fails?
The vendor is. Atlassian must sign a written agreement with each sub-processor imposing the same standard of data protection as the DPA, and it remains liable to you if a sub-processor fails (section 4.1). Article 28(4) requires the same flow-down from any processor, so treat its absence in a DPA as a red flag.
Breach notification windows and data deletion rules
How fast must the vendor tell you about a breach?
Article 33(2) says "without undue delay", with no number attached. The GDPR.eu template follows that wording and adds that the processor must give you enough information to meet your own reporting duties (section 7.1). The Atlassian DPA sets a concrete target: no later than 72 hours after becoming aware of a Security Incident, where feasible (section 3.2).
Your own clock is tight. Under Article 33(1) you have 72 hours to notify your supervisory authority, such as the CNIL, the BfDI or Datatilsynet. A vendor that uses its full window leaves little room to gather facts. So look for a DPA that also obliges the vendor to assist with cause, mitigation and information you can pass on. Atlassian does, although it states that its notice is not an admission of fault.
When must data be deleted after you leave?
The GDPR.eu Model Template is strict: delete all copies within 10 business days of the date services end (section 9.1). That is the benchmark to hold other DPAs against.
Commercial terms are looser. Atlassian deletes your personal data after termination in line with its documentation, but it may keep data required by law or held in standard backups and records under its retention policies (section 6.2). Retained data stays confidential and subject to the DPA, and Atlassian can't process it further except as the law requires.
That carve-out is reasonable but it has a cost. Your data can sit in backups after you leave, with no stated deadline in the DPA text. Ask where those backups live, for example Frankfurt versus US East, and whether the vendor keeps transcripts or recordings without a retention schedule.
Standard contractual clauses sccs for international transfers
When do you need SCCs?
You need them when personal data leaves the EEA to a country without an adequacy decision. The standard mechanism is the set of clauses in Commission Implementing Decision (EU) 2021/914. Do not rely on the EU-US Privacy Shield, which the CJEU invalidated in 2020.
The GDPR.eu template is cautious here. The processor may not transfer data outside the EU or EEA without your prior written consent, and the parties then rely on EU-approved standard contractual clauses unless agreed otherwise (section 11.1).
What changes for UK buyers?
UK transfers run under UK GDPR, not the EU text. Practical Law publishes a controller-to-processor DPA drafted to meet Article 28 of the UK GDPR and the Data Protection Act 2018. That version covers processing within the UK and transfers from the UK to the EEA. A separate Practical Law document covers processors outside the EEA.
For transfers to countries without UK adequacy, UK buyers pair EU clauses with the ICO's International Data Transfer Addendum. So a DPA that only cites the EU clauses may leave your UK entity short.
How do the vendors handle it?
- Atlassian DPA: transfer provisions sit in Schedule 2 (Region-Specific Terms), which ranks above the main body of the DPA if the two conflict.
- Semrush DPA: Semrush acts as processor, and its DPA includes the EU Standard Contractual Clauses (Decision 2021/914) plus a UK transfer mechanism. The clauses are governed by Czech law. See the Semrush page for plans.
- Surfer SEO DPA: a standard DPA from a Polish controller, with processing and NLP analysis hosted in the EU (Poland and Germany). The Surfer SEO page has the plan details.
- DataForSEO Terms: the privacy policy describes written Article 28 agreements with its sub-processors and SCCs or adequacy decisions for transfers outside the EU. A customer-facing DPA doesn't appear in the documentation, so confirm you can get a signed one before you buy. See the DataForSEO page.
That last point matters most. An Article 28 chain between a vendor and its own suppliers does not give you a contract with the vendor.
How European buyers audit SaaS terms
What audit rights should the DPA give you?
Article 28(3)(h) requires the processor to make available all information needed to show compliance and to allow audits. The GDPR.eu template goes furthest: it allows audits, including inspections, by you or an auditor you mandate (section 10.1). It adds that these rights apply only where the main agreement doesn't already give you equivalent ones (section 10.2).
Enterprise vendors rarely open their data centres to every customer. The Atlassian DPA instead supplies a summary of relevant independent audit reports, provided you sign a non-disclosure agreement (section 7.1). That is a workable compromise if the reports are current and cover the services you use. Ask which certifications they reflect, such as SOC 2 Type II or ISO/IEC 27001.
How do you verify where data is hosted?
Look for named locations. Surfer SEO states EU hosting in Poland and Germany. DataForSEO's sub-processor list names Hetzner Online GmbH in Germany next to Google and Microsoft Azure in the United States, and the policy doesn't say which data sits where. For a buyer that needs EU-only processing, that difference decides the matter.
What else belongs on your checklist?
- DPIA support: the vendor must help with Article 35 impact assessments and Article 36 consultations. The GDPR.eu template commits to reasonable assistance (section 8), while Atlassian's help applies when you can't reasonably do the work yourself using its documentation (section 5.2).
- Data subject requests: the processor should notify you promptly and not answer the individual without your instruction.
- Government requests: Atlassian notifies you of valid legal process unless prohibited by law.
- AI training: GDPR doesn't ban model training, so confirm the terms exclude your content from it.
Bottom line for European software buyers
Never put identifiable customer or employee data into a SaaS tool without an executed, Article 28 compliant DPA. If you want EU hosting and a standard DPA in one place, Surfer SEO is the cleanest fit among these vendors. If you use Semrush or Atlassian, read the executed SCCs and UK terms before you sign. If you are weighing DataForSEO, get a customer DPA in writing first. Browse Semrush alternatives if the answer is no.
Your next step: compare each vendor's sub-processor notice window and backup retention clause against the GDPR.eu Model Template before you commit to an annual term.
