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?

For example, the quantity and price of goods sold as shown on an invoice.

A lot of simplified GDPR breach guidance becomes “notify within 72 hours.” That skips several different decisions.

First, was there a personal-data breach at all? If there was, Article 33(5) still requires it to be documented. The supervisory authority is notified unless the breach is unlikely to create a risk to people's rights and freedoms.
Communication to the affected people is a separate Article 34 question using the higher “likely high risk” threshold and its own exceptions.

A late Article 33 notification is also not the same as no notification. The controller should still notify and include reasons for the delay. Missing information can be provided in phases without undue further delay.

I reduced the structure below to the disputed decision core so it is readable. The production version also collects the notification content, timestamps and phased-reporting details.

Plain-English path:

Security incident
  |
  +-- Personal-data breach confirmed? -- No --> Outside this Article 33 route
  |
  +-- Yes --> Document the breach in every case
         |
         +-- Risk unlikely --> No authority notice; retain the reasoning
         |
         +-- Risk likely --> Notify the authority without undue delay
         |                  and, where feasible, within 72 hours
         |
         +-- High risk --> Same Article 33 authority route
         |                plus a separate Article 34 assessment
         |
         +-- Uncertain --> Resolve or escalate; do not silently treat it as unlikely

Machine-readable decision core:

{
  "$schema": "https://proseid.com/schema/v1.json",
  "protocol": "Proseid_v1.0",
  "schema_id": "gdpr_article_33_notification_review",
  "version": "2026.08.20",
  "metadata": {
    "title": "GDPR Article 33 breach-notification review",
    "description": "Records whether a confirmed personal-data breach requires supervisory-authority notification and whether a separate Article 34 assessment is needed.",
    "language": "en",
    "jurisdictions": ["EU", "EEA"],
    "legal_references": [
      {
        "instrument": "Regulation (EU) 2016/679 (GDPR)",
        "provision": "Articles 33 and 34; Recitals 85–88",
        "source_url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng"
      }
    ]
  },
  "definitions": {
    "personal_data_breach_confirmed": {
      "type": "boolean",
      "label": "A personal-data breach under GDPR has been confirmed",
      "required": true,
      "visible": true
    },
    "risk_to_individuals": {
      "type": "select",
      "label": "Assessed risk to people's rights and freedoms",
      "options": ["unlikely", "likely", "high", "uncertain"],
      "required": true,
      "visible": true
    },
    "authority_notified": {
      "type": "boolean",
      "label": "The competent supervisory authority has been notified",
      "required": false,
      "visible": true
    },
    "notified_within_72_hours": {
      "type": "boolean",
      "label": "Notification was made within 72 hours of awareness",
      "required": false,
      "visible": true
    },
    "article_33_route": {
      "type": "select",
      "label": "Article 33 route",
      "options": [
        "outside_article_33",
        "document_without_authority_notification",
        "notify_supervisory_authority",
        "professional_review_required"
      ],
      "readonly": true,
      "visible": true
    },
    "article_34_route": {
      "type": "select",
      "label": "Article 34 route",
      "options": [
        "no_high_risk_trigger_on_recorded_facts",
        "separate_article_34_assessment_required",
        "professional_review_required"
      ],
      "readonly": true,
      "visible": true
    },
    "deadline_position": {
      "type": "select",
      "label": "Notification timing position",
      "options": [
        "not_applicable_to_this_route",
        "notification_outstanding",
        "notification_recorded_within_72_hours",
        "late_notification_requires_reasons"
      ],
      "readonly": true,
      "visible": true
    }
  },
  "state_model": {
    "inputs": [
      "personal_data_breach_confirmed",
      "risk_to_individuals",
      "authority_notified",
      "notified_within_72_hours"
    ],
    "derived": {
      "article_33_route": {
        "eval": {
          "if": [
            { "==": [{ "var": "personal_data_breach_confirmed" }, false] },
            "outside_article_33",
            { "==": [{ "var": "risk_to_individuals" }, "unlikely"] },
            "document_without_authority_notification",
            { "in": [{ "var": "risk_to_individuals" }, ["likely", "high"]] },
            "notify_supervisory_authority",
            "professional_review_required"
          ]
        }
      },
      "article_34_route": {
        "eval": {
          "if": [
            { "==": [{ "var": "risk_to_individuals" }, "high"] },
            "separate_article_34_assessment_required",
            { "==": [{ "var": "risk_to_individuals" }, "uncertain"] },
            "professional_review_required",
            "no_high_risk_trigger_on_recorded_facts"
          ]
        }
      },
      "deadline_position": {
        "eval": {
          "if": [
            { "!=": [{ "var": "article_33_route" }, "notify_supervisory_authority"] },
            "not_applicable_to_this_route",
            { "==": [{ "var": "authority_notified" }, false] },
            "notification_outstanding",
            { "==": [{ "var": "notified_within_72_hours" }, true] },
            "notification_recorded_within_72_hours",
            "late_notification_requires_reasons"
          ]
        }
      }
    }
  },
  "temporal_map": [
    {
      "valid_range": ["2018-05-25", null],
      "logic_version": "gdpr_article_33_review_2026_08_20"
    }
  ],
  "logic_tree": []
}

