How to Ensure Your Privacy Policy Is GDPR-Compliant

Articles 13 and 14 of the GDPR establish detailed transparency requirements. These aren't suggestions; they're mandatory disclosures that must be provided in concise, transparent, intelligible, and easily accessible form, using clear and plain language.

Mandatory Disclosures Under Article 13

When collecting data directly from individuals, your privacy policy must include:

• Identity and contact details of the controller - The legal entity name, not just a brand name. Include a physical address and email contact.
• Contact details of the Data Protection Officer - If you've appointed one (see Section 6).
• Purposes of processing - Specific, granular purposes for each processing activity, not vague statements like "to improve our services."
• Legal basis - The specific legal basis under Article 6 GDPR for each purpose: consent, contract, legal obligation, vital interests, public task, or legitimate interests.
• Legitimate interests - If relying on legitimate interests, you must identify what those interests are.
• Recipients or categories of recipients - Who receives the data, including third-party service providers, advertising networks, analytics providers, and any other data recipients.
• International transfers - Information about transfers to third countries or international organizations, including the transfer mechanism and safeguards.
• Retention period - How long you keep personal data, or if that's not possible, the criteria used to determine retention periods.
• Data subject rights - Existence of rights to access, rectification, erasure, restriction, portability, and objection.
• Right to withdraw consent - If processing is based on consent, the right to withdraw at any time.
• Right to lodge a complaint - The right to lodge a complaint with a supervisory authority.
• Contractual requirement - Whether provision of data is a statutory or contractual requirement, and the consequences of not providing it.
• Automated decision-making - The existence of automated decision-making, including profiling, and meaningful information about the logic involved and consequences.

Additional Requirements for Secondary Data

If you obtain data from sources other than the data subject (Article 14), you must also disclose:

• The categories of personal data concerned
• The source of the personal data, and if applicable, whether it came from publicly accessible sources

These disclosures must be provided within one month of obtaining the data, at the latest.

The Layered Approach

I recommend a layered privacy notice approach for compliance with both GDPR and usability requirements:

1. Just-in-time notices - Brief contextual notices at the point of data collection
2. Short-form notice - A concise summary highlighting key points
3. Full privacy policy - Complete disclosures meeting all Article 13/14 requirements

This approach satisfies the GDPR's emphasis on clear and accessible information while providing comprehensive disclosures for those who want detailed information.

Many US businesses operate under both GDPR (for EU users) and California privacy laws (for California residents). Understanding the differences is critical for developing a unified compliance strategy.

Jurisdictional Scope

• GDPR - Applies based on location of data subjects (EU residents) and targeting/monitoring of EU individuals
• CCPA/CPRA - Applies based on business activity in California and processing of California residents' data

Legal Basis for Processing

• GDPR - Requires identification of a lawful basis (Article 6) before processing. Processing without a lawful basis is prohibited.
• CCPA/CPRA - No general "lawful basis" requirement. Instead, focuses on providing notice and honoring opt-out rights for sales/sharing, and opt-in for sensitive personal information.

This is a fundamental structural difference. Under GDPR, you must justify why you're allowed to process data. Under CCPA/CPRA, you can generally process data but must give consumers control over certain uses.

Consent Requirements

• GDPR - When consent is the legal basis, it must be freely given, specific, informed, and unambiguous. Affirmative action required (opt-in). Pre-checked boxes prohibited. Consent must be as easy to withdraw as to give.
• CPRA - Opt-in consent required for processing sensitive personal information beyond necessary uses. Opt-in also required for selling/sharing data of consumers under 16.

Consumer/Data Subject Rights

Right	GDPR	CCPA/CPRA
Access	✓ Right to access	✓ Right to know
Deletion	✓ Right to erasure	✓ Right to delete
Portability	✓ (structured format)	✗ Not included
Correction	✓ Right to rectification	✓ Right to correct
Opt-out of sale	✗ (consent required upfront)	✓ Right to opt-out
Restrict processing	✓ Right to restriction	✓ Right to limit (CPRA)
Object to processing	✓ Broad objection right	Limited (mainly sales/sharing)

Penalties and Enforcement

