What is a DPA agreement? The data processing agreement, the terms Article 28 requires, and a template to start from

What is a DPA agreement? It is a data processing agreement: the written contract GDPR Article 28 requires when a vendor, the processor, handles personal data for the company that decides why it is used, the controller. A small SaaS signs on both sides: with its business customers, and with the vendors under it, such as Supabase and OpenAI.

What is a DPA agreement, and what does DPA stand for

DPA stands for data processing agreement: the contract, or other binding legal act, that GDPR Article 28 requires whenever a processor handles personal data for a controller. It fixes what data, for what purpose, on whose documented instructions and under what security, and the rule has applied since 25 May 2018.

This page explains the document; it is not legal advice. It covers the EU GDPR, the UK GDPR’s matching Article 28 and, for US readers, two state laws, California’s and Virginia’s. The agreement is one piece of how to manage SaaS data compliance, next to the privacy policy, the data map and the vendor list.

In business, legal and contract use, the DPA meaning is this one, so what a data processing agreement is and what a DPA agreement is are the same question. A procurement email asking for the DPA doc, a vendor contract that refers to its DPA and a sign-up flow offering a DPA document all mean a data processing agreement. Data protection agreement and data privacy agreement are looser names for a DPA; the document and its terms stay the same.

The two roles come from the regulation’s definitions. The controller is whoever “determines the purposes and means of the processing of personal data”, alone or jointly with others, and the processor is whoever “processes personal data on behalf of the controller” (Article 4(7) and 4(8)). The split follows who decides, not who is bigger.

A small SaaS holds both roles at once, depending on whose data it is and whose purpose it serves. The table covers four relationships a small SaaS is likely to have. The “who usually supplies the DPA” column is my reading of how these deals tend to start, not a rule.

So part of a payment relationship falls under data sharing between controllers rather than under a DPA, which the data sharing section below covers. The law is Regulation (EU) 2016/679, Article 28 (the text of the GDPR on EUR-Lex), and the UK GDPR carries its own Article 28 with the same points (a) to (h), set under domestic law.

What does a DPA do: the processor works only on your instructions

A DPA binds the processor to act only on the controller’s documented instructions, keep the data confidential and secure, and delete or return it at the end, at the controller’s choice. Its purpose is the controller’s own duty: Article 28(1) requires a controller to use only processors providing sufficient guarantees, and the DPA is where those guarantees are written.

Put plainly, the agreement turns a vendor’s promises into terms the controller can enforce and can show a regulator. That is my reading of what it is for, not a line from the regulation.

Take a small HR app. A customer’s staff records sit in it, so what the app may do with them is whatever that customer’s documented instructions allow. Reusing those records to build a feature of your own steps outside those instructions.

Data processing addendum or agreement: the same document

A data processing addendum is a data processing agreement attached to a main contract or terms of service instead of standing alone. Article 28 asks the same eight terms of both forms. Stripe’s, for example, states that it is incorporated by reference into Stripe’s main agreement.

Stripe’s wording is that its DPA “is subject to and incorporated by reference into the Agreement”, and its definitions point “Agreement” to the Stripe services agreement between the business and Stripe. When a vendor’s addendum works that way, there may be nothing separate to sign: accepting the main terms brought the DPA with them. Which word a vendor picks is a drafting choice, and the content Article 28(3) asks for does not change with the name.

The data protection authority (DPA): the other meaning, and which one is yours

A data protection authority is the other DPA: the independent authority GDPR calls a supervisory authority. A company’s lead authority for cross-border processing is the one where its main EU establishment is; the UK’s is the Information Commission, which publishes as the ICO. A controller reports a qualifying breach without undue delay and, where feasible, within 72 hours.

A breach qualifies unless it “is unlikely to result in a risk to the rights and freedoms of natural persons” (Article 33(1)), and a processor tells its controller “without undue delay after becoming aware” of one (Article 33(2)). The lead authority is the one of the controller’s “main establishment or of the single establishment” (Article 56(1)). A company with no establishment in the EEA gets no lead: the EDPB’s guidelines say such controllers “must deal with local supervisory authorities in every Member State they are active in, through their local representative”. The EDPB’s list of national data protection authorities gives each one’s contact details. In the UK GDPR’s current Article 33, the breach goes to “the Commission”, meaning the Information Commission, the wording in force since 30 September 2026.

