Article 28 Checklist for SaaS DPAs, Ready Clauses and Negotiation Tips

Hands reviewing a SaaS data agreement

Yes. Any time a SaaS provider handles personal data on your behalf, GDPR Article 28 requires a written data processing agreement, and equivalent laws elsewhere expect the same. Get one signed that covers the processing scope, security measures, sub-processor rules and a lawful transfer mechanism, then check the clause list below before you sign anything.

TL;DR:

  • A signed data processing agreement is mandatory under GDPR whenever a SaaS provider handles personal data on your behalf, covering scope, security, sub-processors, and transfer mechanisms.
  • The DPA must include core elements such as processing purpose, data types, instructions, confidentiality, security, sub-processor rules, data subject support, and deletion upon contract termination.
  • Most SaaS vendors rely on sub-processors and must impose the same data protection obligations through contractual clauses, with notification and objection rights for the controller.
  • Data transfers outside the EU or UK require lawful mechanisms like Standard Contractual Clauses unless an adequacy decision exists for the destination country.
  • Focus negotiations on critical clauses like sub-processor notice, breach reporting timelines, and end-of-contract data deletion, especially for high-risk or high-volume personal data tools.

Table of Contents

What a SaaS data processing agreement actually covers

A SaaS data processing agreement, usually shortened to DPA, is the contract that sits underneath your commercial SaaS agreement and governs how the provider handles personal data. It exists because GDPR draws a hard line between two roles: the controller, who decides why and how data gets processed, and the processor, who processes it on the controller’s instructions. Under Article 28 of GDPR, any processing carried out by a processor must be governed by a contract that binds the processor to specific documented instructions.

Your SaaS agreement handles the commercial relationship: pricing, uptime, support tiers, termination rights. The DPA handles something narrower and more legally sensitive: what happens to the personal data flowing through that software. Treating these as one document usually ends badly, either because privacy obligations get diluted by commercial negotiation, or because commercial terms get held hostage over data clauses. Keep them separate and each moves faster.

Think about a typical project management tool. It stores names, email addresses, task assignments, sometimes client contact details uploaded by your team. That’s personal data under GDPR, and the moment a vendor stores or processes it for you, they’re a processor and you’re a controller. The same logic applies to CRM platforms, HR software, marketing automation and most workplace SaaS tools. If the software touches identifiable information about real people, a DPA belongs in the contract stack, sitting alongside the data ownership terms in your SaaS agreement rather than replacing them.

When does a SaaS DPA become mandatory?

The trigger is simple in theory: a controller engages a processor to handle personal data on its behalf. In practice, plenty of teams miss this because the processing looks incidental rather than central to the product.

A few common situations that quietly trigger the requirement:

If any of that sounds like your stack, you need a DPA rather than a verbal understanding without formal agreement.

Jurisdiction matters here too. Under GDPR and the UK GDPR, the DPA requirement is explicit and enforceable, with fines attached. Other regions increasingly mirror this structure through their own privacy laws, but the specific mandatory clauses, notice periods and penalties vary by jurisdiction. Don’t assume a template built for one region satisfies obligations in another. Check local law, or get someone who knows it to check for you, before you rely on a single DPA template across every market you operate in.

The Article 28 checklist: mandatory and optional SaaS DPA clauses

Every SaaS DPA needs to cover a fixed set of elements before it’s worth signing. The ICO’s guidance on contracts between controllers and processors lays out the minimum contents required under Article 28, and it’s worth working through each one methodically rather than accepting a vendor’s boilerplate at face value.

The non-negotiable Article 28 minimums:

Beyond that minimum list, well-drafted SaaS DPAs usually add clauses that aren’t strictly mandated but protect both sides in practice: notification timelines for security incidents, specific escalation contacts, data segregation commitments for multi-tenant platforms, and defined liability caps.

On liability specifically: Article 28 doesn’t dictate indemnity structures, so this is where negotiation actually happens. Vendors typically want liability capped, often tied to fees paid over a trailing 12 months, and want indirect or consequential losses excluded entirely. Buyers, particularly ones handling sensitive data, push for uncapped liability on security breaches or GDPR fines that flow from the processor’s own failure. A workable middle ground caps general commercial liability while carving out unlimited liability for gross negligence, wilful breach, or confidentiality violations. Insurance requirements (cyber liability cover, typically) often sit alongside this as evidence the vendor can actually pay out if something goes wrong.

Pro Tip: Ask vendors for their DPA before you sign the main SaaS contract, not after. If they can’t produce one, or it’s missing half the Article 28 minimums, that’s a signal worth escalating before procurement gets further along.

The Article 28 checklist: mandatory and optional SaaS DPA clauses — overview diagram

How sub-processor obligations flow down the chain

Almost no SaaS provider processes your data entirely in-house. Cloud hosting, email delivery, payment processing, customer support tooling, most vendors rely on a chain of sub-processors to deliver their product. The DPA has to account for that chain, not just the direct relationship.

