NDA vs DPA: What Each Agreement Covers and When You Need Both
Businesses often reach for a Non-Disclosure Agreement when a new vendor or partner is about to see sensitive information, then assume that same document covers them once personal data starts changing hands too. It does not. An NDA and a Data Processing Agreement protect different things, are triggered by different circumstances, and under GDPR, only one of them is a legal requirement.
Key Takeaways
• An NDA protects confidential business information by contract. A DPA governs the lawful processing of personal data and is a legal requirement under GDPR wherever a processor handles data on a controller’s behalf.
• GDPR Article 28 sets out eight mandatory elements a DPA must include. An NDA has no equivalent statutory content requirement, because it is a commercial agreement, not a data protection instrument.
• An NDA cannot substitute for a DPA, even if it contains confidentiality language about personal data. Confidentiality clauses and lawful processing clauses solve different legal problems.
• Many vendor relationships need both agreements: an NDA early on to protect information shared during evaluation, and a DPA once the relationship involves actual processing of personal data.
What Is an NDA?
A Non-Disclosure Agreement is a contract that restricts how the parties involved may use or share information they define as confidential. It is not specific to personal data. Trade secrets, pricing structures, product roadmaps, and unreleased business plans typically fall under NDA protection, alongside any personal data that happens to be shared during discussions.
NDAs are commonly signed early in a business relationship, often before either party has decided whether to work together, because exploratory conversations frequently involve sharing information that could cause harm if disclosed to a competitor or the public.
What Is a DPA?
A Data Processing Agreement is a contract between a data controller and a data processor that sets out how personal data will be handled once one party processes it on behalf of the other. Under GDPR, a DPA is not optional where this relationship exists. It is a specific legal requirement, not a business preference.
A DPA typically gets signed once a vendor relationship has moved past exploratory discussion and into an arrangement where the vendor will actually handle personal data, for example, a CRM provider, a payroll processor, or a survey tool storing respondent data.
What Is the Difference Between an NDA and a DPA?
The core difference is scope and legal status. An NDA protects broadly defined confidential information through a negotiated contract with no fixed statutory content. A DPA specifically governs personal data processing and, under GDPR, must contain the elements Article 28 requires, regardless of what the parties would otherwise agree to.
An NDA is a business safeguard. A DPA is a compliance instrument. Signing an NDA with a vendor says nothing about whether that vendor is authorised to process personal data lawfully, what security measures they must apply, or what happens to the data when the contract ends. Those questions belong to the DPA.
Does GDPR Require a DPA?
Yes. Article 28(3) GDPR requires a written contract, or an equivalent legal act, between a controller and a processor whenever the processor handles personal data on the controller’s behalf. This applies regardless of company size, and regardless of whether the parties already have an NDA or another commercial contract in place covering the same relationship.
What Must a GDPR-Compliant DPA Include?
Article 28(3) sets out mandatory elements a DPA must contain. The processor must:
• process personal data only on the controller’s documented instructions;
• ensure staff handling the data are bound by confidentiality;
• implement appropriate security measures under Article 32;
• only engage a sub-processor with the controller’s authorisation;
• assist the controller in responding to data subject rights requests;
• help the controller meet its breach notification obligations;
• delete or return all personal data once the processing ends, unless the law requires retention;
• make available the information needed to demonstrate compliance and allow for audits.
A contract missing any of these elements does not satisfy Article 28, even if it is labelled a DPA and even if a separate NDA already covers general confidentiality between the same parties. The ICO’s guidance on controller-processor contracts sets out the same requirements in practical detail for organisations drafting or reviewing a DPA.
Can an NDA Replace a DPA?
No. This is one of the most common compliance gaps businesses run into. Confidentiality obligations and lawful processing obligations solve different problems: an NDA stops a party from disclosing information it should not share, while a DPA governs how a party is allowed to process personal data in the first place, including instructions, security, sub-processing, and deletion. Adding a confidentiality clause covering personal data to an NDA, or to a general services agreement, does not satisfy Article 28’s specific content requirements.
When Do You Need Both an NDA and a DPA?
Most vendor relationships that start with confidential discussions and progress into an actual data processing arrangement need both agreements at different points. A typical sequence looks like signing an NDA during initial evaluation of a vendor, then a DPA once the relationship is confirmed and the vendor will process personal data as part of delivering their service.
Where international data transfers are involved, the DPA is often paired with Standard Contractual Clauses covering the transfer mechanism, on top of the core Article 28 content. Businesses running structured vendor onboarding, comparable to a GDPR compliance checklist approach, typically build both documents into the same procurement stage rather than treating the DPA as an afterthought once integration work has already started.
What Happens If You Use an NDA Instead of a Required DPA?
Operating a processor relationship without a valid DPA is itself a GDPR violation, separate from anything that might go wrong with the data. An NDA covering the same relationship does not change this. Article 28 violations fall under the higher tier of GDPR’s fine structure, alongside violations of the basic principles for processing, which can reach up to €20 million or 4% of global annual turnover. Our breakdown of GDPR fines and penalty structures explains how these tiers work and what factors regulators weigh when calculating a fine.
Conclusion
An NDA and a DPA answer different questions. One protects confidential information through negotiated contract terms; the other satisfies a specific legal requirement for how personal data gets processed, with content GDPR itself dictates. Treating an NDA as sufficient cover for a data processing relationship is a common and avoidable compliance gap. Where a vendor, partner, or contractor will process personal data on your behalf, a properly drafted DPA needs to exist alongside, not instead of, whatever confidentiality agreement you already have.
Frequently Asked Questions
Is a DPA legally required even for small businesses?
Yes. Article 28 GDPR applies regardless of company size wherever a processor handles personal data on a controller’s behalf. There is no small business exemption from this specific requirement, though the scale of the processing may affect how detailed the surrounding documentation needs to be.
Does an NDA need to mention GDPR at all?
Not necessarily. An NDA can function purely as a confidentiality instrument without referencing data protection law. If personal data will also be processed as part of the relationship, that processing needs to be governed by a separate DPA rather than folded into the NDA’s confidentiality clauses.
Who signs a DPA, the controller or the processor?
Both parties sign. Article 28 requires a written contract or equivalent legal act between the controller and the processor, meaning both parties are bound by its terms, including the processor’s obligations around security, sub-processing, and data return or deletion.
Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.
About the Author
Ana Mishova
Sales and Business Development Consultant — GDPRLocal
Ana focuses on helping organisations understand their compliance obligations and find the right data protection solutions. At GDPRLocal she works closely with businesses of all sizes, making GDPR and privacy compliance clear, practical, and accessible.