The two meanings meet in one document. Point (f) of a DPA has the processor assist the controller with its obligations under Articles 32 to 36, “taking into account the nature of processing and the information available to the processor”, and breach notification sits inside that range at Article 33. So, as I read it, the processor’s help with a report to the authority is written into the agreement. Deciding what GDPR makes you report after a personal data breach, and to whom, is its own job.

Outside data protection the letters mean other things: the UK’s Data Protection Act 2018, a deferred prosecution agreement in court reporting, the Defense Production Act in US news, and assorted finance and healthcare terms. None of them is this contract.

Why it matters for a small SaaS: when is a DPA required

A DPA is required under GDPR Article 28 whenever a processor handles personal data of people GDPR covers on a controller’s behalf, and Article 28 sets no size threshold. It is not required when no personal data moves, or when the other side decides its own purposes as a controller.

The legal hook is Article 28(3): processing by a processor “shall be governed by a contract or other legal act”. GDPR also reaches a company outside the EU that offers goods or services to people in the EU, “irrespective of whether a payment of the data subject is required” (Article 3(2)). The size exemption in Article 30(5), for an organization “employing fewer than 250 persons”, covers records of processing activities, not contracts. Whether GDPR reaches your app at all comes before any of this, and what GDPR asks of a small SaaS, in order starts there.

US state laws ask for a comparable contract under their own terms. California’s CCPA regulations, effective January 1, 2026, open section 7051 with “The contract required by the CCPA for service providers and contractors shall:” and then list its terms, starting with a ban on selling or sharing the personal information (California’s privacy regulations). Virginia’s Consumer Data Protection Act says “A contract between a controller and a processor shall govern the processor’s data processing procedures”, and the contract must set out instructions, the nature and purpose of processing, the type of data, the duration and both parties’ rights and obligations (Virginia’s processor-contract section). Each is a contract with listed terms under its own statute, not a GDPR DPA.

When a DPA is needed is a question about roles, so the situations below sort by what happens to the data. The “who usually moves first” column is my reading.

A fresh DPA is not necessary when a vendor adds a sub-processor: the existing agreement’s point (d) already governs the change. DPA compliance, in practice, means the agreements exist, they match what the app actually does, and you can find them when someone asks. It is not a certificate.

What happens without one is set by Article 83(4)(a): breaches of a controller’s or processor’s obligations under “Articles 8, 11, 25 to 39 and 42 and 43”, which take in Article 28, sit in the tier of fines “up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher”. The UK GDPR’s current Article 83(4)(a) names the same Articles, with “up to £8,700,000” in place of the euro figure and the same turnover test. That is the ceiling of the tier, not a forecast of any fine.

If a customer has already sent you theirs, start with when a customer wants you to sign a DPA, which goes through it clause by clause.

How it works: what goes into a DPA, and where its text comes from

Article 28(3) lists 8 terms every DPA must stipulate: process only on documented instructions, bind staff to confidentiality, take the Article 32 security measures, use sub-processors only as allowed, help with data subject requests, help with security, breaches and impact assessments, delete or return the data at the end, and allow audits.

What each of those means for a working app is set out in the eight Article 28 terms, one by one, for an app.

Before the lettered terms, Article 28(3) has the agreement set out “the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller”. Those header facts are the part a template cannot fill for you.

A DPA may also add terms of its own, such as a liability cap or a breach-notice deadline counted in hours. Neither appears among Article 28(3)‘s points (a) to (h), so when a draft carries one, that number came from the parties, not the regulation. Transfer clauses are different: point (a) already covers instructions “with regard to transfers of personal data to a third country or an international organisation”, so a transfer section extends a listed term rather than adding a new one. Both readings are mine.

The DPA template: the clauses, the annexes, and where the free official one lives

The free official DPA template is the European Commission’s standard contractual clauses for controllers and processors, adopted on 4 June 2021. Its annexes ask for the list of parties, a description of the processing, the technical and organizational measures, and the list of sub-processors: facts about your app, not legal text.

The clauses come from Commission Implementing Decision (EU) 2021/915, made under Article 28(7), and the European Commission’s standard contractual clauses for controllers and processors page also offers an editable Word version, dated 25 May 2022. Using them is optional: Article 28(6) lets the contract be based on standard clauses “in whole or in part”, and it leaves an individual contract open.

If you do use them, Clause 2 limits the edits. The parties “undertake not to modify the Clauses, except for adding information to the Annexes or updating information in them”, though they may put the clauses inside a broader contract or add other clauses “provided that they do not directly or indirectly contradict the Clauses or detract from the fundamental rights or freedoms of data subjects”. For the UK, the ICO’s guidance on what a processor contract must include lists the details and terms the UK GDPR’s Article 28(3) asks for. On 3 October 2026 that page carried the notice “Due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change.”