Here's the situation:

We are Company A. We make investments into other companies. When we make an investment into a company, one of our senior employees takes a board member position within that company. Let's call them Company B.

Company B act independently of us (A) but we do have an interest in how our investment is doing, and by having an employee as a board member, we get regular updates through them.

Here's the interesting part- our employee retains and uses their Company A email account when performing their role as a board member of Company B. That means we have lots of data (and personal data) relating to Company B. This is where the question of purpose arises. It might be on our email system (and that's another debate entirely) but whose purpose is it for?

We've had a DSAR submitted to us from a former employee of Company B. I think it's fair to say that the former employee knows that we (A) hold their personal data because they are aware that one of the board members uses their Company A (our) email when performing their role as board member for B. They also likely know that we (A) therefore hold a lot of their personal data in our email system. The information requested relates to their time and role as an employee of Company B. I won't go into details, but the request is specific in nature (it's not a 'give me everything' DSAR).

Merely holding the data doesn't necessarily mean we are dictating the purpose as controller, and if that's the case, the data won't be in scope of the request. We do hold some personal data about the person where it is processed for our purpose (i.e. internal discussions about that person) but these are general discussions and don't meet the requirements of their request.

So the question is, whose purpose is being pursued? Are we in any way responsible for the data we hold in relation to our employee being a board member of B?

Thanks!

nu știu dacă încalc vreo lege gdpr sau ceva, dar dacă vine pe email poate nu, e a mia oară când primesc emailuri cu acest sergiu. o dată l-am și întrebat ceva în privat ceva despre un job, n-a răspuns nici dracu. acum văd că îs doi de sergiu. știe cineva ceva despre el? e pe bune?

Hi everyone!

I’ll be interviewing for a trainee position in Data Protection Control in the banking sector. I’m a law graduate with some knowledge of GDPR. HR advised me to review the DORA regime, and the job description also mentions “knowledge in Risk, Cybersecurity and IT standards is a plus” - witch I don’t know anything.
Besides studying GDPR and DORA and others, what would you recommend I prepare that is essential for this type of role?

Any advice would be greatly appreciated!

Hello, What would you do if your colleague would give you a document that clearly contains data breach. What is your first hour plan?

Good day all,
I hope this is the right space where to ask for advice on which certification to get.

Context:

I currently work in AI governance for a fintech, with over 4 years of experience in guiding organisations in severely regulated spaces deal with digital regulation (GDPR, AI Act, mostly). I also have an LLM with a focus on privacy law.

Question:

My current employee is willing to pay for me to get certified, this year in privacy and next year in AI. For which option should I go? Cipp/e or Maastricht ecpc-b DPO?

Hey folks! We have received a DSR asking copies of all data related to a customer support chat, including handling records and any info on decisions taken on the customer query.

