8 DPA Clauses SaaS Teams Must Include to Pass Enterprise Review

A GDPR-compliant Data Processing Agreement built around Article 28's mandatory clauses is not optional for any SaaS company handling customer personal data. It needs a defined scope, all eight processor obligations, a measurable security annex, subprocessor rules and breach notification timing. Publish that DPA alongside a Trust Centre with SOC 2 or ISO 27001 evidence, and you remove the single biggest bottleneck in enterprise procurement.

TL;DR:

• SaaS companies handling personal data must have a GDPR-compliant DPA with clearly defined scope, security measures, subprocessor rules, and breach notification timings.
• The DPA should specify the processing purpose, duration, and the eight mandatory processor obligations, including confidentiality, security, and data return or deletion.
• Defaults for breach notification are 24 to 48 hours, with an operational runbook needed to meet these commitments effectively.
• A security annex with concrete technical measures and current certifications like SOC 2 or ISO 27001 is crucial to satisfy enterprise security reviews.
• Publishing an up-to-date subprocessor list and transfer matrix streamlines compliance, especially regarding cross-border data flows and international transfer mechanisms.

Table of Contents

• What is a DPA and when does your SaaS need one?
• Article 28 checklist: the mandatory clause set for SaaS
• Building the security annex: TOMs under Article 32
• Managing subprocessors and cross-border data transfers
• Breach notification: what the DPA has to promise
• How to implement your DPA in practice
• Trust signals that speed up enterprise procurement
• How Seven approaches DPA readiness
• The gap between a compliant DPA and a trusted one
• Get DPA-ready without the vendor lock-in headaches
• Sources
• FAQ

What is a DPA and when does your SaaS need one?

A Data Processing Agreement is the contract that governs how one party processes personal data on behalf of another. Under GDPR, the customer is almost always the controller (they decide why the data exists and what happens to it), and your SaaS is the processor (you handle it on their instructions). Article 28 makes a written DPA mandatory the moment a controller hands personal data to a processor for any kind of processing activity.

Most SaaS products trigger this without much thought. If a customer uploads a spreadsheet of employee names into your platform, invites team members by email, or stores client contact details in a CRM field, you're processing personal data on their behalf. That's enough to require a DPA, regardless of how small the dataset is or how briefly you store it.

Common scenarios that make a DPA non-negotiable:

• B2B customer data: any platform where users upload, sync or input personal data belonging to their own customers or employees.
• Third-party integrations: connecting to payment processors, email providers or analytics tools that also touch that personal data.
• Multi-tenant architecture: shared infrastructure across customers raises questions about logical separation that enterprise legal teams will ask about directly.
• Subcontracted processing: using a hosting provider, backup service or support tool that itself touches customer data.

Jurisdiction adds another layer. GDPR applies to any company processing the personal data of people in the EU, irrespective of where the SaaS company is incorporated. If you sell into the US market too, expect overlapping contractual asks: the Texas Data Privacy and Security Act imposes near-identical processor duties, including documented instructions and timely breach notification, and California's frameworks push in the same direction. A single, well-drafted DPA template that satisfies Article 28 will cover most of these overlapping demands with minor addenda rather than a rewrite.

Article 28 checklist: the mandatory clause set for SaaS

Every enterprise legal reviewer runs the same mental checklist against your DPA. Miss one item and the deal stalls in redline. Get it right the first time, and you turn a two-week legal review into a same-day signature.

1. Define subject matter, duration, nature and purpose

Article 28 requires the DPA to spell out exactly what's being processed, for how long, and why. Vague language here is the most common negotiation blocker: phrases like "as necessary to provide the service" give a processor open-ended authority that no competent enterprise legal team will accept. Instead, reference your actual product modules.

For example: "Seven processes account holder names, email addresses, task content and file attachments uploaded by the Controller for the purpose of providing project management functionality, for the duration of the subscription term plus a defined retention period following termination." That's specific enough to survive scrutiny and narrow enough to protect you from scope creep claims later.

2. The eight mandatory processor duties

Article 28 of the GDPR lists eight binding obligations. Every DPA needs language addressing each one:

