Data Processing Agreement Template: What Must Be In It
A data processing agreement template as a blank scorecard, not a legal form: six DPA fields to fill from the vendor's own wording before you sign.
By The ClauseTrail team 9 min read
A usable data processing agreement template is not a blank form you fill once and file. It is a scorecard of the terms that decide how a vendor may engage subprocessors, how fast you hear about a breach, and what happens to personal data when the contract ends. If those clauses are vague or missing, the rest of the paper is theatre.
This post is that scorecard. It focuses on the fields privacy and security teams actually negotiate for subprocessors: notice, objection, breach windows, audits, transfers and deletion. It is not a substitute for what a DPA is, and it is not another clause-by-clause walk of a finished document (that is how to review a data processing agreement). It is the template shape those reviews should leave you with.
What a data processing agreement template must cover
Under Article 28(3) of the GDPR, the contract must set out the subject matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects, and the controller’s obligations and rights. Article 28(2) and 28(4) add the rules for engaging a subprocessor: prior authorisation, the same data-protection obligations, and liability up the chain.
A practical data processing agreement template therefore needs operable numbers for the six fields below. Where a vendor’s DPA leaves one “not stated”, write that down. Do not invent the missing number. The examples below come from DPAs we have read in our directory, each dated to our last extraction. Treat every figure as a snapshot; contracts change.
1. Subprocessor notice: how you find out someone new touches the data
Article 28 requires the processor to tell the controller about intended changes to subprocessors and to give the controller a chance to object. Those are two cells, not one. The notice row should force three answers onto the page:
- How many days of advance notice before a new subprocessor processes your data?
- How is notice delivered (email to a named contact, a subscribed mailing list, a public list update)?
- Does general authorisation apply, or must each new name be approved in advance?
As of our checks in late September 2026, several SaaS DPAs put a concrete advance-notice clock on the page. Intercom notifies the customer at least 20 days before it adds or replaces a name on its Sub-Processor Page (extracted 26 September 2026). Zendesk updates its Sub-processor Policy at least 30 days ahead (extracted the same day). Stripe (30 September 2026) and Atlassian (25 September 2026) both use a 30-day emailed or subscribed-email clock. An emailed clock is not the same control as a silent policy-page update.
Do not put HubSpot on this row as a 30-day advance-notice peer. Its extracted clause (25 September 2026) is a 30-day opportunity to object after notice. That belongs on the objection row. If the draft has no number, that is the finding. “We will notify you of material changes” is not a subprocessor notice clause.
2. Objection window: what you can do when you disagree
Notice without a workable objection path is incomplete. The template should say:
- How long you have to object after notice.
- On what grounds (usually protection of personal data).
- What happens if you object and the vendor still wants to proceed (termination right, alternative processing path, or nothing).
HubSpot’s DPA, as of 25 September 2026, ties the 30-day window to “reasonable grounds relating to the protection of Customer Personal Data”. That is an objection clock measured from the notice, not proof that the new name waits 30 days after you first hear about it, unless another sentence says so.
Do not reuse Stripe’s, Atlassian’s or Intercom’s notice days as the objection window. Those quotes are advance-notice clocks. If the rest of the DPA does not state grounds or an exit path, write “not stated” for those cells. When objection mechanics are thin, set your own internal deadline so whatever window exists is not wasted.
3. Breach-notification windows: a clock, not a slogan
Article 33(2) of the GDPR requires a processor to notify the controller of a personal data breach “without undue delay”. Many DPAs improve on that by naming hours. Your template should record:
- The maximum hours (or days) from awareness to customer notice.
- What starts the clock: a confirmed personal data breach, a Data Incident in scope of the GDPR, or awareness of a Security Incident as the DPA defines it.
- What information the notice must include on first contact.
The number without the trigger is a false pass. Zendesk commits to notice of a confirmed personal data breach without undue delay and within 48 hours, unless prohibited by law (extracted 26 September 2026). Intercom’s DPA, as of the same day, says “without undue delay” with no set deadline. Stripe’s 48-hour GDPR/UK GDPR clock, HubSpot’s 72 hours from a Customer Personal Data Breach, and Atlassian’s 72 hours “where feasible” after a Security Incident are in the review post. If the DPA has no number, your internal runbook still needs one.
4. Audit rights: paper you can request, or a visit you can demand
Article 28(3)(h) requires the processor to make available all information necessary to demonstrate compliance and to allow for and contribute to audits. In practice, SaaS DPAs often limit this to annual questionnaires, SOC 2 reports, or certifications. Capture:
- Frequency (once a year is typical).
- Whether on-site audits are allowed, or only document review.
- Whether third-party audit reports (SOC 2, ISO 27001) satisfy the right by default.
Intercom describes customer audits no more than once a year (extracted 26 September 2026). Zendesk’s annual audit, from the same extraction, “must only be conducted at Zendesk headquarters or an agreed business office”: a limited on-site right, not a questionnaire-only clause. Stripe’s questionnaire model and HubSpot’s SOC 2 / penetration-test copies are in the review post. Make the limit visible so procurement does not assume an on-site right that is not there, or miss one that is.
5. Transfers: the mechanism named on the page
When personal data leaves the EEA (or the UK), the DPA should name the transfer tool: standard contractual clauses, an adequacy decision, the EU–US Data Privacy Framework, or binding corporate rules. Your template row should ask:
- Which mechanism(s) are incorporated?
- Are the 2021 EU SCCs (Commission Implementing Decision (EU) 2021/914) attached or incorporated by reference?
- Does the vendor claim DPF certification, and for which entities?
As of 26 September 2026 extractions: Intercom lists SCCs and the Data Privacy Framework; Zendesk lists those plus binding corporate rules. HubSpot matches Zendesk’s trio; Stripe matches Intercom; Atlassian adds adequacy decisions. If a mechanism is not stated in the DPA we read, we leave it as not stated. Do the same in your notes. This row only confirms the contract names a lawful tool.
6. Deletion and return: what happens when you leave
Article 28(3)(g) requires the processor, at the end of the service, to delete or return personal data at the controller’s choice and delete existing copies unless law requires storage. A usable template forces:
- Delete, return, or customer choice.
- A deadline in days after termination, or “on termination” with a documented process.
- Whether backups are carved out, and for how long.
Read the verb. Intercom, as of 26 September 2026, automatically deletes customer personal data 180 days after termination if the customer does not request deletion earlier. Zendesk’s retention term was not stated in the DPA we read (extracted 26 September 2026). HubSpot (25 September 2026) and Stripe (30 September 2026) describe deletion or return (Stripe puts the choice with the user). Atlassian (25 September 2026) states deletion after expiration or termination, not a documented right to elect return. “Not stated” is the finding: ask for the missing clause before signature.
How to use this as a one-page review sheet
Turn the six fields into a single table you keep next to every new vendor DPA:
| Field | What you need written | Pass / gap |
|---|---|---|
| Subprocessor notice | Days + delivery method | |
| Objection | Window + grounds + exit path | |
| Breach notification | Hours from awareness + trigger | |
| Audits | Frequency + document vs on-site | |
| Transfers | Named mechanism(s) | |
| Deletion / return | Choice + deadline |
Fill it from the vendor’s own wording, not from a sales deck. Date the fill and link the source. An empty cell is a negotiation item, not a soft preference. This sheet sits beside Article 28’s full mandatory list (instructions, confidentiality, security measures, assistance with data-subject rights). The six fields above are the ones that most often decide whether you can operate the relationship after signature.
The one check worth making this week
Open the DPA for your highest-risk SaaS vendor. Write down the subprocessor notice period (and how it is delivered) and the breach-notification hours (and what starts the clock) in one line each. If either number is missing, raise it with the vendor or with counsel before the next renewal. That single pair of numbers is more useful than another unread PDF in the data room.
ClauseTrail reads vendors’ DPAs and the other documents that govern subprocessors, breach terms and transfers. Browse extracted DPA terms by vendor in our directory, or see what we watch.
Frequently Asked Questions
What should a data processing agreement template include for subprocessors?
At minimum: advance notice of new subprocessors (with a day count and a delivery method), a clear objection window and grounds, the same data-protection obligations flowing down under Article 28(4), and a named transfer mechanism when data leaves the EEA. Add breach-notification hours and the trigger that starts them, audit frequency and whether the right is on-site or documents only, and deletion or return on exit so the agreement is operable after signature.
Is a data processing agreement template the same as legal advice?
No. A template or scorecard helps you see which fields are present, missing or vague in a vendor’s draft. Whether those terms are adequate for your processing, and how to negotiate them, is a matter for your counsel and your risk appetite. Use the sheet to prepare questions, not to decide the answer alone.
How is this different from reviewing a finished DPA?
A review walks the vendor’s actual wording clause by clause (see how to review a data processing agreement). A template is the blank shape you hold up against that wording: the six fields you refuse to leave empty, including the ones a review can collapse (notice versus objection, hours versus trigger). You need both. The template without the review is guesswork; the review without a template often merges two clocks into one cell.
What if the vendor’s DPA says “without undue delay” for breaches?
That mirrors Article 33(2) but gives your incident team no clock. Prefer a stated hour count where the vendor will give one. If they will not, record “not stated” and set your own internal escalation timing so you are not waiting on an undefined delay during a live incident.
Do all SaaS vendors publish the same subprocessor notice period?
No. In DPAs we have read, notice windows commonly sit around 20–30 days, but the exact figure and the delivery method differ by vendor and change over time. Always read the current DPA and date your note. A neighbour’s contract is not your evidence.
Where can I see real DPA terms for a vendor?
Where we have extracted them, each vendor’s ClauseTrail page shows the breach window, subprocessor notice, transfer mechanisms, retention and audit rights with quotes from the document. Start from the vendor page or from what we watch for the document types we track.
Written from the primary sources as they stood on 3 November 2026. General information, not legal advice.
ClauseTrail watches vendors' subprocessor lists, DPAs, privacy policies, terms and AI terms, and tells your team what changed and by when to object.