The outline below follows the Commission’s clause headings and annex titles, with what each annex needs from you.

DATA PROCESSING AGREEMENT, OUTLINE
(Commission standard contractual clauses for controllers and processors)

SECTION I
  Clause 1   Purpose and scope
  Clause 2   Invariability of the Clauses
  Clause 3   Interpretation
  Clause 4   Hierarchy
  Clause 5   Docking clause (optional)

SECTION II  OBLIGATIONS OF THE PARTIES
  Clause 6   Description of processing(s)
  Clause 7   Obligations of the Parties
             7.1 Instructions
             7.2 Purpose limitation
             7.3 Duration of the processing of personal data
             7.4 Security of processing
             7.5 Sensitive data
             7.6 Documentation and compliance
             7.7 Use of sub-processors
             7.8 International transfers
  Clause 8   Assistance to the controller
  Clause 9   Notification of personal data breach

SECTION III  FINAL PROVISIONS
  Clause 10  Non-compliance with the Clauses and termination

ANNEX I    List of parties
           needs: each controller and processor, address, contact person, signature date
ANNEX II   Description of the processing
           needs: categories of data subjects, categories of personal data,
                  sensitive data, nature, purposes, duration (from your data map)
ANNEX III  Technical and organisational measures
           needs: each measure the app really has, described concretely
ANNEX IV   List of sub-processors
           needs: name, address, contact, what each one processes (from your vendor list)

Annex II is only as good as a GDPR data map of what the app stores and sends. The controls listed in Annex III should exist, of the kind the MVSP security controls checklist sets out. The vendor list that fills Annex IV is the subject of the next section.

The security annex is where a template does the most harm. A founder fills it from a template’s stock list of measures without opening the app; later the customer uses the audit term, which has the processor make available “all information necessary to demonstrate compliance”, and asks for the evidence behind one listed measure that the app does not have. Every line of the security annex is a statement about the app that the customer can ask to see, and the clauses’ own note says the measures “need to be described concretely and not in a generic manner”. The lesson I take from the case: fill the security annex from what the app does today, then test it with check 5 further down.

On the vendor side, a DPA form can be a generator rather than a PDF. PostHog’s DPA page says you generate a countersigned DPA inside your PostHog organization, self-serve, on “Any plan, including the free one”; the agreement is “effective the moment you do”, that is, the moment you sign. Whichever DPA template you start from, the Commission’s or a data processing agreement template from a contract site, have a lawyer read the final text before a customer relies on it.

Vendor DPA: the ones you accept from your own processors

A vendor DPA is the agreement you hold with each of your own processors: the database and host, sign-in, payments, email, analytics, error tracking, the AI builder and the model provider. Vendors publish their own, and the ways to get one differ, from terms you already accepted to a copy you generate in the vendor’s dashboard.

Every vendor that processes personal data on your behalf needs one on file: under Article 28(3) for your own users’ data, and under Article 28(4) when the data is a customer’s and the vendor is your sub-processor. In the table, “personal data it usually sees” is my reading and “the line to read” is my rule; no column says how a DPA is signed, because that differs by vendor and plan.

Worked examples sit in their own articles: Supabase’s DPA, region and subprocessor list, what Lovable’s compliance documents cover, what Replit’s SOC 2 report and DPA cover, and for the model side, what each model vendor offers on data retention. Save each DPA’s PDF or URL with the date you accepted it. When a customer asks for your vendor list, that folder is the start of it, and the definition of what a sub-processor is decides who belongs on it.

Data sharing agreement: when both sides are controllers

A data sharing agreement is the document for when both sides decide their own purposes as controllers. Article 28 does not apply to that exchange, Article 26 applies if they decide the purposes and means jointly, and the ICO’s data sharing code recommends an agreement recording what is shared, why, each side’s lawful basis and who answers people’s requests.

Stripe’s data processing agreement is the everyday case: for its fraud and legal-compliance processing, Stripe acts as a Data Controller with “the sole and exclusive authority to determine the purposes and means” of that processing, so that part sits outside Article 28. Joint controllers need “an arrangement between them” under Article 26(1), “unless, and in so far as” law already sets their responsibilities. For separate controllers, the ICO’s data sharing code calls an agreement good practice, “although it is not mandatory”. That code is the nearest thing to a GDPR data sharing agreement template: it lists the questions such an agreement should answer, from the purpose and the types of data shared to the lawful basis and individual rights.

