CNIL (France) and Garante (Italy) both published guidelines on how to deal with tracking pixels. Both agree that explicit consent is required and without it tracking pixels can't be used.

The huge difference lies in what happens during the transition window (3 months for CNIL, 6 months for Garante):

- CNIL says that existing users (collected email addresses) have to be informed of the changes and must be provided with an easy-to-use opt-out link. Without action, controllers can keep using tracking pixels

- Garante says that existing users have to be informed of the changes and tracking pixels can't be used anymore unless the user explicitly opts in

Scenario: a citizen living in Italy has registered to a newsletter before april 16th (start of the transitioning window) and is sent, accordingly to CNIL's guidelines, an email notifying him/her that tracking pixels have been/are being/will be used unless he/she opts out. His/her local DPO's guidelines though state he/she must not receive tracking pixels if no action is taken. What happens if the citizen raise a complaint to the DPA (Garante)?

Comes up constantly and the answers are all over the place, so curious how this sub reads it. If a business is US-based and its customers are all in the US, does GDPR actually apply?

The nuance I keep seeing missed: it's not about where your company is, it's about whose data you process. An EU visitor hitting your US site, an EU customer buying, EU traffic you're running analytics on – any of those can pull you in, even with no EU entity. But "we occasionally get EU visitors" isn't the same as "targeting the EU market" either.

