How to Compare Privacy Policies and Data Processing Agreements
Privacy documents change more frequently than almost any other document type lawyers review. A new state privacy law takes effect and the privacy policy needs updating. The European Commission issues a new adequacy decision and the DPA's cross-border transfer mechanism needs revision. A vendor adds a subprocessor and the subprocessor list in the DPA changes. A company launches a new product feature that collects additional data and the privacy policy's data collection section expands.
Each of these changes needs to be reviewed against two things: the applicable regulation (GDPR, CCPA, the latest state privacy law) and the business relationship the document governs. A privacy policy change that broadens data sharing with third parties may be legally compliant but commercially problematic if your vendor agreement restricts how your data is used. A DPA change that replaces on-site audit rights with access to a SOC 2 report may satisfy one regulator's expectations but not another's.
This post covers how to compare both types of privacy documents: consumer-facing privacy policies and B2B data processing agreements. The comparison challenges are different for each, but the underlying discipline is the same. In every case, you need to identify what changed, assess whether the change meets regulatory requirements, and determine whether it affects the business relationship.
Why privacy documents need frequent comparison
Privacy documents change for reasons that other contracts do not. Three forces drive constant revision.
Regulatory velocity. The privacy regulatory landscape has not stabilized. The GDPR has been in effect since 2018, but enforcement guidance, court decisions, and regulatory interpretations continue to evolve. The CCPA was amended by the CPRA effective January 2023. Since 2023, new comprehensive privacy laws have taken effect in Virginia, Colorado, Connecticut, Utah, Iowa, Indiana, Tennessee, Montana, Texas, Oregon, and Delaware, with more states following. Each new law has slightly different requirements for disclosure, consent, data subject rights, and enforcement. Organizations that operate across jurisdictions update their privacy documents regularly to address these requirements, and each update introduces changes that may affect compliance in other jurisdictions.
Product and business changes. Privacy policies describe actual data practices. When those practices change (for example, a new analytics tool is deployed, a new advertising partner is onboarded, or a new feature collects location data), the privacy policy should change to reflect the new reality. Companies that update their privacy practices without updating their privacy policies face enforcement risk. Companies that update their privacy policies without clearly disclosing the changes face consumer trust issues and, in some jurisdictions, regulatory penalties.
Vendor and subprocessor changes. For DPAs, the most common trigger for revision is a change in the processor's subprocessor list. Processors add and remove subprocessors as they change infrastructure providers, analytics tools, and support platforms. Under GDPR Article 28, controllers must be informed of changes to the subprocessor list and given an opportunity to object. Each subprocessor change triggers a review obligation for the controller.
Data collection scope and processing purposes
The data collection section of a privacy policy describes what personal data the organization collects and why. In a DPA, the equivalent is the description of processing (typically in an annex) that specifies the categories of data subjects, categories of personal data, and purposes of processing. Changes to either are among the most consequential revisions in a privacy document.
New data categories. A privacy policy update that adds "precise geolocation data," "biometric identifiers," or "sensitive personal information" to the collection scope is a material change. Many privacy laws impose heightened requirements for sensitive data categories: explicit consent under the GDPR, opt-in consent under the CCPA/CPRA, and specific data protection impact assessments. Between versions, compare the data categories list line by line. A new category may trigger new compliance obligations.
Processing purpose expansion. Under the GDPR's purpose limitation principle, personal data must be collected for specified, explicit, and legitimate purposes and not further processed in a manner incompatible with those purposes. A privacy policy that adds "product improvement," "personalized advertising," or "training artificial intelligence models" as a processing purpose is expanding the scope of data use. In a DPA, a change that broadens the "Purpose of Processing" from "providing the Services as described in the Agreement" to "providing and improving the Services" may authorize the processor to use controller data for the processor's own product development. This is a significant change to the data processing relationship, even though the wording change is subtle.
Third-party sharing. Privacy policies disclose who receives personal data. Between versions, watch for new categories of recipients (advertising partners, data brokers, affiliated companies) and changes to the characterization of sharing. Under the CCPA, a distinction exists between "selling" and "sharing" personal information, and both trigger opt-out rights. A privacy policy change that reclassifies a data transfer from "service provider processing" to "sharing for cross-context behavioral advertising" has regulatory implications even if the underlying data flow does not change.
Retention periods
Data retention is one of the areas where privacy policies most frequently fall short of regulatory requirements, and where changes between versions can create compliance gaps.
Specific vs. vague retention language. The GDPR's storage limitation principle requires that personal data not be kept longer than necessary for the purposes for which it is processed. A privacy policy that states "we retain your data for as long as necessary to provide our services" is vague and may not satisfy regulatory expectations. Compare retention language between versions. A change from specific retention periods ("account data is retained for 3 years after account closure") to vague language ("data is retained for as long as necessary") is a weakening that may indicate the organization is moving away from defined retention schedules.
Retention period changes. In a DPA, the data retention and deletion provisions specify how long the processor may retain personal data after the processing relationship ends. Between versions, watch for extensions of the retention period and changes to the deletion obligation. A DPA that previously required deletion within 30 days of contract termination but now allows retention "for up to 180 days for backup and archival purposes" extends the window during which the processor holds controller data after the relationship has ended.
Subprocessor lists and management
Subprocessor management is the most operationally intensive part of DPA compliance, and the subprocessor list is the provision that changes most often.
Subprocessor additions. When a processor adds a new subprocessor, the controller needs to know: who the subprocessor is, what processing they perform, where they are located, and what data protection measures they have in place. Between DPA versions, compare the subprocessor list (usually in an annex or at a URL referenced in the DPA) for additions and removals. A new subprocessor in a jurisdiction without a GDPR adequacy decision triggers a transfer impact assessment obligation.
Objection rights. GDPR Article 28 requires that controllers be given an opportunity to object to new subprocessors. DPAs implement this requirement differently. Some provide advance notice and a specified objection window (14 to 30 days). Others provide notice but specify that the controller's only remedy for objection is termination of the agreement. Between versions, watch for changes to the objection mechanism. A change from "Controller may object and Processor shall not engage the subprocessor for Controller's data" to "Controller may object by terminating the Agreement" removes a meaningful right and replaces it with a commercially impractical one.
Subprocessor URL references. Many DPAs do not list subprocessors in the agreement itself but reference a URL where the current list is maintained. This allows the processor to update the list without amending the DPA. Between DPA versions, watch for changes from an in-document list to a URL reference. This structural change means the subprocessor list can now change without triggering a DPA amendment, and the controller must independently monitor the URL for updates.
Breach notification timelines
Breach notification is where privacy documents intersect most directly with regulatory requirements, and where changes between versions can create compliance exposure.
Notification to controllers (DPAs). GDPR Article 33 requires controllers to notify the supervisory authority within 72 hours of becoming aware of a personal data breach. For the controller to meet this obligation, the processor must notify the controller promptly. DPAs specify the processor's notification timeline. Between versions, watch for changes from specific timelines ("within 24 hours" or "within 48 hours") to subjective standards ("without undue delay" or "promptly"). While "without undue delay" is the GDPR's own language for controller-to-authority notification, a processor that takes 48 hours to notify the controller, followed by the controller needing time to assess and report, may leave the controller with insufficient time to meet the 72-hour regulatory deadline.
Notification to individuals (privacy policies). Privacy policies often describe how the organization will notify affected individuals in the event of a breach. Between versions, watch for changes to the notification method (email vs. website posting), the information provided in the notification, and any qualifications on the notification obligation. A change from "we will notify affected users by email" to "we will post a notice on our website" reduces the likelihood that individual users will actually learn of the breach.
Breach definition. What constitutes a "breach" or "security incident" varies between DPA versions. A broad definition that includes unauthorized access, accidental disclosure, and loss of availability triggers notification for more events. A narrow definition that covers only confirmed unauthorized access to personal data may exclude incidents that regulators would consider reportable. Between versions, watch for narrowing of the breach definition.
Data subject rights
Both privacy policies and DPAs address data subject rights: access, rectification, erasure, data portability, restriction of processing, and objection. Changes to these provisions affect both regulatory compliance and user experience.
Scope of supported rights. Different regulations grant different rights. The GDPR provides a right to data portability; some US state laws do not. The CCPA provides a right to opt out of the sale of personal information; the GDPR addresses this through the right to object. Between privacy policy versions, check whether new rights have been added (reflecting new regulatory requirements) or whether existing rights have been narrowed. A privacy policy that previously offered erasure to all users but now limits it to "users in jurisdictions where erasure is required by law" may be reducing its commitments while technically remaining compliant.
Response timelines. The GDPR requires responses to data subject requests within one month, extendable by two months for complex requests. The CCPA requires responses within 45 days, extendable by an additional 45 days. Between DPA versions, check the processor's commitments to assist the controller in responding to data subject requests. A change from "Processor shall respond to Controller's data subject request assistance requests within 5 business days" to "Processor shall provide reasonable assistance" removes a specific commitment and replaces it with an undefined one.
Verification and authentication. Organizations must verify the identity of individuals making data subject requests to prevent unauthorized disclosure. Between privacy policy versions, watch for changes to the verification process. Overly burdensome verification requirements (requiring notarized identification to exercise a right to access) may functionally prevent individuals from exercising their rights.
Cross-border transfer mechanisms
Cross-border data transfers are one of the most complex and frequently changing areas of privacy law. The legal mechanisms for transferring personal data outside the EEA have changed multiple times: Safe Harbor was invalidated in 2015, Privacy Shield was invalidated in 2020, and the EU-US Data Privacy Framework was adopted in 2023. Each change has required updates to privacy documents.
Standard Contractual Clauses (SCCs). SCCs are the most widely used transfer mechanism. The current version (adopted June 2021) is modular, with four modules covering different transfer scenarios. Between DPA versions, check which SCC modules are incorporated, which optional clauses are included, and what the annexes contain. The annexes specify the technical and organizational measures the data importer implements. A change to the annex that removes a security measure or adds a qualification may weaken the transfer safeguards.
Adequacy decisions. When the European Commission determines that a third country provides adequate data protection, transfers to that country do not require SCCs or other safeguards. Between privacy document versions, watch for changes that rely on new adequacy decisions (such as the EU-US Data Privacy Framework) and confirm that the data importer is actually covered by the applicable framework. The EU-US DPF requires self-certification by the US entity; an entity that is not self-certified cannot rely on the adequacy decision.
Transfer impact assessments. Following the Schrems II decision, organizations relying on SCCs must conduct transfer impact assessments to evaluate whether the laws of the destination country provide adequate protection. Between DPA versions, check whether the transfer impact assessment provisions have changed. A processor that previously committed to conducting transfer impact assessments and sharing them with the controller but now reserves the right to conduct assessments "in its sole discretion" reduces the controller's ability to evaluate transfer risk.
Liability and indemnification in DPAs
DPA liability provisions determine the financial consequences of a data protection failure. These provisions interact with the main service agreement's liability clauses, and inconsistencies between the two create ambiguity.
Liability caps. Some DPAs include their own liability caps, separate from the main agreement. Others state that liability under the DPA is subject to the caps in the main agreement. Between versions, watch for the introduction of DPA-specific caps (which may be lower than the main agreement caps), changes to whether data protection liability is carved out of the main agreement's cap, and changes to whether regulatory fines are included in or excluded from the cap. A DPA that caps the processor's data protection liability at "the total fees paid in the 12 months preceding the breach" may provide inadequate recovery for a breach that results in significant regulatory fines.
Indemnification for regulatory fines. Under GDPR Article 83, supervisory authorities can impose fines of up to 4% of annual global turnover. The question of who bears the cost of regulatory fines arising from a processor's failure is often addressed (or not addressed) in the DPA. Between versions, watch for changes to indemnification provisions related to fines. A processor that previously indemnified the controller for fines arising from the processor's breach of the DPA but now excludes regulatory fines from indemnification shifts a significant financial risk to the controller.
Tracking regulatory changes across versions
Privacy document comparisons require an additional layer of analysis that other contract comparisons do not: each change needs to be assessed against the applicable regulatory requirements, not just against the business relationship.
Regulatory floor. Privacy regulations establish minimum requirements. A privacy policy can provide more protection than the regulation requires, but it cannot provide less. When comparing versions, assess each change against the regulatory floor. A change that weakens a provision but still meets the minimum regulatory requirement is a business decision. A change that falls below the regulatory floor is a compliance issue that requires escalation regardless of the commercial context.
Multi-jurisdictional analysis. Organizations that operate across jurisdictions must comply with all applicable privacy laws simultaneously. A privacy policy change that satisfies GDPR requirements may fall short of California's CCPA requirements, or vice versa. When comparing versions, assess changes against every applicable regulation, not just the most restrictive one. A change that appears to strengthen one regulatory compliance posture may inadvertently weaken another.
How to structure a privacy document comparison
Privacy document comparisons benefit from a structured approach that accounts for both the contractual and regulatory dimensions.
Step 1: Identify the trigger. Why was the document updated? Regulatory change, product change, vendor change, or routine annual update? The trigger tells you where to focus. A regulatory-driven update probably affects rights, retention, and transfer provisions. A product-driven update probably affects data collection scope and processing purposes.
Step 2: Compare data scope and purpose provisions first. These are the provisions that determine the fundamental scope of the data relationship. If the data categories or processing purposes changed, everything downstream is affected: retention, transfers, rights, and security measures all depend on what data is being processed and why. Run the comparison and start with these sections.
Step 3: Check subprocessor and transfer provisions. For DPAs, compare the subprocessor list and cross-border transfer mechanisms. New subprocessors in new jurisdictions may trigger transfer impact assessment obligations. Changes to SCC modules or adequacy decision reliance affect the legal basis for transfers.
Step 4: Review breach notification and security. Compare notification timelines, breach definitions, and security measure commitments. These provisions directly affect your incident response capabilities. A change from a 24-hour notification timeline to "without undue delay" changes your incident response plan.
Step 5: Assess every change against the regulatory floor. For each change identified, determine whether the revised provision meets the minimum requirements of every applicable privacy law. This step requires familiarity with the applicable regulations, and it cannot be done purely by comparing the two document versions. The comparison surfaces the changes; the regulatory assessment determines whether the changes are acceptable.
Step 6: Check for cross-document consistency. Privacy policies, DPAs, cookie policies, and the main service agreement may all address data handling. A DPA that limits processing to "providing the contracted service" but a privacy policy that permits "analytics and product improvement" creates an inconsistency that may expose the controller. After comparing each document individually, verify consistency across the document set.
The bottom line
Privacy documents are living documents. They change more often than most contracts, driven by a regulatory environment that has not stabilized and by business practices that evolve with every product launch and vendor relationship. Each change needs to be reviewed twice: once against the previous version to understand what is different, and once against the applicable regulations to confirm the change is compliant.
The comparison discipline is not optional. Under the GDPR, controllers are accountable for their processors' data handling practices. Under the CCPA, businesses are responsible for their service providers' compliance. When a vendor updates their DPA or privacy policy, the legal responsibility for understanding the implications rests with you. A two-minute comparison that surfaces every change is materially better than a trust-based assumption that "the vendor updated their terms for routine reasons."
If you are comparing privacy policies or DPAs and need a tool that surfaces every change, including the subprocessor list additions and notification timeline adjustments that affect your regulatory compliance posture, try Clausul.
Frequently asked questions
What is the difference between a privacy policy and a data processing agreement?
A privacy policy is a public-facing document that tells individuals (consumers, users, website visitors) how an organization collects, uses, stores, and shares their personal data. It is a one-to-many disclosure required by laws like the GDPR and CCPA. A data processing agreement (DPA) is a contract between two parties, typically a data controller (the company that determines why and how data is processed) and a data processor (the company that processes data on the controller behalf). The DPA governs the processor obligations regarding security, subprocessors, breach notification, data subject rights, and data transfers. Privacy policies are unilateral; DPAs are bilateral contracts. Both change frequently, and both require comparison when updated.
How often do privacy policies change?
Major organizations update their privacy policies one to four times per year. Changes are driven by new product features that involve additional data collection, regulatory updates (new state privacy laws, GDPR enforcement guidance, adequacy decisions), changes to data sharing practices with third parties, and updates to data retention periods. Many companies notify users of changes via email or in-app notification, but the notifications rarely specify what actually changed. Comparing the updated policy against the previous version is the only reliable way to identify the substantive differences. Companies subject to the GDPR must provide notice of material changes and may need to obtain renewed consent depending on the legal basis for processing.
What should I look for when a vendor updates their DPA?
Focus on five areas. First, the subprocessor list: were subprocessors added or removed, and do any new subprocessors involve cross-border transfers to jurisdictions without adequacy decisions? Second, breach notification timelines: did the notification period change (48 hours to 72 hours, or from a specific timeframe to "without undue delay")? Third, data transfer mechanisms: are the Standard Contractual Clauses still current, and has the vendor added or changed its transfer impact assessment? Fourth, audit rights: can you still audit the processor, or has the right been replaced with SOC 2 report access only? Fifth, liability and indemnification: has the vendor capped or excluded liability for data protection breaches? Each of these changes directly affects your compliance posture under the GDPR and other applicable privacy laws.
Do I need a separate DPA for each vendor?
Under the GDPR, you need a data processing agreement with every processor that handles personal data on your behalf. This includes cloud infrastructure providers, email service providers, analytics tools, customer support platforms, payroll processors, and any other vendor that accesses personal data of your customers, employees, or users. Many vendors provide a standard DPA as part of their service terms. The question is whether their standard DPA meets your obligations as a controller. Compare each vendor DPA against your requirements, because not all standard DPAs include adequate subprocessor controls, audit rights, or breach notification timelines. If a vendor DPA falls short, you need to negotiate supplementary terms or reconsider the vendor.
How do Standard Contractual Clauses (SCCs) affect privacy document comparisons?
Standard Contractual Clauses are pre-approved contract templates issued by the European Commission for transferring personal data outside the EEA to countries without adequacy decisions. The current SCCs (adopted June 2021) are modular, meaning parties select the modules that apply to their relationship (controller-to-controller, controller-to-processor, processor-to-processor, or processor-to-controller). When comparing DPAs that incorporate SCCs, check which modules are selected, whether the optional clauses within each module are included or excluded, and what the annexes contain (the annexes specify the data subjects, data categories, processing purposes, and technical and organizational measures). A vendor that changes which SCC modules are selected, or that modifies the annexes, may be changing the legal basis for the data transfer even though the core SCC text remains unchanged.
What happens if a privacy policy or DPA conflicts with a privacy regulation?
The regulation prevails. A privacy policy that says the company retains data indefinitely conflicts with the GDPR storage limitation principle. A DPA that excludes breach notification obligations conflicts with Article 33. These conflicts do not override the law, and the company is still required to comply regardless of what the policy says. But they create operational risk: the company may follow its own policy instead of the regulation, creating a compliance gap. When comparing privacy documents, flag any provisions that fall below regulatory minimums. A DPA that provides 30-day breach notification when the GDPR requires notification within 72 hours is not just a bad contract term. It is evidence that the processor may not have the processes in place to meet the regulatory requirement.