Your wording
Your clauses stay yours
Upload the agreement your practice already uses as a firm template. The body is untouched; the placeholders for the client's legal name, address and contact are filled from confirmed answers.
Data processing agreements
A data processing agreement that matches what the client actually does
The schedules are where a DPA goes wrong: a description of processing copied from a template, a sub-processor list that is a year old. Both are built here from the same confirmed answers as the rest of the pack.
Free · No sign-up · Up to ten websites
What is a data processing agreement?
A data processing agreement is the contract Article 28 of the GDPR requires between a controller and a processor. It has to set out the subject matter and duration of the processing, its nature and purpose, the categories of data and of data subjects, and the controller's rights — and it has to bind the processor to a specific list of obligations.
The body of the agreement is settled work: most practices have wording they trust and do not want rewritten. The part that dates is the schedules. A description of processing that no longer matches the product, or an annex naming a sub-processor the client dropped last quarter, is the failure mode worth designing against.
What it has to cover
- The subject matter, duration, nature and purpose of the processing
- The categories of personal data and of data subjects
- The controller's instructions, and the processor's confidentiality and security duties
- Authorisation for sub-processors, and how changes are notified
- Transfers outside the EEA and the mechanism relied on for each
- What happens to the data when the contract ends
What changes when it is not done by hand
Schedules from data
The schedules are built, not written
The description of processing, the sub-processor annex and the transfer table come from the client's confirmed facts and the vendor registry, by code — never from a model's paraphrase.
Ends honestly
A missing answer is visible
If the client has not told you how long support conversations are kept, the schedule says so with the question to ask. It does not offer a plausible retention period.
What you get
Every vendor fact comes from our own registry: 157 vendors with the date each entry was checked.
Firm templates with placeholders
Your agreement, with the client's legal name, registered address and privacy contact filled from answers you confirmed.
Sub-processor annex from the registry
Legal entity, country, purpose, transfer mechanism and DPA link for every vendor that client uses, with the date each was checked.
Transfer table built by code
Every vendor outside the EEA with the mechanism it relies on, assembled from the registry rather than recalled.
One interview, the whole pack
The same confirmed answers produce the record of processing, the privacy policy and the retention schedule alongside the agreement.
Marked out of date on a change
When a vendor changes its contracting entity, every client agreement naming it is flagged, with the documents to regenerate.
Exports under your brand
DOCX and PDF carrying your logo and firm name, with no mention of us in the text or the file metadata.
Get started in three steps
- 1
Load your agreement once
Add the wording your practice uses as a firm template, with placeholders where client details belong.
- 2
Interview the client once
Answer in the workspace or send the client a link for the parts only they know. You confirm every answer before it is used.
- 3
Generate, check and export
The agreement is drafted with its schedules built from those facts. You read it, export it under your brand, and hear when a vendor change dates part of it.
Questions
- Do you supply the agreement wording?
- You can start from a draft, but most practices load their own. The value here is the schedules and keeping them current, not replacing clauses you already trust.
- Is the contract text written by a model?
- No. Firm templates are used verbatim. A model drafts prose sections only where you have no template, and the schedules are always built by code from confirmed facts.
- How are sub-processor changes notified?
- That is your decision and your client's contract. We tell you about the change and which clients it touches; the notice to the client comes from your practice.
- Can it cover a client that is a controller, not a processor?
- Yes, but which role a client holds is a legal qualification. It is suggested with an explanation and takes effect only when you confirm it.
- Does this give legal advice?
- No. It prepares the documentation the regime requires from facts you confirm. Every legal qualification stays your decision.
See what changed since your clients' policies were written
Enter up to ten client websites. Free, no sign-up, the first report in about a minute.