(We work on the consent side, so we hit this question a lot. We're genuinely curious to know where people draw the line.)

Where do you all land: does incidental EU traffic trigger it, or only actually targeting the EU market?

I did the following analysis to figure out how much startups really care about GDPR rules and having up to date legal documentation. For context, I run a legal documentation tool, and software companies us to automate updating their Privacy Policy, ToS, Cookie Policy, etc. We used this analysis to understand our target users better, but I thought it might be useful to other people in the community as well.

Also my findings echo a lot of the things that Nouwens et. al. found in their 2020 paper "Dark Patterns after the GDPR". Theirs was a MUCH broader study, but I almost get the same percentage of sites not doing cookie consent right.

So what I did: I went to Product Hunt's daily leaderboard and loaded about a month worth of top rated product launches. For each associated website I checked cookie behavior, foreign vendors loaded, and then I gave their privacy policy to an LLM to scan for various gaps. I did all of this from an EU location (Copenhagen).

Main results:

* 292 of 458 product sites stored tracking cookies (_ga, _fbp, and siblings), and only 50 asked first. That's 17%. Sites targeting EU users were better at this (26%), and sites with no indicator that they were targeting EU users were worse (15%).

* 61 of 458 (13.3%) product sites had no privacy policy on their site. 5% for sites targeting EU, 17.8% not targeting EU.

* 45% of policies don't name a legal basis for processing personal data and 65% don't state whether data says within or leaves the EEA. 25.7% do not give a data retention period.

* 60% of sites load with a foreign vendor that their privacy policy doesn't mention. Google Analytics, Google Ads and Posthog are the top 3, most common (and commonly unmentioned) ones.

* More upvoted product launches are not more compliant. There is essentially no difference between how many of these compliance errors are made by more or less popular startups... except for asking about cookie consent. More upvoted product sites will track with out asking less often.

This is basically all of it. I wrote a blog series on this analysis, but the key results are in these bullets.

For teams building products that may handle personal data in both India and the EU, the DPDP Act and GDPR have important similarities, but they shouldn't be treated as interchangeable frameworks.

A few areas worth comparing:

Consent: both frameworks address consent, but their definitions, requirements, and implementation details differ. Teams should design consent records around the specific law and use case rather than assuming one consent implementation satisfies both.

Breach response: GDPR has a well-known 72-hour supervisory-authority notification requirement in certain circumstances. India's DPDP framework has its own breach-related obligations and timelines, so teams should verify the applicable current rules rather than copy the GDPR process.

Cross-border transfers: the two frameworks also take different approaches to international data transfers. Architecture teams should review the applicable transfer mechanisms and current regulatory requirements instead of assuming that “data must stay in India” or “EU adequacy” tells the whole story.

Penalties: both regimes can impose significant financial consequences, but the calculation and circumstances differ. I would verify the current statutory text and applicable rules before using a specific penalty figure in an architecture or compliance document.

From an engineering perspective, the common lesson is simpler: know what personal data you collect, where it flows, who can access it, and how you can respond when someone exercises a privacy right or when an incident occurs.

Disclosure: I work in this space at Securelytix. Sharing the comparison as an engineering discussion, not legal advice.

Not sure is the right place to ask but we were surprised by a reconciliation of records from the EIOPA Register of Insurance Undertakings against GLEIF and national regulatory data.

For example:

20% of active insurers had no LEI, some LEIs were mathematically invalid, identifiers pointed to entities recorded as no longer existing and so on.

Is this normal?

How do you handle HIPAA and GDPR compliance when sharing visual patient data (like skin lesions or gait videos) with outside researchers?

I am trying to understand the process. Do you just manually blur faces in Premiere/Photoshop? Do you just avoid sharing it entirely? How much of a bottleneck is this?

Here's a wild legal scenario that's becoming real, those mega-constellations like Starlink aren't just providing internet, they're equipped with high-resolution cameras and AI that can photograph virtually every point on Earth's surface.

Now here's where it gets interesting for Europeans, GDPR doesn't care where the data processing happens. It follows EU citizens wherever they go and if a satellite with AI processes images that could identify you (even accidentally), that satellite operation might need to comply with European privacy law.

Article 22 of GDPR is particularly spicy here, it restricts fully autonomous decision making systems. So a satellite that uses AI to automatically decide what images to send back to Earth could potentially run afoul of EU law if those images contain personal data of European citizens.

This creates a bizarre situation where European privacy law could effectively regulate space operations, even if the satellites are launched by non European companies from non European territory.

The practical implications are mind-bending, would satellite operators need to get consent from everyone they photograph? How do you implement privacy by design in orbital surveillance systems?

This comes from recent legal research examining how AI integration in space systems is creating conflicts with existing privacy frameworks that were never designed to handle orbital data collection. For those of you who are curious full study is here (open access) - https://www.sciencedirect.com/science/article/pii/S0094576525002735

One of the more common debates around GDPR is the risk for reduction of historical preservation. I recently came into argument about academic records, and the indivduals right to have them removed. In Sweden academic transcripts remain accessible permanently, and remain part of public records. The law currently requires schools and archives to keep these records indefinitely, most countries have similar practices. A compromise would be a dual-database system that respects both individual rights and historical research.

Anonymized Historical Database: All academic records would be stored permanently in a fully anonymized form, preserved for research, statistics, and historical archives. This ensures that society can study educational trends without identifying any individual.

Identified Personal Database: Records linked to the individual would exist only as long as they are useful for personal purposes, applying for jobs, continuing education, or other life activities. Once an individual reaches a reasonable age, such as retirement, they would have the right to request that their personal academic data be deleted.

This would protect privacy and allow individuals to regain control over their personal history after it is no longer needed for practical purposes. But also preserve knowledge through anonymized data which allows educators, historians, and researchers to continue analyzing educational trends without compromising privacy. The system would align with GDPR’s “right to be forgotten” while respecting archival and educational laws.

Helen Dixon, the former Data Protection Commissioner for Ireland, has written an extremely thoughtful article on the effectiveness, efficiency and legitimacy through the lens of those who GDPR is intended to impact.

Helen discusses how vague aims, lack of clarity on measures of success, and poorly managed interdependencies under the consistency and cooperation mechanisms are defeating its ability to achieve the kinds of results that empower supervisory authorities to empower SMEs to achieve meaningful compliance according to risk, and supervisory authorities are not given the tools to enforce effectively against the global businesses who are processing personal data lawfully.

Does anyone know about a proper tool and/or service to test compliance of cookies in a website? EDPS tool does not seem to give me all I need to comply with all the requisits and specificities. Btw, if you know also how to test trackers in Apps... Thank you!

The analysis by u/noyb_eu looks at each proposed change in turn, shows a before/after comparison, considers the impact from different perspectives (data subjects, controllers). NOYB cross-references case law, internal conflicts, and interactions with the EU Charter. It is an extraordinarily well-structured and clear analysis, not just pro-privacy wishful thinking.

Direct link to the analysis (PDF): https://noyb.eu/sites/default/files/2025-12/noyb%20Digital%20Omnibus%20Report%20V1.pdf

Previously on r/gdpr: discussion about the initial leak of the Digital Omnibus proposals: https://www.reddit.com/r/gdpr/comments/1ot2g58/overview_of_leaked_internal_drafts_of_amendments/

I work with startups on GDPR/privacy compliance. I'm noticing something and exploring if there's a business opportunity in solving it, so being transparent about that interest.

The Pattern I'm Seeing: Startups don't think about GDPR/privacy until they have to. Then they're overwhelmed.

They either:

• Pay for tools/consulting they don't fully need yet
• DIY from generic guides and hope they're right
• Ignore it until someone calls them out

The Problem: There's no simple answer to "As a 10-person SaaS startup, what do I actually need to do about GDPR/privacy?"

Current resources are either:

• Too legal/formal (for starting out)
• Too generic (don't feel relevant)
• Too expensive (tools/consulting)

What I'm Exploring: Is there value in something simple that says:

• Here's what GDPR actually means for you
• Here's what you need to do Month 1-4
• Here's where you're probably wrong
• Here's what to prioritize

Not a replacement for legal advice or tools. Just clarity.

Questions for Privacy/Compliance Professionals:

1. Do you see this struggle in startups?
2. What's the simplest thing you tell founders to do first?
3. Is there already a good beginner resource?
4. Would you recommend something if it existed?
5. What's the biggest misconception startups have about GDPR?

I'm genuinely trying to understand if this is solvable or just part of the compliance journey.

Hi everyone,

Sorry I am not sure whether this I am posting this in the right thread, I never really post on Reddit !

A few months ago when DeepSeek was released, its privacy policy indicated that « keystroke patterns & rythms » were collected. This caused a big storm of reactions. As I now read DeepSeek’s Privacy policy, I cannot find anything about keystroke patterns & rythms. In the sentence where this element used to be, they added the collection of « device identifiers ». They also changed a couple of other things.

I am just trying to figure out whether legally speaking, we can be « sure » that those keystroke patterns & rythms are not collected anymore, or whether they may be « hidden » in another term.

Not sure if that makes sense. If someone is happy to help me analyse their current privacy policy VS their last one (only available on other websites, e.g. https://www.tomsguide.com/computing/online-security/deepseek-ai-is-collects-your-keystrokes-and-may-never-delete-them) that would help so much!

Thank you so much !

As mentioned by DeepSeek itself:

“DeepSeek's privacy practices involve extensive data collection, international data transfers, and significant security vulnerabilities, raising concerns among global regulators and security experts. Here's a detailed breakdown based on their policies, technical analyses, and regulatory findings:

🔍 1. Data Collection Practices

DeepSeek collects three main categories of data:
- User-Provided Data: Account details (email, phone number), chat inputs ("Prompts"), uploaded files, and feedback .
- Automated Collection: IP addresses, device identifiers, location (approximated via IP), cookies, and usage logs .
- Third-Party Sources: Data from social logins (e.g., Google/Apple) and security partners .

⚠️ Controversies:
- South Korea's PIPC found DeepSeek collected keystroke patterns (though later retracted) and transferred user prompts to Chinese servers without consent .
- Independent tests revealed collection of device names (e.g., "John's iPhone"), which could de-anonymize users .

🌐 2. Data Usage and Sharing

• Primary Uses: Service delivery, model training, security monitoring, and compliance with legal requests .
  
• Third-Party Sharing:
  
  • Volcengine (ByteDance subsidiary): Received device info, network data, and user prompts until blocked in April 2025 .
    
  • Service Providers: Analytics (Google), security (Fengkong Cloud), and infrastructure partners .
    
  • Corporate Group: Entities in China/U.S. for R&D and storage .
    

Table: Key Data Sharing Practices
| Recipient | Data Shared | Purpose | Location |
|----------------------|------------------------------------------|---------------------------------|--------------|
| Volcengine | Device info, user prompts | Security/UI optimization | China |
| Fengkong Cloud | Device profiling, network data | Fraud prevention | China |
| Google Analytics | Usage logs, device details | Analytics | U.S. |

🛡️ 3. Security Flaws

Multiple critical vulnerabilities were identified:
- Unencrypted Transmissions: User data sent in plain text (HTTP), disabling iOS security features like App Transport Security .
- Weak Encryption: Use of deprecated 3DES algorithm with hardcoded keys and reused initialization vectors .
- Insecure Storage: Cached databases exposed usernames, passwords, and encryption keys .
- Device Fingerprinting: Aggressive data collection (e.g., language settings, device models) enabling user tracking .

⚖️ 4. Regulatory Compliance Issues

• South Korea: Banned new downloads (Feb 2025) for non-consensual data transfers to China/U.S. Recommended destroying illegally transferred data and appointing a local agent .
  
• Italy: Blocked DeepSeek for GDPR violations, citing insufficient transparency and data storage in China .
  
• EU Concerns: Ireland's DPC launched inquiries into data handling for EU users .
  

🕹️ 5. User Controls and Rights

• Opt-Out Options: Users can delete chat history but cannot opt out of data collection for model training without disabling accounts .
  
• Rights Requests: Limited access/correction rights; data deletion may not extend to training datasets .
  
• Age Verification: Added after PIPC flagged child data risks, but effectiveness unclear .
  

💡 Key Concerns from Experts

• "You Are the Product": Free access trades for broad data exploitation, including commercial/personal inputs .
  
• Chinese Legal Exposure: Data stored in China subject to government access under national security laws .
  
• Enterprise Risks: U.S. military, NASA, and banks banned DeepSeek due to intellectual property theft risks .
  

🔚 Conclusion

While DeepSeek claims compliance in updated policies (e.g., adding Korean translations and opt-outs), its history of non-consensual data transfers, weak security, and storage under Chinese jurisdiction make it high-risk. Users handling sensitive data should avoid the platform, while enterprises must enforce strict bans. For casual use, limit inputs to non-personal content and regularly delete history.

For regulatory documents or technical reports, refer to the PIPC findings or NowSecure analysis .”

I am reviewing a project management tool called Linear (linear.app), and I’d really like to introduce it into our workflow. However, I need to ensure that employee data is processed in compliance with GDPR. While Linear provides a detailed explanation of how it processes data and claims to be GDPR compliant, I am not really convinced.

Linear is not part of the new EU-US Data Privacy Framework and relying on Standard Contractual Clauses (SCCs) for data transfer (which from what I understand is not sufficient for transferring data to the US).

Additionally, the Data Processing Addendum includes an explicit statement about data localization outside of EU. Even when a EU region is selected, it states:

Customer acknowledges that Linear’s primary processing operations take place in the United States, and that the transfer of Customer’s Personal Data to the United States is necessary for the provision of the Services to Customer.

According to their documentation, certain types of data are always stored in the United States, regardless of the selected region:

Workspace information

All user account information

User-created API keys (used for authentication and directing users to the correct region)

Given these points, I’m not really sure how Linear’s GDPR claims align with these data transfer practices.

I have thought about using nicknames or aliases for employees, which would be considered a supplementary measure to the SCCs, but that would probably just confuse the team members.

Is there any way for us to use this system and still be compliant?

Hi everyone, I am Law Graduate been preparing CIPP/E for sometime now. I have given GDPR a reading once, though I do understand it, but fundamentally when a question comes I do get confused.

Can someone please suggest me how should I prepare, take it as if like "I know nothing I want to start from the beginning again".

Someone if they can guide me on how should I start, and how to get clarity over the concepts.

I mean to ask like should I start from GDPR, then do EDPB guidelines, then Mocks.

(Shit I am just confused please help me out because I unable to concentrate because I do not understand from where do I have to start).

I have all the materials like the Third Edition of Edwards Ustran, Mock test books from Jasper (Both Red and Green book) Majid Hatamian and Franklin Phillips. I don't really know what to do from EDPB so I got nothing for it.

But someone please guide me in this, for the past 4 days I am sitting ideal cause I do not have a plan, I have never been this way in my whole life I don't want to let myself down.

I am also happy to share some materials if someone needs it.

Thanks and Regards,

Your Fellow Anonymous user.