How to check your own app against what a DPA promises

Checking your app against a DPA means testing each promise the agreement makes against what the app does: one user traced through every store, a DPA on file for each vendor, the fields sent to model providers, a working export and delete, the security annex against real settings, and someone who would notice a breach.

The reason to test rather than trust the paperwork: in my June and July 2026 audits, at least 5 of the 21 third-party apps exposed PII or PHI. They were a selected set of apps, not a random sample, so the count is no rate for AI-built apps in general. A security annex describes measures; only the app shows whether they hold.

1. 01 Annex II: follow one test user through the database, the logs and every vendor, and compare what you find with the annex's description of the processing.
2. 02 Annex IV: list the vendors that process customer data, and check that list against your provider inventory and your privacy policy.
3. 03 Model providers: for each call to a model, write down the fields sent and compare them with your data inventory.
4. 04 Terms (e) and (g): run an export and a delete for a seeded test user, check that nothing is missed and that another user cannot trigger either one, and write down anything kept with its reason.
5. 05 Annex III: for each measure the annex lists, point to its owner, the setting that implements it, or a test that proves it.
6. 06 Term (f): confirm that someone would see a breach and could tell the customer without undue delay, or sooner if the contract sets an hour count.

Keep each result with its date. Check 6 is the processor’s Article 33(2) duty from the authority section above. When check 3 turns up fields the model never needed, the next step is how to redact personal data before LLM calls. When check 4 misses a store, work through the data subject request handling checklist.

The Production Hardening Sprint verifies five related deliverables this way: 12.1, “Trace a sample user through storage, logs, and providers and compare it with the inventory”; 12.8, “Confirm the list matches the provider inventory and the privacy policy”; 12.7, “Trace each model call, list the fields sent, and match them against the inventory”; 12.2, “Export and delete a seeded user’s data; verify completeness, authorization, and recorded exceptions”; and 12.6, “Link each documented control to its owner, configuration, or test evidence. This deliverable is not a SOC 2 audit report.”

Where the sprint fits

Legal advice and certification are separate services; the sprint implements and documents the technical data-handling controls, so the agreement’s wording and the decision to sign stay with you and your lawyer. Five deliverables in the same privacy area apply here: 12.1 documents what personal data is stored, where it lives, why it is collected, and who can access it; 12.2 implements authenticated export and deletion workflows covering related systems and documented retention exceptions; 12.6 delivers a technical controls checklist with supporting evidence organized for enterprise security review; 12.7 inventories the user data that reaches AI providers, redacts what is not needed, and records each provider’s data-processing terms; and 12.8 publishes the list of vendors that process customer data, with the agreement in place for each. Each one is listed with its verify line among the privacy deliverables in the published scope.

Common questions about DPA agreements

Is a DPA mandatory?

Yes, under GDPR, whenever a processor handles personal data on a controller’s behalf: Article 28(3) requires a binding contract or other legal act for that processing. Company size does not change that. The under-250 exemption in Article 30(5) applies to keeping records of processing activities, and it leaves the contract duty untouched.

Is a DPA required in the US?

Yes, under some state laws, though the requirement is a state contract rule rather than GDPR. California’s CCPA regulations list the terms a contract with a service provider or contractor must hold, and Virginia’s Consumer Data Protection Act requires a binding contract between a controller and a processor. GDPR can still apply to a US company that offers its service to people in the EU.

Does a DPA have to be signed?

Not necessarily: Article 28(9) asks for the agreement “in writing, including in electronic form”. Some vendor DPAs bind you through terms you accepted online, as Stripe’s does by being incorporated into its main agreement, while PostHog’s copy, generated in the app, takes effect when you sign it.

Who needs a DPA?

Every controller that uses a processor needs one, and so does every processor that brings in a sub-processor, which must take on the same data protection obligations under Article 28(4). For a small SaaS that usually means one with each business customer whose people’s data the app holds, and one with each vendor that processes personal data for it.

What are the 7 DPA principles?

They are the seven data protection principles in Article 5 of the UK GDPR, as the ICO lists them: lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality (security); and accountability. The UK’s Data Protection Act 2018 sits beside them, and its first section says “Part 2 supplements the UK GDPR”. A data processing agreement is a different thing: it has eight required terms, not seven principles.