A Customer Wants You to Sign a DPA: What Your SaaS Is Agreeing To

A data processing agreement is a contract between a business customer and the company whose app holds their people’s data, and one of them has just landed in your inbox with a signature block at the bottom. The letters also belong to three other things: the data protection authority that enforces the law, the power of attorney that keeps working after you cannot sign for yourself, and the prosecution deal that defers a criminal charge. None of those is what your customer sent.

What did arrive is a deal blocker. Somebody in procurement or legal has attached a document to a purchase that was otherwise going through, and they are waiting on a signature. You can read the thing. What you cannot answer, without going and looking, are the two questions it turns on: which of the companies behind your app belong on the list it wants attached, and what you are taking on once your name is at the bottom.

A customer’s data processing agreement is the document that names them the controller and you the processor for the personal data their people put in your app. Article 28 of the regulation lists eight terms such a contract must stipulate. The hardest is the one about your own vendors.

Every fact below comes from a document anyone can open: the text of the regulation itself, three pages of the UK regulator’s own guidance on processor contracts, and the pages on which named companies publish their own agreements and their own vendor lists. Each one was pulled down twice on 3 September 2026, plainly and then with the headers a browser sends, read end to end with its navigation attached, and dated wherever it is quoted. AxonBuild drafted no agreement here, signed none, read nobody’s paperwork on their behalf and negotiated no clause. This page gives no legal advice and decides nothing about whether your app, or the agreement in front of you, satisfies the law.

For most owners this document does not arrive alone. It turns up inside a longer set of things one large buyer wants settled before it signs anything, and the other items on that list have their own answers.

What is a customer’s data processing agreement, and which side of it are you on?

The agreement fixes which of two roles you hold. The regulation’s definitions, as the ICO sets them out, put your customer in the controller role because they decide why their people’s data is in your product, and you in the processor role because you run it on their instruction.

The split is by who is deciding rather than by who is bigger. The ICO’s page on when a contract is needed, read on 3 September 2026, sets out the regulation’s definitions: the controller is whoever settles the purposes and the means, alone or with others, and the processor is whoever handles the data for them. Your customer decides why their staff and their own customers are in your product. You run the product. That is the split the paperwork is drawing.

Most subscription businesses end up on both sides of it at once. For the records your customer’s people create inside your app you are usually the processor. For your own billing records, your support inbox and your marketing list you are usually the controller, because nobody instructed you to keep those. The same company, two hats, and the agreement in front of you only covers one of them.

The same ICO page says plainly when a contract is required, and its reading is more useful than the article text on its own: every time a controller uses a processor to process personal data, there has to be a written contract binding that processor to that controller for its processing activities. It adds a nuance that saves argument in a chain: Article 28(3) can be met not only by a direct contract between the two of you but by other legally binding arrangements, such as a set of contracts between several parties, provided the processor is ultimately bound to each controller.

Two details on that page save arguments later. The first is what counts as an instruction: the ICO’s page on what needs to be included in the contract, read the same day, says an instruction “can be documented by using any written form, including email” and that it “must be capable of being saved, so that there is a record of the instruction”. An email from your customer asking you to purge a test account is an instruction. A phone call is not, until somebody writes it down.

The second is what happens if you stop following them. The same ICO page says that if a processor acts outside the controller’s instructions in such a way that it decides the purpose and means of processing, “it will be considered to be a controller in respect of that processing and will have the same liability as a controller”. Article 28(10) of the regulation says the same thing in one line. Reusing a customer’s data to train something of your own, or to build a feature nobody asked for, is the ordinary way a small product walks into that.

One thing to carry into every ICO sentence below. All three of the regulator’s contracts pages cited here were re-read on 3 September 2026, and each one carries a notice reading “Due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change”. The regulator’s words below are its words as they stood that day.

The agreement is one of several duties that land on a small subscription business at once, and the order they arrive in is a separate subject.

The list you cannot write from a diagram you do not have

The obvious way to build the list is to open the architecture diagram and count the services that touch personal data. That assumes you drew the diagram, chose the services one at a time, and can read the code that calls them. If your product came out of an AI builder, none of those is true. The services underneath it arrived as a set, most of them before you had a single paying customer, and several of them because a template called them.

So the list gets rebuilt from evidence you already have rather than from memory. Three sources, in the order they are usually worth reading.

