Data Processing Agreement (DPA)

Scope of this page

A SUMMARY, NOT THE AGREEMENT

This page describes our position so that a reviewer can read it before a call. It is not the contract, and nothing on it varies a contract you have already signed with us. Ask for the document itself and we will send it, or work from yours. Whether a particular arrangement makes anyone a controller or a processor is a question for your counsel and your data protection officer, on the facts of that arrangement.

The short version

We sign your DPA in the ordinary case.

Your legal team has already approved your own paper, and arguing about whose template wins adds weeks to a procurement process without improving anybody's protection. If you have a standard agreement, send it.
We read it before signing.

Where a clause commits us to a control we do not operate, or to a certification we do not hold, we say so and propose language that describes what we actually do. A signed obligation we cannot meet is worse for you than a negotiated one we can — it converts a known gap into an unknown one, discovered during an incident.
We sign before any personal data reaches us,

not after the first export has already landed in somebody's inbox. In practice this means the agreement is in place before credentials are issued, and that access and the agreement are managed as one step rather than two.
In most engagements we are not a processor at all.

The systems we build run in your cloud accounts, against your data stores, under your contracts with your cloud and model providers. We write the code and hand over the keys; the personal data never enters our systems. That is the arrangement we recommend, and it is also the one that leaves you with the least to explain in your records of processing. The GDPR page covers how that shapes the design.

When a dpa is actually needed

Compare your options

Reviewed September 2026. The shape of the engagement decides this, not a policy preference — which is why it is settled in week one rather than at contract signature.
Criterion	Controller	Processing done by	DPA with us
A system we build that runs in your cloud accounts	You	Your cloud and model providers, contracted by you	Not required — the data never reaches us
Discovery, design and architecture work	You	Nobody, where we work from schemas and synthetic samples	Not required, and we design the engagement to keep it that way
A debugging window against production data	You	Us, for the length of the window	Yes, signed before credentials are issued
An evaluation set built from real records	You	Us, for the life of the project	Yes, with return or deletion at the end
A migration or backfill we run for you	You	Us, for the migration and no longer	Yes
You email us or use the form on this site	Us	Our own vendors, listed on the sub-processors page	Not applicable — here we are the controller

The distinction matters more than it looks. A DPA signed for an engagement in which we never touch personal data is not harmless paperwork: it puts a processing relationship into your records that does not exist, and it makes our vendor list a dependency of your compliance position when it need not be. Where the honest answer is that we are not a processor, we will say so and explain why, rather than signing because signing is easier than the conversation.

The reverse is also true. If a single afternoon of debugging means an engineer sees live customer records, that is processing, and it needs to be covered before it happens rather than described afterwards.

What article 28 requires it to say

Article 28 of the GDPR sets out what a controller-to-processor contract must contain. A DPA that omits one of these is not a stronger commercial document for being shorter; it is an incomplete one, and reviewers notice. These are the terms, and what each one means in an engagement with us.

01

The scope, written down

Subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subject. In our agreements these are specific to the engagement rather than a catch-all: a named window, a named data set, a named purpose. A DPA whose scope reads "any data, indefinitely, for any purpose connected with the services" tells a reviewer nothing.

02

Documented instructions only

We process on your documented instructions and nothing else, including on transfers. In practice the instruction is the statement of work, and anything outside it comes back to you as a question rather than a decision we take. Where an instruction appears to us to breach data protection law, we say so.

03

Confidentiality of the people involved

Everyone with access is bound to confidentiality. We are a small senior team, so the practical version is that the people who see your data are the people you have already met, and there is no pool of subcontractors behind them.

04

Security measures under Article 32

The technical and organisational measures, described rather than asserted. Ours are set out on the security questionnaire page and in the architecture document for your specific system. Article 32 asks for measures appropriate to the risk, which means the answer differs between a public FAQ bot and a claims file.

05

Sub-processors and prior notice

No sub-processor without your authorisation, and advance notice of a change so there is time to object. The current list is on the sub-processors page. In the common arrangement your model and cloud providers are not our sub-processors at all, because you contract them directly.

06

Assistance, then return or delete

Help with data subject rights, with security, breach notification and impact assessments — and at the end of the engagement, return or deletion of the personal data at your choice, with written confirmation. Where the system ran in your own accounts there is usually nothing to return, and we say that rather than performing a deletion ceremony over data we never held.

What we will not sign

None of these are refusals on principle. Each is a case where signing would mean asserting something untrue, and we would rather have the conversation in week one than be found out in an incident review.

A warranty that we hold a certification. We hold no security certifications — no external audit, no attestation. A clause that warrants one, or that requires us to maintain one throughout the term, is a clause we cannot sign. We will describe and evidence the controls instead, and if your process has a hard certification gate we will tell you on the first call.

A commitment to a control we do not operate. A twenty-four hour staffed security operations centre, a formal third-party screening programme, a documented control set that has been externally tested — we do not have these, and a DPA that says we do is worthless to you. Where your policy genuinely requires one, that is a real gap and worth knowing about early.

Liability for a sub-processor we do not contract. If you hold the agreement with the model provider and the cloud, their acts are not ours to indemnify. We will help you read their terms and configure their retention settings, and we will name them in the architecture document, but we cannot underwrite a contract we are not party to.

An unqualified on-site audit right. We will answer a written questionnaire in full, put the engineer who built the system on a call with your reviewer, and walk your auditor through the architecture, the logs and the access model. An unrestricted right for any of your customers to audit us at any time, at our cost, is not something a firm of our size can honestly commit to, and we say so rather than signing it and hoping it is never exercised.

A processor designation for data we never touch. Covered above, and the most common one. It is easy to sign and quietly wrong.

Questions

Questions about Data Processing Agreement.

Will you sign our DPA, or do we have to use yours?

Yours, in the ordinary case. Send it with the statement of work and we will return it marked up rather than silently accepting terms we cannot meet. Where you would prefer to start from a template, we have one, but working from your approved paper is almost always faster through your own legal review.

How long does your review take?

Usually a few working days. The clauses that take longest are always the same three: sub-processor liability, audit rights, and any warranty that depends on a certification. If you want to shorten the cycle, flag those to your counsel before sending, because they are where our mark-up will be.

Do we need a DPA if the system runs entirely in our own accounts?

Often not with us, though you will need the processor terms with your cloud and model providers, which you contract directly. Confirm this with your own counsel rather than on our say-so. If any part of the engagement gives us access to live personal data — a debugging window, a migration, an evaluation set built from real records — then yes, and it is signed before that access is granted.

What about international transfers?

Where a transfer needs a mechanism, we use standard contractual clauses or another valid one, and we support the transfer impact assessment with the technical detail it requires. The simpler path is usually not to transfer at all: EU-region compute and EU-region model endpoints, or open-weight models inside your perimeter, remove the question rather than defending it.

What happens to our data at the end of an engagement?

Return or deletion at your choice, on a schedule written into the agreement, with written confirmation when it is done. Access credentials are revoked at handover and we ask you to verify the revocation from your side rather than taking our word for it. Where we never held the data, the confirmation says exactly that.

How will we hear about a new sub-processor?

Clients under a data processing agreement are notified in advance of a change that affects their data, with time to object before it takes effect. The sub-processors page carries the date it was last reviewed so you can see whether what you are reading is current.

Can you complete our security questionnaire as well?

Yes, and our standing answers are already published so you can check the awkward ones before spending anyone's time. Send the spreadsheet and we will fill it in properly, marking a control that is not in place as not in place rather than writing language engineered to look like a yes.