• GDPR - Up to €20 million or 4% of annual global turnover (whichever is higher). Administrative fines issued by supervisory authorities.
• CPRA - Up to $2,500 per violation or $7,500 per intentional violation. Enforced by California Privacy Protection Agency and Attorney General. Private right of action for data breaches.

Practical Approach for Dual Compliance

I advise clients to:

1. Use GDPR as the baseline - GDPR is generally more stringent. If you comply with GDPR, you're likely close to CPRA compliance.
2. Segment users by jurisdiction - Use geolocation to provide jurisdiction-specific notices and controls.
3. Harmonize where possible - Provide the highest level of protection globally rather than maintaining separate systems (privacy by design approach).
4. Document legal bases carefully - Map GDPR legal bases to your processing activities, even if not strictly required under CCPA/CPRA.

Based on Articles 13 and 14 GDPR, here are the 12 essential elements every privacy policy must include, with practical examples.

1. Identity and Contact Details of the Controller

Required: Legal entity name, physical address, email, phone (optional)

Example: "The data controller is Acme Software Inc., a Delaware corporation, located at 123 Market Street, San Francisco, CA 94103. You can contact us at privacy@acmesoftware.com."

2. Data Protection Officer Contact Details

Required: Name (or position title) and contact information if DPO appointed

Example: "Our Data Protection Officer is Jane Smith. You can contact her at dpo@acmesoftware.com or at the address above, marked 'Attention: DPO'."

3. Purposes of Processing

Required: Specific purposes for each category of data processing

Bad example: "We use your data to provide and improve our services."

Good example: "We process your personal data for the following purposes: (1) Account creation and authentication, (2) Processing your orders and payments, (3) Providing customer support, (4) Sending transactional communications about your account, (5) Analyzing usage patterns to improve platform performance, (6) Detecting and preventing fraud."

4. Legal Basis for Each Processing Activity

Required: Identification of Article 6(1) legal basis for each purpose

Example:

• Account creation: Contract performance (Article 6(1)(b))
• Payment processing: Contract performance (Article 6(1)(b))
• Marketing emails: Consent (Article 6(1)(a))
• Fraud prevention: Legitimate interests (Article 6(1)(f)) - our legitimate interest in protecting our platform and users from fraudulent activity
• Tax compliance: Legal obligation (Article 6(1)(c))

5. Categories of Personal Data

Required: Specific categories collected

Example: "We collect the following categories of personal data: Identity data (name, username), Contact data (email address, phone number), Financial data (payment card details via our processor), Transaction data (purchase history, order details), Technical data (IP address, browser type, device information), Usage data (how you interact with our platform), Marketing preferences."

6. Recipients or Categories of Recipients

Required: Who receives the data, including sub-processors

Example: "We share your personal data with: Payment processors (Stripe, Inc.), Cloud hosting providers (Amazon Web Services), Email service providers (SendGrid), Analytics providers (Google Analytics, Mixpanel), Customer support platform (Zendesk), Advertising networks (for users who consent to marketing)."

7. International Data Transfers

Required: Information about transfers outside the EEA, including safeguards

Example: "Your personal data may be transferred to and processed in the United States and other countries outside the European Economic Area. We ensure these transfers are protected through: (1) Standard Contractual Clauses approved by the European Commission, (2) Additional technical and organizational measures including encryption in transit and at rest, access controls, and regular security audits. You may request copies of the Standard Contractual Clauses by contacting privacy@acmesoftware.com."

8. Retention Periods

Required: How long data is kept, or criteria for determining retention

Example: "We retain personal data for the following periods: Account data - for the duration of your account plus 6 months after closure; Transaction data - 7 years to comply with tax and accounting requirements; Marketing communications data - until you withdraw consent plus 30 days; Technical logs - 90 days."

9. Data Subject Rights

Required: Explanation of rights and how to exercise them

Example: "You have the right to: (1) Access your personal data and receive a copy, (2) Rectify inaccurate data, (3) Erase your data in certain circumstances, (4) Restrict processing in certain circumstances, (5) Object to processing based on legitimate interests, (6) Data portability for data processed based on consent or contract, (7) Withdraw consent at any time. To exercise these rights, email privacy@acmesoftware.com or use the privacy controls in your account settings. We will respond within one month."

10. Right to Withdraw Consent

