Privacy Policy vs Data Processing Agreement: the Difference (2026)

Privacy policy vs DPA: the short answer They do different jobs for different audiences. - A privacy policy (or privacy notice) is a public statement to individuals. It tells the people whose data you handle what you collect, why, how long you keep it, who you share it with, and what rights they have. It is a transparency document.

• A data processing agreement (DPA) is a private contract between two businesses: a controller (who decides why and how data is processed) and a processor (a vendor who processes data on the controller's instructions). It sets out the rules the processor must follow. One faces your users and explains your data practices. The other faces your vendor and binds them contractually. Having one does not satisfy the need for the other. This article is general guidance, not legal advice. Data-protection law varies by jurisdiction and changes often, so take professional advice before relying on either document. ## What a privacy policy is for A privacy policy is a transparency notice aimed at data subjects: your customers, website visitors, job applicants and anyone else whose personal data you hold. Under the GDPR this duty comes from Articles 13 and 14. A privacy policy typically covers: - Who you are and how to contact you (and your data protection officer, if any).
• What personal data you collect and from where.
• Why you process it (the purposes) and your legal basis.
• Who you share it with, including processors and any transfers abroad.
• How long you keep it.
• The rights individuals have, such as access, correction and deletion, and how to exercise them. The audience is the public, so the language should be clear and the document should be easy to find, usually linked from your website. ## What a data processing agreement is for A DPA is a contract, not a public notice. Under the GDPR, Article 28 requires a binding contract whenever a controller uses a processor, so that the processor only acts on the controller's instructions. A DPA typically covers: - The subject matter, duration, nature and purpose of the processing, and the types of data and categories of individuals involved.
• That the processor acts only on the controller's documented instructions.
• Confidentiality obligations on the processor's staff.
• Security measures the processor must apply.
• Rules on sub-processors, usually requiring the controller's permission.
• Help for the controller with data subject rights, breach notification and audits.
• What happens to the data at the end: return or deletion. The audience is your vendor. The DPA is what makes it lawful to let that vendor touch personal data on your behalf. ## Side by side | Feature | Privacy policy | Data processing agreement | |---|---|---| | Audience | Individuals (the public) | A vendor/processor (another business) | | Type | Public transparency notice | Private contract | | Legal source (GDPR) | Articles 13 and 14 | Article 28 | | Purpose | Tell people what you do with their data | Bind a vendor to handle data correctly | | Direction | You to your users | Between controller and processor | | Signed? | No, it is published | Yes, it is a signed contract | ## Why one cannot replace the other This is the practical point most businesses get wrong. A privacy policy does not cover your vendor relationships, so it cannot do the job of a DPA. And a DPA is not shown to your users, so it cannot do the job of a privacy policy. If you embed a third-party analytics or email tool, that vendor is usually a processor: you need a DPA with them, and your privacy policy should separately disclose that the tool processes your visitors' data. Each document satisfies a different legal obligation. Having one does not tick the box for the other. ## A quick worked example You run an online store. - Your privacy policy tells shoppers what data you collect at checkout, why, how long you keep order records, that you use a payment processor and an email provider, and how they can ask for their data.
• Your DPA with the email provider records that the provider processes customer emails only on your instructions, keeps them confidential and secure, will not add new sub-processors without telling you, and will delete the data when the contract ends. Both are needed, and they describe the same data flow from two different angles. ## Does this vary by jurisdiction? Yes, though the two-document split is common across modern data-protection regimes. The GDPR (EU) and UK GDPR use Articles 13, 14 and 28 as above. In India, the Digital Personal Data Protection Act, 2023 uses the language of "Data Fiduciary" (similar to a controller) and "Data Processor", requires a fiduciary to process personal data only under a valid contract with a processor, and requires notice to individuals about the data collected and the purpose. US state laws such as California's CCPA/CPRA require a privacy notice and impose contract terms on service providers that function much like a DPA. The names and the fine print differ, so check the rules of the jurisdictions whose residents' data you handle. <!-- [VERIFY] exact current notice and processor-contract wording under India DPDP Act rules as at October 2026 --> ## Where a contract workspace helps A DPA is a contract, and most organisations sign one per vendor, each with its own sub-processor list, security schedule and deletion terms. Drafting a DPA, reviewing a vendor's version before you sign, tracking which vendors have a current one, and governing changes as your processing shifts can all live in one AI workspace tuned to how your company uses vendors. Adira is designed around that single shared workspace. This explainer is enough to tell a privacy policy from a DPA; the workspace keeps every vendor agreement and its key dates in one place.