The following skips the primer and works as a contract audit, organised by 9 contract types: Processor Agreements, Joint Controller Arrangements, International Transfers, Sub-processors, Breach Notification, Audit Rights, Exit, Liability and AI Vendors. Each section lists what the law requires, what to check in the document and where templates usually fall short. Book a LEGALFLY demo and see how we build a personalised playbook for you, based on your internal guidelines or golden contracts, that complies with old and new GDPR rules.
If the enterprise operates from the US and serves EU data subjects, the GDPR compliance checklist for US companies covers the programme-level obligations first.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
What changes in 2026 checklist: the Digital Omnibus
On November 19th, 2025, the European Commission proposed the Digital Omnibus, two regulations that would rewrite parts of the GDPR and the ePrivacy Directive. This proposal would eventually split in two: the Artificial Intelligence Act and the Data Omnibus, which contains GDPR Amendments.
The AI Act was adopted as Regulation (EU) 2026/1744 in July 2026 (Annex III, regarding high-risk obligations, was moved to December 2nd, 2027), but the Data Omnibus is still in its first reading
Despite the Presidency of the European Council’s request for negotiations, the member states' ambassadors have yet to reach a unanimous decision, and several meetings have been rescheduled. However, as a Council mandate cannot amend the GDPR, this is but a step in negotiations.
The final text of the omnibus might still change substantially, but these are the current proposals that will impact contracts:
Personal data becomes relative - A revised Article 4(1) would treat information as not personal for an entity that cannot reasonably identify the person. This codifies the CJEU's September 2025 ruling in EDPS v SRB (C-413/23 P) on pseudonymised data.
DPIAs become harmonised - The Commission proposed EU-wide lists of processing that do and do not require a data protection impact assessment, plus a common template, to replace the current national lists.
Breach notification changes - Notification to the supervisory authority would apply only to breaches likely to pose a high risk, within 96 hours instead of 72, through a single EU reporting point shared with NIS2 and other incident regimes.
AI processing gets a clearer basis - A new Article 88c would confirm that developing and operating AI systems can rely on legitimate interest, with a narrow Article 9 exception for residual special category data in training sets.
For in-house legal, this simply means they must keep running their GDPR programme against the current law and reinforce it with contracts that can absorb future changes. The next section explains how, clause by clause.
How to run a GDPR compliance audit checklist
Start from the data map rather than the contract repository, as the records of processing, under Article 30, already list the recipients of personal data. Each recipient should have a contract matching its role, and each contract should also match what the vendor actually does.
Here is how to do it at a glance, with a more in-depth guide below:
Scope the estate | Pull every agreement under which personal data leaves your control. This can be SaaS and cloud contracts, outsourcing, payroll and HR providers, marketing platforms, group intra-company agreements, data sharing with partners, and/or AI tools. |
Classify the role | Tag each counterparty as processor, joint controller or independent controller. The role decides which checklist applies, and a wrong label is itself a finding. |
Tier by risk | Prioritise contracts that involve special category data, large volumes, transfers outside the EEA, or AI processing. Low-risk vendors can follow a lighter review cycle. |
Test against one playbook | Check every contract against the same positions, so findings are comparable across the portfolio and can be fixed at renewal. |
1. Processor agreements under Article 28
Article 28(3) sets the minimum content of every controller to processor contract and most DPAs will recite those points.
The audit question is whether they recite them in an enforceable way, and whether the annexes describe the processing that actually happens.
The EDPB's Guidelines 07/2020 on controller and processor are clear: Copying the wording of Article 28 is not enough; the contract has to say how each obligation is met. If the vendor template does not have enough information, the Commission's Article 28 standard contractual clauses (Implementing Decision 2021/915) might be useful.
Checklist: Article 28 DPA
☑️ Subject matter, duration, nature and purpose of processing, data types and data subject categories are specific to this service, not a generic list.
☑️ The processor acts only on documented instructions, including on transfers, and must say if an instruction appears to infringe the GDPR.
☑️ Staff with access are bound by confidentiality.
☑️ Security measures under Article 32 are described in an annex that maps to the service, with a right to see updates.
☑️ Sub-processor engagement requires prior authorisation, specific or general, with flow-down of the same obligations (see section 4).
☑️ The processor assists with data subject requests within a set timeframe.
☑️ The processor assists with Articles 32 to 36: security, breach notification, DPIAs and prior consultation.
☑️ Deletion or return at the end of the service is decided by the person or firm implementing the process, with a deadline and certification (see section 7).
☑️ The processor makes available all information needed to demonstrate compliance and allows audits (see section 6).
☑️ Order of precedence: the DPA wins over the main agreement on data protection matters.
Attention: Annex I is often a copy of the vendor's whole product catalogue, and, since instructions are defined as "the use of the service", this hands the processor the right to decide purposes. This is where templates fall short, because some uses of customer data appear outside the DPA, which turns the processor into a controller for that data.
2. Joint controller arrangements under Article 26
Joint controllership is the arrangement most often missing. The CJEU has read it broadly: in Wirtschaftsakademie (C-210/16) and Fashion ID (C-40/17), a party that influences the purposes and means of even one stage of processing became a joint controller for that stage.
In other words, co-marketing, shared platforms, group-level HR systems and research partnerships, for instance, regularly become co-responsible for collected data, but there is no arrangement drafted to monitor and regulate those situations.
Article 26 requires an arrangement that not only sets out each party's responsibilities in a transparent way, but also reflects their real roles towards data subjects. These subjects can still exercise their rights against either party, no matter the contract, as they have access to the data essence.
Checklist: Joint Controller Arrangement
☑️ The joint processing operations are identified with a clear line between what is joint and what each party does alone.
☑️ Each party's legal basis for the joint processing is recorded.
☑️ Responsibility for transparency (privacy notices, Articles 13 and 14) is allocated to one party.
☑️ A single contact point for data subjects is named, and requests are forwarded within a set time.
☑️ Responsibility for breach notification, DPIAs and security measures is allocated per operation.
☑️ The essence of the arrangement is published or available on request.
☑️ Internal liability and indemnity follow each party's share of control, accepting that external liability to data subjects is joint (Article 82(4)).
☑️ Exit terms cover what happens to jointly collected data when the relationship ends.
Attention: If the facts show joint control, that is the contract the parties must sign, even if the template on file is a processor DPA. This simple mistake is where templates fall short, because the DPA then misdescribes the relationship, and neither party has made the transparency allocation that Article 26 requires.
3. International transfer clauses: SCCs, TIAs and the DPF
Any transfer outside the EEA needs a Chapter V mechanism. This means one of three things: an adequacy decision, the 2021 standard contractual clauses (Implementing Decision 2021/914), or binding corporate rules for intra-group flows.
The contract audit checks that the mechanism exists, fits the transfer and, when required, is backed by a transfer impact assessment.
The EU-US Data Privacy Framework survived its first challenge in September of last year, with Latombe v Commission (T-553/23). Latombe appealed, and the decision is pending, so, until further notice, the practical advice holds: where a US vendor relies on DPF certification, keep SCCs in the contract as a fallback that activates automatically if the adequacy decision falls.
Checklist: International Transfer Clauses
☑️ Every non-EEA recipient, including sub-processors and support access from third countries, is identified and has a named transfer mechanism.
☑️ The correct SCC module is used (controller to controller, controller to processor, processor to processor, processor to controller), and the annexes are completed, not left blank.
☑️ SCC wording is incorporated unchanged. Commercial terms elsewhere do not contradict or limit the clauses.
☑️ A transfer impact assessment is documented for each SCC transfer to a non-adequate country, and the review date is recorded.
☑️ Supplementary measures identified in the TIA (encryption with keys held in the EEA, pseudonymisation, access controls, etc) are written into the contract or security annex.
☑️ The importer must notify you of government access requests where legally allowed, and challenge disproportionate ones (SCC Clause 15).
☑️ DPF reliance is checked against the vendor's active certification, with SCCs as a fallback.
☑️ Onward transfers by the importer are restricted to recipients covered by an equivalent mechanism.
☑️ For UK flows, the UK Addendum or IDTA is attached. For Swiss flows, the Swiss adaptations are in place.
Attention: TIAs are signed once and never revisited, even when the vendor moves processing to a new region. If the Annex III sub-processor lists are out of date, the templates will fall short.
4. Sub-processor flow-down and notification
A vendor's vendors process data too. Article 28(2) and 28(4) require prior authorisation for each sub-processor and the same data protection obligations flowing down the chain, with the original processor fully liable for its sub-processors' failures.
This bar was further raised by the EDPB in Opinion 22/2024, where controllers were advised to have the identity of all processors and sub-processors, and not just the first tier, available at all times. Additionally, it is the controller's duty to verify sufficient guarantees extend down the chain in proportion to the risk.
Checklist: Sub-processors
☑️ The authorisation model is stated: specific (each sub-processor approved) or general (approved list plus notice of changes).
☑️ The current sub-processor list is attached or linked, with name, location, service and transfer mechanism for each.
☑️ Notice of new or replaced sub-processors is given in advance, in writing or by subscription, with a set period (30 days is a common market position).
☑️ You have a right to object on reasonable data protection grounds, and a remedy if the objection is not resolved, such as termination of the affected service without penalty.
☑️ The processor imposes the same obligations on each sub-processor by written contract, and can show those contracts on request.
☑️ The processor remains fully liable for sub-processor performance.
☑️ The chain beyond the first tier is visible, in line with the EDPB position on identity of all sub-processors.
☑️ Emergency replacements are allowed only with immediate notice and the same objection right after the fact.
Attention: The templates will fall short when objections rights never lead to actions. Notices in web page’s updates with no alerts, objections leading only to "good faith discussions", with the final step of an unresolved objection being the termination of the whole agreement with no refund.
5. Breach notification windows
The controller has 72 hours since becoming aware of a personal data breach to notify the supervisory authority under Article 33(1). The processor only has to notify the controller "without undue delay" under Article 33(2). This gap is where most incidents go wrong: if the DPA does not set a hard window, the controller's 72 hours can be half spent before it hears anything.
For regulated enterprises, GDPR is no longer the only clock, as incident regimes stack on top of each other:
Regime | Who notifies | Deadline |
|---|---|---|
GDPR Art. 33 (current law) | Controller to supervisory authority | 72 hours from awareness |
GDPR Art. 33(2) | Processor to controller | Without undue delay |
NIS2 Art. 23 | Essential and important entities to CSIRT or authority | Early warning in 24 hours, notification in 72 hours, final report in one month |
DORA Art. 19 | Financial entities to competent authority | Initial notification within hours of classifying a major ICT incident, per the RTS |
Digital Omnibus (proposal only as of October 2026) | Controller to supervisory authority, high-risk breaches only | 96 hours, through a single EU reporting point |
Checklist: Breach Notification Clauses
☑️ The processor must notify within a fixed number of hours of becoming aware, not "without undue delay" alone. 24 to 48 hours is a common enterprise position.
☑️ Awareness is defined, so the clock starts at detection by the processor or any sub-processor.
☑️ The notice must contain the Article 33(3) content, and information can be provided in phases.
☑️ The processor must cooperate with investigation, containment and notifications to authorities and data subjects.
☑️ The processor may not notify authorities or data subjects on your behalf without your approval, unless the law requires it.
☑️ Where you are also subject to NIS2 or DORA, the window is short enough to meet the strictest regime.
☑️ Costs of notification and remediation caused by the processor are allocated (see section 8).
Attention: Vendor DPAs often promise notice "without undue delay" and define a breach as a "confirmed" breach, which justifies days of internal investigation before notice. If the Omnibus moves the authority deadline to 96 hours, a fixed processor window still works, because it is set in hours from awareness rather than as a fraction of the statutory deadline.
6. Audit rights
Article 28(3)(h) gives the controller a right to audits and inspections, conducted by itself or a mandated auditor. Large vendors resist on-site audits, which is reasonable at scale, but the contract still has to provide a path to evidence that does not depend on the vendor's goodwill.
The common compromise is layered: certifications and reports first, a questionnaire second, and a real audit when the first two are not enough or after an incident.
Checklist: Audit rights
☑️ Independent reports (ISO 27001 certificate and statement of applicability, SOC 2 Type II report) are provided on request, at least annually, and cover all the services being used.
☑️ Security and privacy questionnaires can be sent, with a response deadline.
☑️ An on-site or remote audit is available where reports do not answer the question, after a breach, or when a supervisory authority asks.
☑️ Audits can be performed by a third-party auditor bound by confidentiality, not only by the controller’s staff.
☑️ Supervisory authorities have the same access, without contractual limits.
☑️ Notice periods, frequency limits and cost allocation are reasonable. Costs shift to the vendor when an audit finds material non-compliance.
☑️ Findings lead to a remediation plan with deadlines.
☑️ Audit rights reach sub-processors, either directly or through the processor's own audits.
Attention: "Audit" is limited to reviewing the vendor's latest certificate, which may not cover all the products bought and, in turn, affect the templates. Frequency is capped at once a year with no incident exception, and the customer pays even when the audit finds a failure.
7. Deletion and return on exit
Article 28(3)(g) requires the processor to delete or return all personal data at the end of the service, at the controller's choice, and delete existing copies unless Union or member state law requires storage. Exit is where contracts get the least attention at signing and cause the most trouble later, especially when backups, logs and AI-derived data are involved.
Checklist: Deletion and Return on exit
☑️ The controller chooses between return and deletion, and the choice can be made at signing and at termination.
☑️ Return happens in a usable, documented format within a set period.
☑️ Deletion has a deadline, including backups, with a stated maximum retention for backup rotation.
☑️ The processor provides written certification of deletion, covering sub-processors.
☑️ Retention required by law is identified specifically, and the data remains protected under the DPA while held.
☑️ Logs, metadata and derived data (embeddings, indexes, model fine-tunes, etc) are in scope of deletion.
☑️ Transition assistance is available at agreed rates, so you are not forced to accept deletion before migration is complete.
☑️ Data protection obligations survive termination for as long as the processor holds any data.
Attention: "Deletion in accordance with our standard retention policy" can mean 90 days or more, with no certification, and without even mentioning data from AI features. Be aware of those details when setting up the templates.
8. Liability caps for data incidents
The GDPR sets the external exposure. Article 83, sets administrative fines, which can reach up to €20 Million or 4% of worldwide annual and article 82 allows data subjects to claim compensation. When controller and processor are both responsible, each is liable for the entire damage, with a right of recourse against the other. The contract cannot change that external position and it decides who ultimately pays.
Most vendor contracts cap total liability at 12 months of fees, which, for some companies, can be smaller than the cost of notifying data subjects after a single breach.
Checklist: Liability and Indemnity
☑️ The DPA is subject to the main agreement's liability clause only where that is intended. It is crucial to check the order of precedence in both directions.
☑️ Data protection breaches carry a separate, higher cap (a super-cap), often a multiple of annual fees or a fixed sum linked to data volume and sensitivity.
☑️ Breach of confidentiality and data protection obligations is not swept into the general exclusion of indirect or consequential loss.
☑️ Recoverable losses are listed: forensic investigation, notification costs, call centres, credit monitoring, regulatory defence costs and compensation paid to data subjects.
☑️ Indemnities for processor fault cover third-party claims under Article 82, and the recourse right under Article 82(5) is not limited.
☑️ Whether fines can be recovered contractually is addressed carefully, since enforceability varies by member state.
☑️ Insurance requirements (cyber cover with a stated minimum) back the cap.
☑️ Liability for sub-processors sits with the processor, uncapped by the sub-processor's own terms.
Attention: When DPA says the processor is liable "in accordance with the GDPR", but the main terms quietly cap everything at the fees paid in the last year, the templates fall short. This gap is the more important the cheaper the vendor is.
9. AI vendor contracts: the newest gap in most DPA templates
Most DPA templates were written for hosting and SaaS, and they assume the vendor stores and processes data to deliver a defined service. AI vendors, however, use the data differently:
Training on data - The first question is whether the provider uses prompts, uploaded documents or outputs to train or improve its models. If so, it decides the purpose of that processing, which makes it a controller for that use instead of a processor. As a result, there needs to be a legal basis and transparency for a disclosure that might not even be intentional. The EDPB's Opinion 28/2024 on AI models also warned that a model trained on unlawfully processed data can carry that problem into its later use. The proposed Article 88c in the Omnibus would make legitimate interest easier to rely on for AI development, which is one more reason to settle the training question in the contract rather than rely on the vendor's interpretation of the law.
Data Processing - An AI vendor may host a workspace in Frankfurt and send inference requests to a model running in the US. The model provider is a sub-processor, and the inference region is a transfer question. Abuse-monitoring logs held by the model provider are a retention question.
Checklist: AI Vendor Contracts
☑️ A clear, unqualified commitment that customer inputs, documents and outputs are not used to train, fine-tune or improve any model, including the vendor's and its model providers'.
☑️ Any "service improvement", "analytics" or "aggregated data" right in the main terms is excluded for personal data, or limited to anonymised telemetry.
☑️ The model provider and any hosting provider are listed as sub-processors, with their processing locations.
☑️ The location of inference, not only storage, is stated, and any transfer is covered by a Chapter V mechanism.
☑️ Retention of prompts, outputs and logs is defined, including any abuse-monitoring retention by the model provider, with zero retention where available.
☑️ Derived data (embeddings, vector indexes, fine-tuned models built on your data) is yours, and is deleted on exit.
☑️ The vendor tells you before changing the underlying model or model provider, with the same objection right as any sub-processor change.
☑️ The vendor supports your DPIA and your AI Act obligations as a deployer, including documentation and logs, ahead of the high-risk obligations that now apply from 2 December 2027.
☑️ Where AI output feeds decisions about individuals, the contract supports human review and the safeguards in Article 22.
Attention: The no-training promise must be included in the DPA, otherwise the templates fall short. A marketing FAQ, a trust page that can change without notice, a processing location that is different from where the data is stored, etc, are not legally binding.
How to write Omnibus-ready contracts
As the changes to the law have not been implemented yet, the aim of the new contracts is to avoid as many renegotiations with hundreds of vendors as possible, particularly in four main areas:
Pseudonymised data
The change with the largest contractual impact. If personal data becomes relative, a vendor that receives only pseudonymised records and holds no key may argue the data is not personal in its hands, so the DPA no longer applies (the SRB ruling already supports that argument in some cases).
The fix is a contractual definition that does not depend on the vendor's view:
Define the protected data as all customer data relating to individuals, "including pseudonymised data, whether or not it constitutes personal data in the hands of the Processor".
Prohibit any attempt to re-identify individuals, or to combine the data with other sources that would allow it.
Keep re-identification keys with you, and state that the vendor will not request or receive them.
Restrict onward sharing of pseudonymised data to the same terms as personal data.
This also keeps the controller on the right side of the EDPB, which rejected the narrower definition. A contract that protects pseudonymised data in full works under both the current text and the proposal.
DPIAs
If DPIA lists are harmonised at EU level with a common template, the triggers for some processing will change. The solution is to draft the assistance clause by reference to any DPIA required under Article 35 "or under any list or template adopted at Union level", require the vendor to provide the information needed within a set time, and avoid naming a specific national authority list as the only trigger.
Breach windows
Keep processor notice in fixed hours from awareness, as mentioned in section 5. It stays valid whether the authority deadline is 72 or 96 hours, and whether every breach or only high-risk breaches must be reported.
Change in law
Adding a clause that refers to applicable data protection law "as amended or replaced from time to time", obliges both parties to agree to amendments needed for compliance within a set period, and prevents the vendor from charging for changes required by law.
Additionally, a no-training commitment that applies whatever legal basis becomes available, will also protect the data when dealing with AI vendors and processors.
Running the contract audit with LEGALFLY
Having a checklist is only half of the solution - now, it must be applied to every new vendor contract and every DPA already signed, while procurement waits. LEGALFLY, the legal operating system for in-house teams, moves this work from request to outcome, inside the guardrails legal sets.
MSIG Europe, a property, casualty, and marine insurer operating across several European countries, implemented LEGALFLY's contract review and playbook functionality, to help review their evergrowing data protection agreements. Since deployment, the time spent reviewing, tracking or responding to business questions decreased dramatically - in some cases, from a full day to around 20 minutes - while consistency and quality maintained, allowing the teams to expand jurisdictional coverage. All of it due to LEGALFLY’s extended solutions:
With Agent Studio, the GDPR contract that started in procurement runs through one end-to-end workflow, with a human always in control:
A vendor contract arrives (by email, Slack, manual upload, etc).
The Review agent checks the DPA against the GDPR playbook (Article 28 terms, transfer mechanism, breach window, sub-processor rights, etc).
Terms inside the playbook are approved while deviations are escalated to legal, with the flagged clause, the reason and a suggested redraft.
Legal decides and an approved summary goes back to procurement automatically.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
And, for the DPAs, vendor agreements and data sharing contracts full of names, signatories and contact details, there is Anonymisation, the only tool that anonymises documents at import, before analysis begins. Context and structure stay intact, so personally identifiable data does not leave your environment.
For when obligations keep moving - DPA renewals, SCC and TIA review dates, sub-processor notice periods, processor obligations with deadlines, etc - there is Contract Intelligence. It covers the full contract lifecycle, from negotiation through approval and e-signature to monitoring renewals, notice periods, obligations and key dates.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
Lastly, Multi Review allows audits to the whole DPA estate in one pass, for when reviewing one contract at a time does not scale.
The tool scans entire document sets from SharePoint or the document system, anonymises every file, and applies one GDPR playbook across all of them. It flags missing clauses, deviations and high-risk outliers, and exports the result as an audit-ready table with source links. It is the fastest way to turn the checklist above into a remediation list.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
FAQs About GDPR Compliance Checklist
What should a GDPR compliance checklist for contracts include?
At minimum: Article 28 processor terms, Article 26 joint controller arrangements, international transfer mechanisms with transfer impact assessments, sub-processor controls, breach notification windows, audit rights, deletion and return on exit, and liability for data incidents. In 2026, add AI vendor terms on training and processing location.
Does the Digital Omnibus change GDPR compliance requirements in 2026?
Not yet. As of October, 2026, the GDPR part of the Digital Omnibus remains a proposal, as the European Council has approved its position on the proposal and must now start negotiations with the Parliament in order to reach an agreement. Current GDPR rules apply in full. The sensible step is to draft contracts that work under both the current text and the proposal.
How often should we run a GDPR compliance audit checklist on our DPAs?
Review high-risk processor contracts at least annually and on any material change, such as a new sub-processor, a new processing region or a new AI feature. Lower-risk contracts can follow the renewal cycle, and transfer impact assessments need a set review date.
Is pseudonymised data still personal data?
Under current law, pseudonymised data is personal data for anyone who can reasonably re-identify it. The CJEU's SRB ruling held that it is not necessarily personal for every recipient. The Omnibus proposal would codify that relative approach. Contracts should protect pseudonymised data in full either way.
Is there a GDPR compliance checklist for US companies?
Yes. US companies that offer goods or services to people in the EU, or monitor their behaviour, are subject to the GDPR. See our GDPR compliance checklist for US companies.