Required: If consent is the legal basis, how to withdraw it

Example: "Where we process your data based on consent, you may withdraw that consent at any time by clicking the 'unsubscribe' link in marketing emails, adjusting your preferences in account settings, or contacting privacy@acmesoftware.com. Withdrawal of consent does not affect the lawfulness of processing before withdrawal."

11. Right to Lodge a Complaint

Required: Information about the right to complain to a supervisory authority

Example: "You have the right to lodge a complaint with a data protection supervisory authority, particularly in the EU member state of your residence, workplace, or where an alleged infringement occurred. A list of supervisory authorities is available at https://edpb.europa.eu/about-edpb/board/members_en."

12. Automated Decision-Making and Profiling

Required: Information about existence, logic, significance, and consequences

Example: "We use automated decision-making for fraud detection. Our system analyzes transaction patterns, device information, and behavioral signals to identify potentially fraudulent activity. If our system flags a transaction, we may temporarily hold the order for manual review. This helps protect you and other users from fraud. You have the right to: (1) Obtain human intervention, (2) Express your point of view, (3) Contest the decision. Contact fraud@acmesoftware.com to exercise these rights."

Use this tool to assess your privacy policy's GDPR compliance. Answer the questions below to receive a compliance score and identify gaps.

I've reviewed hundreds of privacy policies and identified recurring mistakes that create enforcement risk.

1. Pre-Checked Consent Boxes

The violation: Using pre-checked boxes for consent to data processing or marketing.

Why it matters: GDPR requires consent to be an affirmative act. Pre-checked boxes constitute invalid consent. The CJEU confirmed in Planet49 (Case C-673/17) that consent must involve active opt-in.

Penalty example: €10 million fine against H&M for various violations including deficient consent mechanisms.

2. Vague or Bundled Purposes

The violation: Combining multiple purposes into vague categories like "to improve our services" or bundling unrelated purposes together.

Why it matters: Consent must be specific and granular (Article 4(11) GDPR). The purpose limitation principle (Article 5(1)(b)) requires that data be collected for specified, explicit, and legitimate purposes.

Fix: List distinct purposes separately: "analytics to improve platform performance," "targeted advertising based on your interests," "product development research."

3. Failing to Identify Legal Basis

The violation: Not stating which Article 6 legal basis applies to each processing activity.

Why it matters: Controllers must identify a lawful basis before processing (Article 6). Supervisory authorities view failure to identify legal basis as a fundamental compliance failure.

Enforcement example: Norwegian DPA fined Grindr €9.63 million partly for invalid consent serving as an inadequate legal basis for sharing data with advertising partners.

4. Cookie Walls

The violation: Conditioning access to your website or service on consent to non-essential cookies.

Why it matters: GDPR consent must be "freely given" (Article 4(11)). The CJEU ruled in Planet49 that consent is not freely given if the user cannot refuse without detriment.

Current guidance: EDPB states that cookie walls are generally prohibited. France's CNIL issued guidance in 2020 stating cookie walls violate GDPR.

Acceptable alternative: Pay-or-consent models where users can choose between: (1) free access with targeted advertising, or (2) paid subscription with no tracking. This must be a genuine choice with equivalent access.

5. Inadequate International Transfer Disclosures

The violation: Not disclosing transfers to third countries or failing to identify transfer mechanisms.

Why it matters: Post-Schrems II, international transfers are a major enforcement priority. Supervisory authorities require detailed disclosures about where data goes and how it's protected.

Fix: Identify: (1) Countries where data is transferred, (2) Transfer mechanism (SCCs, adequacy decision, BCRs), (3) Additional safeguards implemented (encryption, access controls, data minimization).

6. No Data Subject Request Process

The violation: Privacy policy doesn't explain how users can exercise their rights, or the process is unclear/burdensome.

Why it matters: Articles 15-22 create enforceable individual rights. Controllers must facilitate exercise of these rights, not obstruct them.

Red flags: Requiring physical mail, notarization, excessive identity verification, or charging fees without justification.

Fix: Provide multiple contact methods (email, web form, in-app controls). Respond within one month. Don't charge fees unless requests are manifestly unfounded or excessive.

7. Missing DPIA Triggers