The first is the platform’s own published list. Where a builder publishes the names of the companies it uses underneath, that page is the fastest way to learn what sits under your own app, and Article 28(2)‘s authorisation duty, set out further down, is the reason so many of them publish one. It also tends to be longer than founders expect, because it includes the logging and support vendors nobody thinks of as part of a product. The platform an app is built and hosted on usually publishes its own vendor list, its own agreement and its own attestation on separate pages, and reading them in that order changes what each one means.

The second is the set of accounts your app actually authenticates against. Every outbound call your product makes at runtime carries a key that belongs to some account somewhere. The keys are the inventory. An account that exists but is never called does not belong on the list; a key sitting in an environment variable and firing on every signup does.

Third comes the agreement the builder itself asked you to accept. It names its own role, and in some cases it attaches its list of vendors to the contract as a numbered exhibit, which means the names you inherited are already written into a document you agreed to.

None of the three tells you where the personal data goes inside your own code. That part is a job of reading the code, and it is the one this page keeps coming back to.

When the same request arrives as a spreadsheet from procurement rather than as a contract from legal, the row asking for that list is one line on a longer form with its own rhythm, and it is worth reading about before the file lands.

How do you tell whether a vendor belongs on the list?

The test in the ICO’s guidance is whether a company processes personal data on your behalf, under your instructions, as part of what you provide to your customer. The regulator also notes that the shorthand word for such a company is not a term the regulation itself defines, so the relationship decides.

Start with the regulator’s own caveat. The ICO’s page on when a contract is needed says that a processor might use the services of another processor, and adds: “For shorthand, this is sometimes referred to as using a ‘sub-processor’, although this is not a term taken from the UK GDPR itself.” The shorthand is convenient and, on the regulator’s own page, it is not the test. What the regulation defines is the relationship, and the relationship is what the test has to follow.

Three ordinary cases fall out of it without much argument.

A company that stores, moves or reads the personal data your customer put into your app, because your app told it to, is processing on your behalf. Where the rows live, what serves the pages, what puts a password reset in somebody’s inbox, what records that a person clicked something: in each case a real person’s details are being handled because your code asked for it, not because that company chose to.

A company your customer pays directly is not yours to list. If they connect their own account for something and the data flows there under their contract, that is their arrangement, not a vendor sitting underneath you.

Tools that only ever see your code give a different answer from tools that see your data. An editor, a repository, an issue tracker and a coding assistant reading a file are working on the source rather than on the customer’s records. The moment one of them is pointed at a production database, an export or a log file full of real rows, the answer changes, and it changes because of what was handed over rather than because of what the tool is called.

That distinction is where most of the honest disagreement lives, and it is worth writing down which side you put each tool on and why, because the next person who asks will not be your customer’s lawyer. It will be the person who inherits the accounts.

What the model vendor behind an app’s AI features keeps, and for how long, is the one entry on the list that comes with its own set of switches.

What does Article 28 actually put in the agreement?

Article 28(3) fixes both the description and the terms. The contract has to record, under that same paragraph, the subject matter and duration, the nature and purpose, the type of personal data and the categories of people, and the controller’s obligations and rights. It then stipulates eight specific terms, which the ICO groups under eight names of its own.

Take the description first, because it is the half founders skip. Article 28 of Regulation (EU) 2016/679, read on 3 September 2026, says at paragraph (3) that the contract must 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. In a customer’s template these usually sit in an annex at the back with blank lines in it, and the blanks are yours to fill. Writing “customer data” in every box is where the trouble starts, because the deletion clause and the assistance clause both point back at whatever you wrote there.

Then the eight terms. The regulation lists them as points (a) to (h) of Article 28(3); the ICO’s page on what needs to be included names the same eight in plainer words and adds: “These are the minimum required, but the controller and processor may agree to supplement them with their own terms.”

Two of those come with published nuance worth knowing before you sign a version of them.

On deletion, the ICO’s page says it “appreciate[s] the practical reality that it may not be possible for data in backups or archives to be deleted immediately on termination of a contract”, and that where appropriate safeguards are in place, such as the data being put immediately beyond use, deletion on the processor’s next deletion cycle may be acceptable. That is the regulator’s wording about what may be acceptable, not a promise your own agreement makes for you.

On audits, the same page says the contract must require the processor to provide all the information needed to show Article 28 has been met, and to “allow for, and contribute to, audits and inspections” carried out by the controller or an auditor it appoints. The regulation’s point (h) uses the same words. Read that clause and then ask who at your company would answer the questions.

One more line sits just after point (h) in the regulation itself: the processor “shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation”. It is a duty to speak up, and it is easy to miss because it sits outside the lettered list.