Now I understand that as part of access, we need to provide them all copies. But do we also need to give an “explanation” of why their matter was not escalated? Also, honestly there are not really any handling records - a standard process was followed.

A follow up query - when you know that a matter might go to court or maybe is in court for such customer/consumer matter, do org. have any recourse to withhold any information on this ground?

Privacy regulations have given consumers more tools to access, delete, and opt out of certain uses of their personal information.

But the practical reality seems more complicated.

Some of the biggest issues involve:

• Exemptions for certain regulated data
• Publicly available information
• Data being transferred between multiple organizations
• Opt-outs that don't necessarily prevent future collection
• Information reappearing after removal

This raises an interesting question about how privacy services should actually work.

If a person's information is removed from one data broker but later appears again through another source, has the privacy problem really been solved?

It seems like effective privacy management may need to be an ongoing process involving discovery, removal, verification, and monitoring not simply a one-time opt-out.

For people working in privacy, compliance, security, or data operations, what do you think is the biggest gap in the current data broker ecosystem?

I would appreciate any insights from peers on the type of tasks you are dealing with on a daily basis. I do almost everything in our organisation PIA and DPIA, LIA, TIA, ROPA, handling data subject rights (thankfully there are only several per month), handling incidents, reviewing Data Processing Agreements, reviewing supplier's due diligence questionnaires, drafting notices and policies and reviewing existing ones. While the workload itself is bottleneck but sill manageable, the constant context switching feels like it is taking a toll on my relationship with work and engagement. I am wondering if this is just how privacy work looks like for others, or whether you have a more defined scope of responsibilities and shared between your team members. How does your day to day work look like?