The violation: Conducting high-risk processing without a Data Protection Impact Assessment.

Why it matters: Article 35 requires DPIAs for processing likely to result in high risk to individuals' rights and freedoms. Failure to conduct required DPIAs can lead to fines.

Triggers: Systematic monitoring, large-scale processing of special categories, automated decision-making with legal or similar effects, processing of vulnerable individuals, new technologies, denial of service.

8. Combining Consent with Terms Acceptance

The violation: "By clicking 'I agree,' you accept our Terms of Service and consent to data processing as described in our Privacy Policy."

Why it matters: Bundling consent with contract acceptance makes consent non-voluntary. EDPB Guidelines 05/2020 state consent cannot be bundled as a condition of contract performance if the processing isn't necessary for the contract.

Fix: Separate consent requests from terms acceptance. Use contract performance as the legal basis for necessary processing, and obtain separate consent for optional processing (marketing, analytics, etc.).

9. Not Maintaining ROPA

The violation: Failure to maintain Records of Processing Activities under Article 30.

Why it matters: ROPA is mandatory for organizations with 250+ employees or those engaging in regular high-risk processing. Supervisory authorities request ROPA during audits; absence suggests lack of compliance infrastructure.

What to document: Processing purposes, data categories, recipients, international transfers, retention periods, security measures.

10. Unlawful Sub-Processor Practices

The violation: Not disclosing sub-processors, or not providing a mechanism for objection to new sub-processors.

Why it matters: Article 28(2) and (4) require controllers to authorize sub-processors. Data subjects need visibility into who processes their data.

Fix: Maintain a list of sub-processors in your privacy policy or a linked page. Implement a notification mechanism when adding new sub-processors and provide an objection process.

Article 35 GDPR requires a Data Protection Impact Assessment when processing is "likely to result in a high risk to the rights and freedoms of natural persons."

Mandatory DPIA Triggers

Article 35(3) identifies three situations requiring a DPIA:

1. Systematic and extensive evaluation based on automated processing - Including profiling, on which decisions are based that produce legal effects or similarly significantly affect individuals
2. Large-scale processing of special categories of data - Article 9 data (health, race, religion, etc.) or Article 10 data (criminal convictions)
3. Systematic monitoring of publicly accessible areas on a large scale - Such as extensive CCTV surveillance

Additional High-Risk Indicators (EDPB Guidelines)

The European Data Protection Board published Guidelines 4/2021 listing criteria that indicate high risk:

• Evaluation or scoring (creditworthiness, insurance risk, health, personal preferences)
• Automated decision-making with legal or similar significant effect
• Systematic monitoring
• Sensitive data or data of a highly personal nature
• Data processed on a large scale
• Matching or combining datasets
• Data concerning vulnerable data subjects (children, employees, elderly, mentally ill)
• Innovative use or application of technological or organizational solutions
• Processing that prevents data subjects from exercising a right or using a service

If your processing meets two or more of these criteria, a DPIA is likely required.

Supervisory Authority DPIA Lists

Many supervisory authorities maintain lists of processing operations requiring DPIAs. For example:

• France (CNIL) - Requires DPIA for health apps, credit scoring, large-scale biometric authentication, employee monitoring, geolocation tracking
• UK (ICO) - Requires DPIA for large-scale profiling, biometric data for unique identification, genetic data processing, systematic monitoring
• Germany - Requires DPIA for processing visible to the public, processing on a large scale, automated decision-making

DPIA Process and Content

A compliant DPIA must include (Article 35(7)):

1. Systematic description of processing operations - What data, what purposes, what technology, who has access, retention periods
2. Assessment of necessity and proportionality - Why this processing is necessary for your purposes, whether the same purposes could be achieved with less intrusive means
3. Assessment of risks - Identification of risks to individuals' rights and freedoms, considering likelihood and severity
4. Measures to address risks - Security measures, safeguards, mechanisms to ensure protection of personal data and demonstrate compliance

When to Consult the Supervisory Authority

Article 36 requires prior consultation with the supervisory authority if the DPIA indicates high residual risk that cannot be mitigated. This is mandatory before beginning the processing.

The supervisory authority has up to 8 weeks (extendable to 14 weeks for complex cases) to provide written advice. Proceeding without required consultation can result in enforcement action.