What does the agreement keep asking of you after you sign it?

The vendor clause does not settle at signature. Article 28(2) requires prior written authorisation before you add another processor, and under a general authorisation it requires you to tell the customer about intended additions or replacements and give them the chance to object. Article 28(4) then keeps the liability with you.

Article 28(2) of the regulation says the processor “shall not engage another processor without prior specific or general written authorisation of the controller”. Specific authorisation means the customer approves each name. General authorisation means they approve the arrangement and you keep them informed: in the regulation’s own words, under a general authorisation the processor “shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes”.

Note what is not in that sentence. Neither Article 28(2) nor the ICO’s page on what needs to be included states a number of days for that notice, checked in both texts on 3 September 2026. Vendors and privacy sellers quote notice periods as though the law set one, and it did not. Any period in the document in front of you is that document’s own term, put there by whoever drafted it, and it is a term rather than a rule.

Down the chain, on the regulator’s own reading, the wording does not have to match. The ICO’s page says the subprocessor’s obligations “do not need to exactly mirror those set out in the contract between the controller and the processor, but should offer an equivalent level of protection”. The bar it sets is equivalence rather than identical drafting.

If you are a processor and use a sub-processor to carry out processing on your behalf, you will be fully liable to the controller for the sub-processor’s compliance with its data protection obligations.

That sentence is the ICO’s own, from its page on the responsibilities and liabilities processors have in their own right, read on 3 September 2026. The same page adds the mechanism: under Article 82(5), if a subprocessor is at fault the controller may claim compensation back from you, and you may then claim back from the subprocessor. Article 28(4) of the regulation puts it in the negative and gets to the same place, saying that where the other processor fails to fulfil its obligations, “the initial processor shall remain fully liable to the controller for the performance of that other processor’s obligations”.

Read those two together and the vendor list stops being paperwork. Every name on it is a company whose failure your customer can bring to you first. That is the reason the reconstruction job earlier on this page is worth doing properly rather than from memory.

A vendor can publish its own route for this. What one named host puts in writing about telling customers that a name on its list has changed, including the address to subscribe at and the window to object in, is read out on the page that goes through that host’s own documents. Those specifics belong to that vendor’s agreement rather than to the regulation, which is exactly the distinction this section is drawing.

What the builders and model vendors publish, and what that leaves you to write

Published vendor lists come in a few shapes, and the shape decides how much work is left for you. Three of them, each read on 3 September 2026 from the company’s own page.

The first shape is a list printed inline. OpenAI’s sub-processor list, headed “Last updated: July 9, 2026”, opens by saying that “OpenAI engages the following entities to provide processing activities for Customer Data (as defined in the OpenAI Data Processing Agreement)”, and then prints a table with four columns: entity name, OpenAI product or service, location of processing, and purpose of processing. Under the table it offers a form to “Subscribe to new Sub-processor notifications” and names a privacy address for questions. That is Article 28(2)‘s notification mechanism as a working feature rather than a clause. The page also footnotes conditions on individual rows, including entries that apply only at the customer’s election and one that applies except where zero data retention is used, which is a reminder that a name on a list can be conditional on a setting.

The second shape attaches the list to the agreement. Base44’s subprocessor exhibit, headed “Sub-processors List”, states that the addendum it belongs to is part of the terms of service governing the platform, and names each entity with a country in brackets and a one-line purpose. The names themselves, the count and the difference between that exhibit and the trust centre are set out in what one builder’s own agreement and its list of names actually contain, and are not repeated here.

A third shape is the one you cannot read from outside. As of 3 September 2026, Anthropic’s subprocessor list does not render to an automated read: anthropic.com/legal/subprocessors and anthropic.com/legal/subprocessors-list each returned 404 to both request shapes, and trust.anthropic.com answered both with a page whose content never loaded. That is a statement about what those reads returned that day, not about what the company publishes; the route in that case is to ask the vendor directly.

When the builder under your app is the one being asked about, what it publishes about its own vendors and which plan a signed agreement sits behind is a longer read of one company’s pages.

Where the database under the app is one named platform, its own agreement, its own list of names and the regions it offers are answered on their own page.

Whatever shape your own suppliers use, the outcome is the same: their names end up on the list you attach to your customer’s agreement, and their conditions end up as your conditions.

What to check in your own app before you promise any of it

The clauses describe behaviour. Your app either has that behaviour or it does not, and four of the eight terms in the table above are only as true as the code underneath them. Each of the four is settled elsewhere, and none of them is settled here.