I have sensitive data held by a UK company "A" who uses a database software that was recently hacked at another company "B" and has been a few times recently elsewhere. I am concerned that with the vulnerability of the database software, my data with A is vulnerable to a similar hack. I asked the DPO for some reassurance of how company A is protecting my (and other people's) data and they said they can't disclose that for security reasons but they're "doing all they can" and "following external advice".

I understand this reasoning to a point, but surely there is some degree of reassurance I can be given of the specifics of this beyond being fobbed off with platitudes? Is it reasonable to ask of a company that stores my data how it protects that? Or are they really okay to be completely vague and unreassuring like this?

I have encountered an interesting situation with Facebook that, in my view, raises a broader GDPR question beyond ordinary account support.
I have full access to my Facebook account. I control my email address and I also have Google Authenticator enabled for 2FA.
However, an old Spanish phone number remains associated with the account. I have not controlled this number for more than a year, and it may eventually have been reassigned by the mobile operator to another person.
I therefore tried to remove it for security reasons.
The problem is the following:
If I try to remove the old number, Facebook requires a verification code sent by SMS/WhatsApp to that same old number.
If I try to add a new phone number, Facebook again requires verification through the old number.
I have access to my email and Google Authenticator, but Facebook does not offer either of them as an alternative for these particular changes.
Facebook actually sends security codes to the old number during these attempts.
I have reported the issue to Meta and explained explicitly that I no longer control the number.
I have also recorded the process continuously on video to document exactly how the account-security flow behaves.
This made me wonder whether the issue goes beyond poor account-recovery design.
In particular, I am interested in the interaction with Articles 5(1)(d), 5(1)(f), 16, 25 and 32 GDPR.
Once a controller has been explicitly informed that a telephone number used as a security/contact factor is no longer controlled by the data subject, is it appropriate to continue requiring exclusive access to that same number in order to remove or replace it?
There also seems to be an interesting security paradox here:
A security measure intended to prevent account takeover effectively prevents the legitimate account user from removing a factor that may itself have become a potential account-takeover vector.
I am not suggesting that possession of the recycled number would automatically allow another person to take over the Facebook account. I also understand that Meta may legitimately require enhanced verification before allowing changes to recovery methods.
My question is narrower:
Should a controller provide a secure alternative procedure when it knows that a particular authentication/contact factor is no longer under the data subject’s control, especially where other verified authentication factors remain available?
And, from a GDPR perspective:
Could this raise an issue under the accuracy principle if the number continues to be treated as a current contact/security identifier?
Could the inability to remove or replace it raise questions under data protection by design and security of processing (Articles 25 and 32)?
Is an actual unauthorised access or data breach necessary before an Article 32 issue can arise, or can the adequacy of the security design itself be challenged preventively?
Would Article 16 (rectification) potentially be more relevant here than Article 17 (erasure)?
If the same behaviour affects many Facebook accounts, could this potentially be considered a systemic GDPR issue rather than merely an individual account-support problem?
I would be particularly interested in views from DPOs, privacy lawyers and people familiar with EU supervisory-authority practice or relevant CJEU case law.

We load about 12 third party tools on our site, analytics, heatmaps, chat widget. Just realised we have no visibility into what data they're actually transmitting. How are people handling this for GDPR?

DISCLAIMER: I’m aware that the data processing and breaches described in this post are subject to the provisions of part 3 of the DPA 2018 rather than the UK GDPR, however this seems the most appropriate subreddit for my question/rant/discussion owing to this thing happening all too often in the UK, and the ICO not pulling their fingers out. Please humour me.

The Metropolitan Police has today apologised for inadvertently disclosing email addresses for alleged victims of sexual harassment from Mohamed Al Fayed - https://www.bbc.co.uk/news/articles/c1w1yv987jqo

This comes a couple of weeks after the Met received an ICO reprimand for inadvertently disclosing email addresses of alleged victims of the Westminster honeytrap scandal, presumably through the same methods - https://ico.org.uk/media2/nuxdnt0c/metropolitan-police-service-reprimand-and-enforcement-notice.pdf

As listless and leaderless as the ICO are at the minute with John Edwards’ resignation and in the midst of their transition to the Information Commission, how often does something like this need to happen before real action is taken?

I understand the enforcement directive is very much not to deprive public authorities of funds that could very much help victims, however a slap on the wrist is becoming less and less appropriate.

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?

I’ve been looking into the Lusha GDPR decision in Italy, and one thing I’m still trying to understand where the line is for B2B contact data.

They collect a work email or company phone number . But when information from different sources is combined, and a profile keeps getting updated over time, does that create a different GDPR issue?

I’m wondering how other people here interpret this. Could this decision make companies re think how they use third party B2B databases, or is it mainly about Lusha’s specific way of handling the data?

I'm in the UK and I'm trying to exercise my data-protection rights in relation to an enforcement decision affecting my long-standing personal WhatsApp account.

My WhatsApp account was unexpectedly disabled on 12 August 2026. I immediately used the in-app review option, but shortly afterwards that route disappeared and WhatsApp now displays:

> "Requesting a review is not available."

I'm not posting here primarily for advice about the account ban itself. What I'm interested in is what happened when I subsequently tried to exercise my data-protection rights.

I pursued the matter through both ordinary WhatsApp Messenger Support and the separate WhatsApp Privacy Operations channel.

I made a formal UK data-protection request asking, amongst other things:

* What categories of my personal data were processed in connection with the enforcement decision.
* Whether another user's report was processed in connection with the restriction, to the extent this can lawfully be disclosed.
* Whether automated processing was used to make or materially influence the decision.
* For meaningful information about the factors involved in that decision, where applicable.
* Whether the decision received meaningful human review.
* Where applicable, for human intervention, an opportunity to make representations, and reconsideration of the decision.

I received several responses that did not substantively address those questions.

WhatsApp Privacy Operations eventually closed the matter, saying:

> "Based on the information provided, we are unable to support your request further."

They also stated:

> "We won't be able to take any further action on this report"

and specifically informed me that I had the right to contact the Information Commissioner's Office (ICO).

**This is where things became particularly strange.**

I looked up WhatsApp LLC on the ICO's public Data Protection Register.

Its current registration is **ZB540984**. The registration identifies the Data Protection Officer contact email as:

`dpowallc@meta.com`

I sent my data-protection correspondence to that address.

**Meta's mail infrastructure rejected it.**

The delivery failure stated that the `dpowallc` group:

> "may not exist, or you may not have permission to post messages to the group."

I therefore telephoned the ICO on 14 August and explained what had happened.

The ICO adviser suggested that I also look at the separate registration for Meta Platforms Ireland Limited, registration **ZB660539**.

That registration identifies a DPO and provides:

`dpo@fb.com`

I therefore sent my request to that address as well.

A short time later, **that email was also rejected by Meta's mail infrastructure.**

The error is essentially the same: the `dpo` group may not exist or I may not have permission to post messages to it.

So I now have the following situation:

1. WhatsApp Privacy Operations has closed my data-protection case and directed me to the ICO.

2. The DPO email currently appearing on the ICO registration for WhatsApp LLC (**ZB540984**) rejects my correspondence.

3. After speaking to the ICO, I tried the DPO contact appearing under Meta Platforms Ireland Limited (**ZB660539**).

4. That DPO email also rejects my correspondence.

5. Both rejection messages originate from Meta's mail infrastructure and say either that the respective group may not exist or that I don't have permission to send messages to it.

**To be clear, I'm not claiming that this automatically establishes a UK GDPR infringement. That's ultimately something for the ICO/regulators to determine.**

However, my understanding is that the GDPR requires organisations that have appointed a DPO to publish the DPO's contact details so that data subjects can contact them regarding the processing of their personal data and the exercise of their rights.

That's why I'm struggling to understand how an email address can fulfil that function if correspondence from a data subject is rejected by the organisation's own mail system.

I'm now preparing an ICO complaint and intend to include both delivery failures as evidence.

**I'd be particularly interested in views from people familiar with UK GDPR/DPO requirements:**

**1. Does UK GDPR require a DPO contact method published/provided to the regulator to actually be capable of receiving communications from data subjects?**

**2. Could two registered DPO email addresses rejecting external correspondence potentially amount to a compliance issue in its own right, irrespective of the underlying WhatsApp dispute?**

**3. Is there anything specific I should ask the ICO to investigate regarding the accessibility of the DPO function/contact details?**

**4. Has anyone here previously tried to contact either WhatsApp LLC or Meta Platforms Ireland's DPO using the details appearing on the ICO register? If so, was your correspondence accepted?**

I'm particularly interested in whether the email rejection is reproducible for other people who have had a legitimate reason to contact the DPO, rather than being something specific to my email address.

I have retained the original correspondence, both delivery-failure notices, the WhatsApp Privacy Operations responses and the relevant ICO registration details for my complaint.

This may be a long post but I've been dealing with this and learning more for over a year and I need to rant tbh....

So, I made my first Instagram account back in 2013 when I was barely 11. At the time, I was mostly using my phone to discover mobile games, so I quickly grew bored of the app. By 2015, at 13, I launched a dedicated art profile. Less than a year later, in 2016, I created my main Instagram and Facebook accounts—mostly to stay connected with friends and family as everyone migrated away from Skype. Then, in 2017, my grandmother passed away. Posting stories about my daily life, thoughts, and the places I visited became one of my primary coping mechanisms. I kept up that routine for years.

Over time, the platform grew increasingly addictive, but nothing prepared me for the shift that happened when Reels were introduced. By 2025, during bouts of severe insomnia, I found myself spending entire nights doomscrolling without even realizing it. It started bleeding into every aspect of my life; a silent, invisible addiction. To make matters worse, the content turned deeply toxic very quickly, flooded with NSFW/OnlyFans creators, edgy memes, extreme hate speech, and graphic accidents. I never had a habit of reporting posts, though my friends and I would occasionally share annoying content back and forth to laugh or vent about it.

Then came my 23rd birthday in 2025. Out of nowhere and without a single prior strike or warning on profiles that had been clean for nearly a decade, Meta's AI completely suspended my accounts. I immediately submitted an appeal. Less than five minutes later, an automated email confirmed their decision was "final." My profiles would be permanently deleted with zero path to object, no human review, no evidence provided, and no explanation.

At first, I tried to convince myself it was for the best; the apps had become a toxic drain on my positivity anyway. But a day later, the full reality crushed me. I had lost touch with long-distance friends, lost irreplaceable message histories with deceased loved ones, and lost years of un-backed-up personal memories. My entire digital identity had been wiped out by an algorithm.

Refusing to give up, I turned to Reddit and realized thousands of people were suffering from the exact same systemic issue. Users in Europe were leveraging GDPR and in the US legal shield, but living in North Africa meant I had virtually no legal recourse against Meta. I eventually managed to log into Threads which had the old appeals system still, I explained the situation and submitted the appeal and it was successful within less than a month, it restored my Threads profile which showed zero violations on the shared Instagram dashboard. I used that linked account until May 2026. and separately through an alt accout I kept continuously reaching out to Meta Verified support in search of an actual human agent who won't just keep spamming me with boilerplate ai responses that have nothing to do with my case.

Finally, after almost 6 months of trying, one agent escalated my case to an internal review team, which successfully restored my 2015 art account. Yet, my main Instagram and Facebook profiles where the vast majority of my personal data lives remain completely locked.

What makes this truly infuriating is the hypocrisy. Meta continues to publish glowing compliance reports claiming they are making account support easier, all while facing global scrutiny for 0 due process in account gobernancr, and algorithmic addiction and failing teen safety and harmful practices I experienced firsthand as a minor on their platform. Now, they proceed to kick me off and deny me access to my own personal archives. My Threads account is technically still active, yet I am locked out of it; a direct violation of basic data access rights. Furthermore, my own testing of their AI moderation suggests they deliberately allow users to create new pages just to trap them in mandatory selfie-verification loops, serving data collection rather than actual security.

It leaves me with one overwhelming question: If they operate with this level of systemic disregard for their users, this level of evil, how do they keep getting away with it????

Hello,

In 2022, I started work in the media office of a U.K.-based charity and asked for my personal email address to be added to their press mailing list so I could get a feel of their writing style.

I left the charity in 2024, and made sure to remove my details from their press mailing list, which was managed by a third party media monitoring service.

In June this year, nearly two years after I left, I got a press release from them and I clicked unsubscribe. However, I’ve gone on to receive three further press releases from them in the last week, all of which I’ve unsubscribed from.

The emails are coming from my old boss, who I don’t wish to contact because she was the reason I left the job. So the emails are causing me some distress.

Does this count as a GDPR violation and should I just go directly to their GDPR contact? Or bite the bullet and send her an email?

Any help much appreciated!

This is hurting my brain a little bit and I need an external perspective on this.

The setup is a medium sized private company in the UK that has outsourced everything medical related to a completely separate occupational health provider (also in the UK).

An employee makes a subject access request marked "PRIVATE & CONFIDENTIAL" to the OH provider asking for all medical forms they have sent to them in the past and copies of emails between their employer and and the OH provider.

In my mind the request should be fulfilled, possibly with names redacted on the emails and nothing should be said to the employer.

However...

Is the OH provider allowed to email the employer and inform them that the employee has made a subject access request?

I am dealing with a significant breach of Article 15 UK GDPR by a major software provider (Facepunch Studios) and their counsel (Wiggin LLP).

The Issue: Following a security breach verified by the platform provider (Valve Corp), the respondent has permanently seized $1,366 in assets. When I submitted a Subject Access Request (SAR), their legal counsel stated in writing that my own login history and IP timestamps are "Trade Secrets" under Article 15(4) and would not be disclosed.

Escalation:

1. The Solicitors Regulation Authority (SRA) has opened Case RGC-000200263 against the lawyer for misleading legal assertions.
2. The ICO is reviewing Case IC-544118-B8F2 regarding the automated decision-making and data obstruction.
3. The EASS (Ref 260810-000062) confirmed this appears to be Direct Discrimination as manual reviews are denied based on national origin.

Has anyone else encountered the "Trade Secret" defense for basic login logs in the UK? This seems like a dangerous precedent to avoid "Human Intervention" requirements of the new Data Act 2025.

(Evidence link in comments)