Practical DPIA Examples

SaaS Analytics Platform

Scenario: A SaaS company implements behavioral analytics that tracks all user interactions, builds user profiles, and uses machine learning to predict churn risk and personalize features.

DPIA required? Yes - meets multiple criteria: systematic monitoring, evaluation/scoring, automated decision-making affecting user experience, large-scale processing.

Key considerations: Data minimization (only collect necessary events), purpose limitation (separate analytics from marketing), user controls (opt-out), transparency (explain profiling logic).

HR Background Check System

Scenario: An employer implements automated background check processing that screens criminal records, credit history, and social media for all job applicants.

DPIA required? Yes - processing sensitive data (criminal records), automated decision-making affecting employment, vulnerable subjects (job applicants in unequal power relationship), large scale if processing many applicants.

Key considerations: Legal basis (likely legitimate interests, possibly legal obligation), necessity (is all this data needed?), human oversight (no fully automated rejection), data retention (delete after hiring decision).

The Schrems II decision (Case C-311/18, July 2020) invalidated the EU-US Privacy Shield and established stricter requirements for international transfers. Understanding these requirements is critical for US-based businesses.

The Schrems II Holding

The Court of Justice of the European Union ruled that:

1. The Privacy Shield is invalid because US surveillance laws (FISA 702, EO 12333) don't provide adequate protection for EU data subjects
2. Standard Contractual Clauses (SCCs) remain valid BUT controllers must assess whether the destination country's laws undermine the protections in the SCCs
3. If such laws exist, controllers must implement supplementary measures to ensure essentially equivalent protection

Transfer Mechanisms Still Available

1. Adequacy Decisions (Article 45)

The European Commission has recognized certain countries as providing adequate data protection:

• Andorra, Argentina, Canada (commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, United Kingdom, Uruguay
• United States - Data Privacy Framework (DPF) adopted July 2023, replacing Privacy Shield. Provides adequacy for certified US organizations.

Note: The Data Privacy Framework faces legal challenges and may suffer the same fate as Privacy Shield. I advise implementing SCCs as a backup mechanism.

2. Standard Contractual Clauses (SCCs)

The European Commission issued updated SCCs in June 2021 (Decision 2021/914). These replace the old model clauses and must be used for new contracts.

Key features of new SCCs:

• Modular structure for different transfer scenarios (controller-to-controller, controller-to-processor, processor-to-processor, processor-to-controller)
• Docking clause allowing third parties to join
• Specific provisions on government access requests
• Requirements for risk assessment and supplementary measures

3. Binding Corporate Rules (BCRs)

For multinational corporations, BCRs allow intra-group transfers. These require supervisory authority approval and are resource-intensive to implement.

4. Derogations (Article 49)

Limited exceptions for specific situations:

• Explicit informed consent (after being informed of risks)
• Necessary for contract performance
• Important reasons of public interest
• Legal claims
• Vital interests
• Transfers from public registers
• Compelling legitimate interests (limited to occasional, non-repetitive transfers affecting limited data subjects)

Warning: Derogations are narrowly construed and cannot be used as a general transfer mechanism.

Transfer Impact Assessment (TIA)

The EDPB Recommendations 01/2020 require a Transfer Impact Assessment for all transfers to third countries without adequacy decisions.

TIA Process:

1. Know your transfers - Map all data flows to third countries, including indirect transfers through processors and sub-processors
2. Verify transfer tool - Confirm you're using valid SCCs (2021 version), BCRs, or appropriate derogation
3. Assess third country law - Evaluate whether the destination country's laws and practices impinge on the effectiveness of contractual safeguards
4. Identify supplementary measures - If risks identified, implement technical, organizational, or contractual measures
5. Formal procedural steps - Document the assessment; notify supervisory authority if required
6. Re-evaluate regularly - Monitor for changes in law or circumstances

Supplementary Measures for US Transfers

When transferring to the United States, I recommend these supplementary measures:

Technical Measures:

• End-to-end encryption - Encrypt data before transfer using keys held only in the EU. US processor cannot decrypt.
• Pseudonymization - Replace identifying fields with pseudonyms; maintain mapping table in EU only.
• Multi-party computation - Perform analytics on encrypted data without decryption.
• Data minimization - Transfer only the minimum necessary data; retain sensitive fields in EU.

Organizational Measures:

• Transparency policies - US data importer commits to notify EU controller of government access requests and to challenge disproportionate requests.
• Regular audits - Verify importer's compliance with SCCs and supplementary measures.
• Data Protection Impact Assessment - Document risks and mitigations for the specific transfer.

Contractual Measures:

• Enhanced notification clauses - Importer must notify controller of government requests (unless legally prohibited) and challenge overbroad requests.
• Data localization commitments - Importer commits not to transfer data outside designated jurisdiction.
• Audit rights - Controller has right to audit importer's security and compliance.

Privacy Policy Disclosures for International Transfers

Your privacy policy must disclose:

1. That transfers occur - "Your personal data may be transferred to and processed in countries outside the European Economic Area, including the United States."
2. Transfer mechanism - "We protect these transfers through Standard Contractual Clauses approved by the European Commission."
3. Supplementary measures - "We implement additional safeguards including encryption, access controls, and contractual commitments from our service providers."
4. How to obtain copies - "You may request a copy of the Standard Contractual Clauses by contacting privacy@company.com."
5. Risks - For transparency, consider: "While we implement these safeguards, you should be aware that countries outside the EEA may not provide the same level of data protection as your home country."

Specific Risks with US Cloud Providers

AWS, Google Cloud, Microsoft Azure, and other US cloud providers are potentially subject to FISA 702 and other surveillance laws. Recommended approach:

• Use EU regions - Store data in EU data centers (though legal access may still apply to US companies)
• Encryption - Use customer-managed encryption keys (CMEK) or bring-your-own-key (BYOK) solutions where the provider cannot access plaintext
• Contractual protections - Ensure SCCs are in place with cloud provider
• Consider EU alternatives - Evaluate EU-based cloud providers (OVHcloud, Scaleway, etc.) to avoid US CLOUD Act jurisdiction

Q: What is the GDPR?

The General Data Protection Regulation (GDPR) is an EU regulation that went into effect on May 25, 2018. It governs how organizations collect, process, and store personal data of individuals in the European Union. The GDPR applies to any business worldwide that processes the personal data of EU residents, regardless of where the company is located.

Q: Does the GDPR apply to my US-based business?

Yes, if you process personal data of EU residents. This includes businesses that target EU customers (e.g., EU-specific marketing, accept euros, provide EU shipping), collect data from EU visitors to your website, or process EU employee data. The GDPR has extraterritorial reach under Article 3(2) and applies based on where data subjects are located, not where your business operates.

Q: What are the 12 required elements of a GDPR-compliant privacy policy?

See Section 3 above for detailed analysis. The 12 elements are: (1) Controller identity/contact, (2) DPO contact (if applicable), (3) Processing purposes, (4) Legal basis for each activity, (5) Categories of personal data, (6) Recipients, (7) International transfers, (8) Retention periods, (9) Data subject rights, (10) Right to withdraw consent, (11) Right to complain, (12) Automated decision-making information.

Q: What is the legal basis for processing under GDPR?

Article 6 recognizes six legal bases: (1) Consent - freely given, specific, informed, and unambiguous; (2) Contract - processing necessary to perform a contract with the data subject; (3) Legal obligation - compliance with legal requirements; (4) Vital interests - protecting someone's life; (5) Public task - performing official functions; (6) Legitimate interests - pursuing legitimate business interests balanced against individual rights (requires balancing test).

Q: What are data subject rights under GDPR?

Data subjects have eight primary rights: (1) Right to be informed (Articles 13-14), (2) Right of access (Article 15), (3) Right to rectification (Article 16), (4) Right to erasure / right to be forgotten (Article 17), (5) Right to restrict processing (Article 18), (6) Right to data portability (Article 20), (7) Right to object (Article 21), (8) Rights related to automated decision-making and profiling (Article 22).

Q: When is a Data Protection Officer (DPO) required?

Article 37 requires a DPO if: (1) The controller is a public authority or body (with limited exceptions), (2) Core activities consist of processing operations requiring regular and systematic monitoring of data subjects on a large scale, or (3) Core activities consist of processing on a large scale of special categories of data (Article 9) or personal data relating to criminal convictions and offenses (Article 10). Even if not required, appointing a DPO demonstrates compliance commitment and can be beneficial.

Q: What is a Data Protection Impact Assessment (DPIA)?

A DPIA is a process to identify and minimize data protection risks in processing operations. Article 35 requires a DPIA when processing is likely to result in high risk to individuals' rights and freedoms, particularly for: new technologies, large-scale processing of special category data, systematic monitoring of public areas, profiling with legal effects, processing vulnerable individuals' data, innovative applications of technology. See Section 6 for detailed analysis.

Q: How are international data transfers handled after Schrems II?

After Schrems II invalidated Privacy Shield, transfers require: (1) EU adequacy decisions for approved countries (including US organizations certified under Data Privacy Framework), (2) Standard Contractual Clauses with Transfer Impact Assessment and supplementary measures, (3) Binding Corporate Rules, or (4) Specific derogations. Controllers must assess third-country laws and implement technical/organizational measures to ensure essentially equivalent protection. See Section 7.

Q: What is the 72-hour breach notification rule?

Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach likely to result in a risk to individuals' rights and freedoms. If the breach results in high risk, Article 34 requires notification to affected individuals without undue delay. Failure to notify when required can result in fines up to €10 million or 2% of annual global turnover under Article 83(4)(a).

Q: What is the difference between GDPR and CCPA/CPRA?

See Section 2 for comprehensive comparison. Key differences: (1) Jurisdictional scope (EU residents vs. California residents), (2) Legal basis requirement (GDPR requires lawful basis for all processing; CCPA focuses on notice and opt-out), (3) Consent standards (GDPR requires affirmative opt-in; CCPA allows opt-out for sales/sharing), (4) Penalties (GDPR up to €20M or 4% revenue; CPRA up to $7,500 per intentional violation), (5) Rights (GDPR includes portability and restriction; CPRA includes correction and automated decision-making limits).

Q: What are the most common privacy policy mistakes that trigger enforcement?

The top 10 mistakes I see are: (1) Pre-checked consent boxes, (2) Vague or bundled purposes, (3) Failing to identify legal basis for each activity, (4) Cookie walls conditioning access on consent, (5) Inadequate international transfer disclosures, (6) No clear data subject request process, (7) Not conducting required DPIAs, (8) Combining consent with terms acceptance, (9) Not maintaining Records of Processing Activities (ROPA), (10) Not disclosing sub-processors. See Section 5 for detailed analysis.

Q: What are Records of Processing Activities (ROPA)?

Article 30 requires controllers and processors to maintain written records documenting: (1) Name and contact details of controller/processor and DPO, (2) Purposes of processing, (3) Categories of data subjects and personal data, (4) Categories of recipients, (5) International transfers and safeguards, (6) Retention periods, (7) Technical and organizational security measures. ROPA is mandatory for organizations with 250+ employees or those regularly processing special categories, criminal data, or processing likely to result in risk to rights and freedoms.

Q: Can I use Google Analytics under GDPR?

This is currently controversial. Several EU supervisory authorities (Austria, France, Italy) ruled that Google Analytics violates GDPR due to data transfers to the US and insufficient safeguards against US surveillance. Alternatives: (1) Implement Google Analytics with enhanced privacy settings (IP anonymization, consent for cookies, SCCs), (2) Use EU-based analytics (Matomo, Plausible, Fathom), (3) Use Google Analytics 4 with Google signals disabled and EU data storage only. The safest approach is obtaining explicit consent before loading Google Analytics.

Q: How long do I have to respond to a data subject access request?

Article 12(3) requires response without undue delay and within one month of receipt. This can be extended by two further months for complex or numerous requests, but you must inform the data subject of the extension and reasons within the initial one-month period. The response must be free of charge unless requests are manifestly unfounded or excessive.

Q: Can I charge a fee for data subject requests?

Generally no. Article 12(5) states you can only charge a reasonable fee based on administrative costs, or refuse to act, if requests are manifestly unfounded or excessive (particularly if repetitive). You must demonstrate the request meets this high threshold. Charging fees for standard requests violates GDPR and can result in enforcement.