1. Process only on documented instructions from the controller, including for international transfers, unless required by law.
2. Ensure confidentiality of anyone processing the data, typically through employment contracts or statutory confidentiality duties.
3. Implement Article 32 security measures appropriate to the risk, detailed in a security annex rather than left as boilerplate.
4. Respect subprocessor rules, either through specific prior authorisation for each new subprocessor or general authorisation with a right for the controller to object.
5. Assist with data subject rights, giving the controller the technical means to respond to access, deletion, portability and correction requests.
6. Assist with Articles 32 to 36 obligations, covering security, breach notification, impact assessments and prior consultation with regulators.
7. Delete or return all data at the end of the contract, including copies, unless law requires retention.
8. Make available information and cooperate with audits, demonstrating compliance to the controller or an appointed auditor.

Drafting notes matter here. For duty five, don't just promise "reasonable assistance"; state the mechanism (an admin panel, an export function, a support ticket SLA). For duty seven, name the exact window for deletion after termination rather than leaving it open-ended. For duty eight, define what "audit" means before someone else defines it for you.

3. Where negotiations actually happen

Legal teams rarely fight over the existence of these eight duties. They fight over the defaults sitting underneath them.

Pro Tip: Publish your standard DPA position on each of these five negotiation points before a prospect's legal team asks. A one-page "our standard terms" summary attached to the DPA cuts most back-and-forth to a single email thread instead of three rounds of redlines.

None of these defaults are arbitrary. They reflect what most SaaS vendors can realistically deliver operationally while still satisfying an enterprise buyer's risk appetite. Offering a 48-hour breach notification window, for instance, still leaves the controller comfortable margin against their own 72-hour regulatory deadline.

Building the security annex: TOMs under Article 32

Article 32 requires "appropriate technical and organisational measures", but that phrase alone is worthless in a contract. Enterprise reviewers read "appropriate measures" as a red flag for a company that hasn't actually documented its security posture. The fix is a standalone security annex with specific, measurable commitments.

At minimum, your annex should state:

• Encryption in transit: TLS 1.2 or higher for all data in motion, named explicitly rather than implied.
• Encryption at rest: AES-256 or an equivalent named standard for stored data.
• Access controls: role-based access control (RBAC) and multi-factor authentication (MFA) for all administrative and privileged accounts.
• Logging and audit trails: retention period for access logs and what events get logged.
• Backup and restore: backup frequency, geographic redundancy, and tested restore procedures.
• Vulnerability management: penetration testing cadence (annually is the common baseline) and patch management SLAs.
• Incident response: a named process with defined roles, not just a promise to "respond appropriately".

Practitioner guidance consistently lands on the same point: attach a security annex with concrete technical measures rather than relying on generic assurances, and back it with current evidence like SOC 2 or ISO 27001 reports.

The evidence gap that stalls deals: Enterprise security teams increasingly treat a current SOC 2 or ISO 27001 report as functionally equivalent to a full on-site audit for routine reviews. Vendors that can produce that evidence on demand skip weeks of back-and-forth that vendors relying on self-attestation alone cannot avoid.

The presentation matters almost as much as the content. A security annex published alongside a Trust Centre with report dates, scope statements and a subprocessor list turns your DPA from a static PDF into a living compliance resource a buyer's team can actually verify. Teams evaluating platform security for their own products often reach the same conclusion when reviewing file attachment security practices: specificity beats reassurance every time.

Managing subprocessors and cross-border data transfers

Two subprocessor models dominate SaaS contracts, and the choice shapes how much friction you create for yourself down the line.

Specific prior authorisation requires the controller to approve each named subprocessor individually before you can use them. It's thorough but operationally painful. Adding a new logging vendor means chasing sign-off from every customer before deployment.

General authorisation with an objection window lets you maintain a published subprocessor list and add new ones after giving notice, typically 30 days, during which the controller can object. This is the workable default for most SaaS vendors, and it's what most enterprise buyers will accept once they see your list is current and your notification process is reliable.

Either way, your DPA needs to specify:

• How and where the current subprocessor list is published (a static page or a Trust Centre entry, not a buried PDF).
• The notification method and window before a new subprocessor goes live.
• Flow-down obligations, meaning every subprocessor is bound by data protection terms at least as strict as your own DPA.
• What happens if a subprocessor itself suffers a breach; liability for a subprocessor's failure sits with you, not the subprocessor, in the eyes of the controller.