Article 28(9) sets the rule plainly: when a processor engages a sub-processor, it must impose the same data protection obligations by contract, and the initial processor remains fully liable to the controller for anything the sub-processor gets wrong. Your vendor doesn’t get to shrug and point at a subcontractor if something leaks.

Two models govern how sub-processors get approved in practice:

Most enterprise SaaS DPAs use general authorisation with a notice period, typically a few weeks, because specific authorisation doesn’t scale once a vendor is running dozens of sub-processors. What matters is the notification cadence being explicit and the objection right being real, not decorative. Good clause language reads something like: “Processor shall notify Controller at least 14 days prior to any change in Sub-processors, and Controller may object on reasonable data protection grounds within that period.” Vague language (“Processor may update its sub-processor list from time to time”) gives the controller nothing to act on.

Handling international data transfers under a SaaS DPA

Most SaaS platforms run infrastructure across multiple countries, which means personal data routinely crosses borders the moment you sign up. If that crossing takes data out of the EU or UK into a country without an adequacy decision, you need a lawful transfer mechanism, and Standard Contractual Clauses are the most common one.

Standard Contractual Clauses (SCCs) are a pre-approved framework issued by the European Commission that legitimises transfers by binding both the exporter and importer to specific data protection commitments, regardless of what the destination country’s own laws provide. They get annexed directly to the DPA rather than negotiated from scratch, which is one reason they’ve become the default mechanism for SaaS vendors operating globally.

Adequacy decisions are the simpler alternative where they exist. If the European Commission has ruled a destination country provides adequate protection, transfers can happen without SCCs at all. But adequacy only covers a limited list of countries, and most major cloud regions (the US among them) rely on other mechanisms or a patchwork of certifications instead.

Drafting-wise, your DPA annex should name the specific transfer mechanism in use, map exactly which data exporters and importers are involved (this matters more once sub-processors are in the mix), and keep a record of which SCC modules apply, since the 2021 SCCs come in different modules depending on whether it’s controller-to-processor or processor-to-processor transfer. This pairs naturally with clear data residency commitments that specify where data actually lives, not just which legal mechanism authorises it moving.

Handling international data transfers under a SaaS DPA — overview diagram

What security measures should a SaaS DPA require?

Article 28 requires “appropriate technical and organisational measures,” a phrase deliberately vague enough to cover both a two-person startup and an enterprise platform. The DPA should pin that down with specifics rather than leaving it to interpretation later — for more on typical controls, see Data and security.

Expect (and negotiate for) commitments covering:

Breach notification deserves its own attention because timing gaps here create real regulatory exposure. Controllers generally have 72 hours to notify their own supervisory authority once they become aware of a breach, but that clock doesn’t start when your vendor discovers the problem, it starts when they tell you. A DPA that lets the vendor sit on a breach for a week before notifying you has already blown your compliance window before you’ve even heard about it. Insist on prompt notification (commonly “without undue delay” or a fixed number of hours) plus a commitment to cooperate on remediation and provide details sufficient to meet your own notification obligations.

For evidence of these controls actually existing, SOC 2 reports, penetration testing summaries and a documented vulnerability disclosure programme are the standard proof points vendors should hand over without much prompting. If a provider can’t produce any of these on request, that’s worth treating as a gap rather than an oversight.

Getting practical support for data subject requests

Article 28(3)(e) requires the processor to assist the controller in responding to data subject rights requests, access, erasure, rectification, portability, within a reasonable timeframe. GDPR gives controllers one month to respond to most requests, so the DPA needs to set an internal deadline for the vendor that leaves you enough runway to actually meet that clock.

In practice, this assistance should show up as tooling, not just a promise on paper: export functions that pull a user’s data into a portable format, deletion APIs that remove records on request rather than requiring a support ticket, and a named escalation contact for anything urgent. Vendors that force every access request through a generic support queue tend to blow through response windows.

DPIA (Data Protection Impact Assessment) cooperation matters too, particularly for higher-risk processing. If your use of the platform requires a DPIA, the vendor should be able to supply relevant information about their own processing and security posture on request, and cooperate with any prior consultation your supervisory authority requires.

What happens to your data when the contract ends

End-of-contract handling is where a lot of otherwise solid DPAs go soft, because vendors default to vague language (“data will be deleted in accordance with our policies”) that gives you nothing to hold them to. Article 28 requires processors to delete or return all personal data once the service ends, at the controller’s choice, and also to make available information necessary to demonstrate compliance, including cooperation with audits.

Push for specifics: a defined return window (30, 60 or 90 days is typical), an export format you can actually use, and secure deletion carried out to a named standard with written certification once it’s done. The DPA should also explicitly prohibit withholding data as leverage in a payment or contract dispute, since that’s a real pattern vendors fall into when relationships turn sour.

Before you’re in an actual termination scenario, run a test export while the contract is still active. A dry-run backup or export tells you whether the promised format is genuinely usable, rather than discovering the gap when you’re already under time pressure to migrate.