The delete route is where this usually comes apart, because one written early rarely reaches the copies made later. The question to settle is whether a deletion request actually reaches every copy of the person asking.

Retention assumes a number exists. Point (g) and the annex both assume somebody decided how long the data stays, which makes the retention period somebody has to have written down a precondition rather than a detail.

The assistance clause assumes an export is possible. Before agreeing to help with rights requests, it is worth knowing what an export has to be able to produce and whether your app can produce it.

The incident route assumes a person. Article 28(3)(f) points at Articles 32 to 36, and the ICO names breach notification among what the processor has to assist with. Assistance needs somebody reachable and a way to tell what happened, which is a logging question before it is a legal one.

AxonBuild drafts, reviews, negotiates and signs no data processing agreements, and it is not a privacy lawyer, a compliance consultant, an auditor or a seller of compliance software. It is not weighed as an option anywhere above either. What it does is change AI-built products that are already running: tracing a fault to the code, fixing it, or adding what a customer’s requirements turn out to need in the app itself, such as the logging or the access control named above.

Common questions about signing a customer’s DPA

Is a DPA the same as an NDA?

No. A non-disclosure agreement is about keeping information confidential between the parties. A data processing agreement is about personal data belonging to other people, and Article 28(3) fixes what it has to contain: the description of the processing plus eight stipulated terms, including deletion at the end and the conditions for using another processor. A data sharing agreement is a third thing again, used where two parties each decide their own purposes rather than one instructing the other. The three often arrive stapled together in the same envelope.

What should be included in a DPA?

Article 28(3) of the regulation sets out both halves. The contract records the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of people involved, and the controller’s obligations and rights. It then stipulates eight terms, which the ICO names as documented instructions, duty of confidence, security measures, using subprocessors, data subjects’ rights, assisting the controller, end-of-contract provisions, and audits and inspections. The ICO adds that these are the minimum and that the parties may supplement them.

Do I have to accept the customer’s version of the agreement?

Nothing in Article 28 or in the ICO’s contracts guidance, both read on 3 September 2026, says whose paper the contract has to be on. What both fix is content rather than authorship: the description of the processing and the eight stipulated terms. Article 28(6) to (8) allow the contract to be based in whole or in part on standard contractual clauses, and the ICO’s page notes that the Danish Data Protection Agency has adopted clauses approved by the EDPB and that using them without amendment “should comply with the requirements in Article 28”. Whether to sign what is in front of you is a question for your own adviser, not for this page.

Who in a small company can sign one of these?

The ICO’s page on when a contract is needed says the controller and processor must be party to the contract, and that in subprocessing arrangements the parties are the processor and the subprocessor. For an organisation without separate legal personality it points at the document that governs how the organisation is managed and how contracts may be entered into on its behalf. Article 28(9) adds only that the contract “shall be in writing, including in electronic form”, so an electronic signature is a form the regulation contemplates.

Does the AI builder my app runs on count as a subprocessor?

The test is the same one the ICO applies to any vendor: is it processing personal data on your behalf, under your instructions, as part of what you provide to your customer. A builder that hosts the running app and its database is doing exactly that; a builder used only to generate code that you then deploy somewhere else is a different case. The builder’s own agreement usually states which role it takes, and reading that document is faster than reasoning about it from outside.

Do I need a separate agreement with every vendor my app calls?

Article 28(4) says that where a processor engages another processor, the same data protection obligations set out in the main contract have to be imposed on that other processor by contract or other legal act. The ICO reads that as meaning every time a processor uses another processor there must be a written contract between them, though it also notes the wording need not exactly mirror the original as long as it offers an equivalent level of protection. The vendors whose own pages are read further up this page each publish standard terms of their own, which is why the accounts inventory earlier on this page matters more than the drafting.

What happens when I add a new vendor after the agreement is signed?

That depends on which authorisation your agreement uses. Under specific authorisation, Article 28(2) requires the customer’s prior written approval of the new name. Under general authorisation, the same paragraph asks instead that the customer be told about an intended addition or swap and be given the chance to object to it. Neither the regulation nor the ICO’s guidance sets a notice period; any period in your agreement is a term of that agreement. The practical version is to keep the list somewhere it can be updated and to have a way of telling customers when it changes.

Is a business associate agreement the same thing under a different name?

No. A business associate agreement belongs to the United States health-privacy regime and is signed in a different set of circumstances, with different terms and a different regulator. If health records are involved, the health-data agreement is a different document under a different regime and the question of which platforms will sign one is answered separately.