International transfers add a separate layer of complexity. If any subprocessor sits outside the EU/EEA without an adequacy decision covering that country, you need a lawful transfer mechanism. Standard Contractual Clauses remain the default mechanism the European Commission provides for this, and they must be properly incorporated, not just referenced in passing. The EU-US Data Privacy Framework offers an alternative route for transfers to certified US organisations, but it doesn't eliminate the need for a Transfer Impact Assessment: a documented review of the destination country's laws and any supplementary technical or contractual safeguards needed on top of the SCCs themselves.

A transfer matrix, mapping which subprocessor sits where and under which legal mechanism, is the single most useful document you can maintain here. It turns a question that used to take a lawyer two days to answer into something you can hand over in an email attachment. This overlaps directly with broader questions about data residency in SaaS architecture, since where your infrastructure physically sits determines which transfer mechanism you even need.

Breach notification: what the DPA has to promise

GDPR sets the regulatory clock running the moment a controller becomes aware of a breach: Article 33 requires notification to the supervisory authority within 72 hours. Your DPA's breach clause exists to make sure the controller finds out in time to hit that deadline, and that means your processor notification window has to be materially shorter than 72 hours.

Industry practice has converged on a 24 to 48 hour window for processor-to-controller notification, giving the controller enough runway to investigate, prepare their own regulatory filing and notify affected individuals if required.

Your breach clause should commit to providing:

• Initial notice within the agreed window, even if the investigation is incomplete, rather than waiting for full details.
• Nature of the breach, including categories and approximate number of affected data subjects and records.
• Containment steps taken and the current status of the incident.
• Root cause analysis, once available, distinguishing preliminary findings from a final report.
• Recommended controller actions, such as whether affected individuals need direct notification.

None of this works if the DPA clause exists disconnected from your actual operations. The notification window in your contract needs to match a runbook your engineering and security teams have actually rehearsed, complete with named on-call responsibilities and a template for the initial notice. A DPA promising 24-hour notification with no internal process behind it is a liability waiting to surface at the worst possible moment. Teams building out broader SaaS security checklists usually find breach response is where the gap between paper commitment and operational readiness shows up first.

How to implement your DPA in practice

A signed DPA is only the starting point. What turns it into something enterprise buyers trust is the operational scaffolding sitting behind it.

1. Attach a security annex with the measurable TOMs covered earlier, dated and version-controlled so updates don't require a full contract renegotiation.
2. Publish a subprocessor schedule listing every subprocessor, its role, and its location, updated whenever anything changes.
3. Build a transfer matrix mapping each subprocessor location to its legal transfer mechanism, whether that's an adequacy decision, SCCs, or the DPF.
4. Draft a retention and deletion schedule specifying exactly what happens to customer data at each stage of the relationship, including backups.
5. Define your audit protocol, stating what evidence you provide by default (SOC 2, ISO 27001, pen test summaries) and under what conditions a fuller audit applies.

On timing, set a data export window of 30 to 90 days post-termination before deletion, and document any backup retention carve-out separately (backups on rolling encrypted storage might not purge instantly, and saying so upfront avoids a compliance argument later). These numbers need to be defensible operationally, not just legally convenient. If your backup rotation is 45 days, don't promise 30-day deletion you can't technically deliver.

Pro Tip: Run a legal-to-engineering handover the moment your DPA template is finalised. Map every clause to a real system: who owns the access logs, who can pull an export, who gets paged on a breach. A DPA that legal signed off on but engineering never saw is the fastest way to break a promise you made in writing.

The handover checklist should cover: data flow mapping (what personal data moves where), access review cadence, logging configuration matching your stated retention periods, and current test evidence for anything you've claimed in the security annex. Review this quarterly, because commitments made a year ago about encryption standards or audit cadence age quickly as your stack evolves.

Trust signals that speed up enterprise procurement

Enterprise security reviews rarely stop at reading your DPA. They ask for evidence, and the fastest deals go to vendors who hand that evidence over before it's even requested.