How to put a SaaS DPA in place without stalling procurement

Getting a compliant DPA signed doesn’t need to be a six-week legal saga. Most delays come from teams treating it as a bespoke negotiation when it should be a structured checklist exercise.

  1. Map your vendors and data flows first. List every SaaS tool touching personal data and what categories of data each one processes. You can’t prioritise DPA negotiations without knowing where the exposure actually sits.
  2. Decide self-service versus negotiated. For lower-risk tools, accepting a vendor’s published, Article 28-compliant DPA is usually faster and perfectly adequate. Reserve negotiation effort for platforms handling sensitive or high-volume personal data.
  3. Get procurement and security aligned early. Security should review the technical measures clause and evidence (SOC 2, penetration tests) at the same time legal reviews the contract language, not after signature.
  4. Negotiate the clauses that matter, not all of them. Sub-processor notice periods, liability caps and breach notification timing are worth fighting for. Formatting and boilerplate definitions usually aren’t.
  5. Keep version control. Track which DPA version you signed and when, particularly if the vendor updates sub-processor lists or security controls regularly.

Pro Tip: Vendors that publish a self-service DPA page with version history are usually the fastest to close, because you’re accepting known terms rather than starting a negotiation from zero. Treat that as a genuine signal of operational maturity, not just a convenience.

Sample clauses and a procurement checklist you can reuse

A short clause bank speeds up review considerably. Adapt the wording below rather than starting from a blank page:

For multi-tenant SaaS specifically, add language confirming logical data segregation between tenants and confirming that support staff access is logged and time-limited, since shared infrastructure raises questions a single-tenant tool never has to answer.

A compact checklist for vendor assessment covers: Article 28 minimums present, sub-processor list and notice period disclosed, transfer mechanism named, security evidence attached (SOC 2 or equivalent), breach notification window specified, and end-of-contract deletion terms with a certification requirement.

Common drafting mistakes and negotiation shortcuts

Scope creep is the most frequent problem: DPAs that describe processing so broadly (“any processing necessary to provide the Services”) that they’re functionally meaningless if a dispute ever arises. Unclear data ownership is the second, particularly around who owns derived or aggregated data.

Fast negotiation shortcuts worth using:

Pro Tip: If legal and security keep disagreeing on the same three clauses across every vendor review, that’s usually a sign your internal template needs updating, not that every vendor is unusually difficult.

Where privacy-first design already answers most DPA questions

A provider that never mines or sells usage data, and never trains models on customer content, starts most DPA conversations from a stronger position, because entire clauses about secondary use simply don’t apply. Seven was built around that principle from the outset, with security and compliance documentation covering the technical measures buyers typically request in Article 28 negotiations. Open data export, rather than a locked format vendors dole out reluctantly, also removes most of the friction around end-of-contract return obligations before it becomes a negotiation point at all.

Where teams get the trade-offs wrong

Most negotiation delays I’ve seen come down to legal and security chasing perfection on clauses that barely move risk, while ignoring the two or three that actually matter. Sub-processor notice periods, breach notification timing, and a genuinely usable export format at end-of-contract cover the bulk of real exposure. Everything else, definitions, formatting, minor liability wording, is negotiable in minutes if you stop treating it as equally urgent.

The bigger shift worth making is structural: push vendors toward self-service, version-controlled DPA pages instead of bespoke redlines for every deal. It sounds like a small operational choice, but it’s the difference between legal reviewing the same clauses fifty times a year and reviewing them once, properly, then trusting the version history. Buyers who insist on custom paper for every vendor usually end up with worse protection, not better, because reviewers get fatigued and start rubber-stamping.

— Greg

If you’re mapping vendors and deciding which ones deserve negotiation effort versus a quick self-service sign-off, it helps to work with tools that were built around data independence from day one rather than retrofitted after a compliance complaint. Seven gives teams flexible workspaces, task and subtask management, built-in messaging and file attachments, without mining usage data or selling analytics, and without locking your project data into a format you can’t get back out.

Seven

Pricing stays transparent at $5 for individuals and $9 per user for teams, with no hidden costs buried in a separate enterprise tier. Excel import means shifting existing project data across doesn’t require a migration project of its own, and open data export means end-of-contract return obligations are a non-issue rather than a negotiation point. If you’re assessing project management vendors against the DPA checklist above, start a trial and see how Seven handles the Article 28 conversation before you sign anything longer term.

Where to check the official wording yourself

Every clause discussed here traces back to primary sources worth bookmarking directly. The ICO’s contract guidance sets out the UK GDPR position on mandatory contents, while the full text of Article 28 covers processor obligations in detail. For cross-border transfers, the European Commission’s SCC decision is the authoritative source, and Gdpr offers a practical starting draft adapted from real vendor agreements. For the commercial side of SaaS contracts, the American Bar Association’s guidance on SaaS provisions is worth reading alongside whatever DPA template you adopt, since the two documents need to work together rather than in isolation.

Sources