The reports that matter most are a SOC 2 Type II report (showing controls operated effectively over a period, not just at a point in time) and an ISO 27001 certificate, if you hold one. A Trust Centre that centralises both, alongside your DPA, security annex, subprocessor list and recent penetration test summary, turns a security questionnaire that used to take two weeks into a same-day response.

• Keep report dates current; a SOC 2 report older than twelve months invites follow-up questions instead of answering them.
• Prepare reusable answers to the most common questionnaire fields (encryption, access control, breach history, subprocessor list) so your team isn't rewriting the same paragraph for every prospect.
• Treat legal completeness and technical evidence as one package. A perfect DPA paired with no security documentation, or vice versa, both stall review cycles roughly the same amount.

How Seven approaches DPA readiness

Privacy-first product design changes what a DPA actually needs to say. Seven doesn't mine user data, sell analytics, or train models on customer content, which narrows the processing purposes in the DPA to exactly what the platform does: task management, file storage, team messaging. Fewer processing purposes mean a shorter, cleaner scope clause and fewer places for a buyer's legal team to probe.

That same independence, no parent company harvesting data for other product lines, also simplifies the subprocessor conversation considerably.

The gap between a compliant DPA and a trusted one

Most DPA advice treats the document as a legal artefact to file away once signed. That's backwards. The DPA is a public commitment, and enterprise buyers now treat the gap between what a contract promises and what a security questionnaire reveals as the real signal of vendor maturity.

Where conventional guidance falls short is in separating legal drafting from operational proof. A beautifully worded breach clause promising 24-hour notification means nothing if nobody has rehearsed that response. A subprocessor authorisation clause is empty if the subprocessor list hasn't been updated in a year. The real work isn't writing the DPA, it's building the muscle memory that makes every clause true on the day it's tested.

If you're prioritising one thing first, make it the security annex. Vague TOMs language is the single most common reason deals stall in legal review, and it's the easiest thing to fix with specific, dated, evidenced commitments. Everything else in the negotiation gets easier once a buyer trusts that your technical claims are real.

— Greg

Get DPA-ready without the vendor lock-in headaches

Negotiating a DPA gets harder when the platform itself won't let you export your data cleanly or hides its security posture behind a sales call. Seven takes the opposite approach: transparent pricing, open data export, and no data mining or AI training on customer content, so the DPA you sign corresponds to typical platform operations.

That clarity matters when you're the one being asked to sign a DPA rather than draft one. Seven's security and compliance documentation is public, not gated behind a request form, and the platform offers monthly subscription plans for individuals and teams, with details available on the pricing page. Review the security docs, check the plan that fits your team, and start a trial to see whether the DPA terms match how the product actually behaves before you commit to anything.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• Article 28 GDPR text
• Texas Data Privacy and Security Act overview
• European Commission: standard contractual clauses (SCC) guidance
• SaaS compliance requirements and how companies meet them (Stripe resources)

FAQ

Is a DPA mandatory for SaaS companies?

Yes. Any SaaS company processing personal data on behalf of a customer under GDPR is legally required to have a signed DPA under Article 28, regardless of company size or data volume. This applies even to free trials if personal data changes hands during that period.

What are the core principles a DPA must reflect?

A GDPR-compliant DPA must reflect processing limited to documented instructions, confidentiality, appropriate security under Article 32, controlled subprocessor use, cooperation on data subject rights, assistance with breach and impact assessment obligations, deletion or return of data at contract end, and audit cooperation. These map directly to the eight duties set out in Article 28.

What must a DPA include at minimum?

At minimum, a DPA needs a defined subject matter, duration, nature and purpose of processing, the eight Article 28 processor obligations, a security annex mapped to Article 32, subprocessor rules, transfer mechanisms for any data leaving the EU/EEA, and clear breach notification timing. Most enterprise buyers also expect a data retention and deletion schedule attached as an annex.

Are there exemptions from DPA requirements?

There's no blanket exemption for small SaaS companies. Every processing relationship involving personal data under GDPR needs a DPA. Some non-EU frameworks, like the Texas Data Privacy and Security Act, apply only above certain revenue or data volume thresholds, but GDPR itself sets no such floor.

Recommended

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