Blog · Privacy and compliance · 8 minute read

Is a screen-share slip a GDPR data breach?

Sometimes, yes. What the GDPR actually says, how to judge the risk when customer data appears on Zoom, Google Meet or Teams, the 72-hour rule, and how to stop it happening.

The short answer

It can be. The GDPR defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data” (Article 4(12)). Showing a customer's name, email address or card number to people who have no right to see it, such as another customer, a prospect or a webinar audience, is an unauthorized disclosure, even if it was accidental and lasted a second.

Not every slip has to be reported. You must notify your supervisory authority within 72 hours of becoming aware of a breach unless it is “unlikely to result in a risk to the rights and freedoms of natural persons” (Article 33(1)), but you must document every breach either way (Article 33(5)).

This article is general information, not legal advice. Your data protection officer or lawyer makes the call for your organization.

Key takeaways

  • Accidental disclosure counts. Intent and duration do not decide whether a breach happened; they decide how serious it was.
  • Notify the regulator within 72 hours unless the breach is unlikely to result in a risk to people. Record every breach, reported or not.
  • Recording, audience and data sensitivity drive the risk. A published webinar is very different from a glimpse on an internal call.
  • Masking data before it reaches the screen is the kind of “data protection by design” measure Article 25 asks for.

What the GDPR counts as a personal data breach

Two definitions in Article 4 do most of the work. Personal data is “any information relating to an identified or identifiable natural person” (Article 4(1)): names, email addresses, phone numbers, customer IDs, IP addresses and payment details all qualify. A personal data breach is a breach of security leading to the destruction, loss, alteration, “unauthorised disclosure of, or access to” that data (Article 4(12)).

The UK regulator puts it plainly. The ICO's guide to personal data breaches describes a breach as a security incident that affects “the confidentiality, integrity or availability of personal data”, and its examples include “access by an unauthorised third party” and “sending personal data to an incorrect recipient”. A screen share transmits whatever is on your screen to everyone on the call. If someone on the call is not entitled to see a piece of personal data, its confidentiality has been breached.

Two things do not matter for the definition: whether it was deliberate (the text says “accidental or unlawful”) and how long it was visible. They matter a great deal for the next question, which is how serious it was.

Common screen-sharing slips, and what makes them serious

Here are typical situations, whether personal data is involved, and the facts that move each one up the risk scale:

Screen-sharing scenarios and GDPR risk factors
SituationPersonal data involved?What raises the risk
A sales demo shows other customers in the CRM list viewYes: names, emails, phone numbersA competitor on the call, a recording, many records visible, deal or pricing notes
A support agent shares the helpdesk with the ticket queue visibleYes: other customers' names and issuesSensitive ticket topics such as health or finances, a recorded session
A recorded webinar shows the attendee or customer listYesPublication: a public recording is permanent and easy to copy
An internal call shows HR or payroll data to colleaguesYes, if they have no need to knowSalary, health or disciplinary details that can harm people if known
A billing page shows full card numbers or IBANsYes, and payment-card rules applyFull card numbers: PCI DSS already requires masking on display
Your own email appears in your own tutorialOnly your ownNot a breach of anyone else's data, but a phishing and privacy risk for you
A demo account with synthetic dataNoNone, which is why demo data is the gold standard when it exists

On card numbers specifically: PCI DSS v4.0 requirement 3.4.1 says the card number (PAN) must be masked when displayed, with the BIN and last four digits as the most that may be shown, unless someone has a documented business need to see more (PCI SSC FAQ). A screen share that shows full card numbers to a third party breaks that expectation regardless of the GDPR.

Do you have to report it? The 72-hour rule

Article 33 sets the clock. The controller must notify the competent supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to people's rights and freedoms. If it is likely to result in a high risk, Article 34 also requires telling the affected individuals without undue delay.

Questions that decide the risk

  • What was shown? Contact details are less harmful than card numbers, health information, salaries or credentials.
  • How much? One email address in a sidebar is different from a table of thousands of customers.
  • Who saw it? A colleague bound by confidentiality is different from a competitor, the public or an unknown audience.
  • Was it recorded or published? A recording turns a glimpse into a copy that can be paused, shared and kept.
  • Could it cause harm? Think fraud, phishing, discrimination, embarrassment or the loss of confidentiality a person relied on.

Whatever the answer, record it. Article 33(5) requires the controller to document any personal data breach, “comprising the facts relating to the personal data breach, its effects and the remedial action taken”, and the ICO tells organizations to record all breaches, “regardless of whether or not they need to be reported”.

Agencies and consultants: you may be the processor

If you handle client data on a client's behalf, you are usually a processor, and Article 33(2) requires you to notify the controller (your client) without undue delay after becoming aware of a breach. Your contract probably sets a shorter deadline. Showing client A's customer data to client B on a call is exactly this situation; see how consultants and agencies set up BlurPilot to prevent it.

What to do in the first hour after a screen-share slip

  1. Stop the exposure. Stop sharing, or switch on Presenter Mode, before you say anything else.
  2. Capture the facts while they are fresh. What data was visible, for how long, who attended, and whether the call was recorded or transcribed.
  3. Contain copies. Pause or delete cloud recordings, keep the session out of shared drives and ask external attendees to delete screenshots.
  4. Tell your DPO or privacy lead now, not after the weekend. The 72-hour window starts when the organization becomes aware of the breach.
  5. Deal with credentials and cards. If an API key, password or full card number was shown, revoke or cancel it; see what to do when an API key leaks.
  6. Fix the cause and write it up. Add a blur rule or a demo account so the same screen cannot leak again, and record the remedial action, as Article 33(5) requires.

Prevention: data protection by design for screen sharing

Breaches are expensive: IBM's Cost of a Data Breach Report 2025 puts the global average at USD 4.44 million. A screen-share slip is usually far smaller, but the cheapest breach is still the one that never reaches the screen.

Article 25 asks controllers to build data protection in “by design and by default”, and Article 32 asks for “appropriate technical and organisational measures” for security. For screen sharing that means layers:

  • Synthetic demo data wherever a sandbox exists.
  • Least-privilege views, so presenters do not see data they do not need in the first place.
  • Window or tab sharing instead of the whole desktop.
  • A short written rule for customer-facing calls, and five minutes of training on it.
  • Automatic masking on the device, so the personal data that does reach the screen is hidden before anyone else sees it.

BlurPilot covers that last layer in Chrome and Edge. Emails, phone numbers and card numbers (validated with the Luhn checksum) blur on the Free plan; Pro adds IBANs, money amounts, IP addresses, API keys and your own list of customer or project names. A team lead can export one rule pack so every rep blurs the same CRM columns, and IT can push it to managed browsers through policy.

One point matters more for compliance than any feature: where the masking happens. A tool that uploads your screen or page content to a cloud service to find personal data becomes another processor of the very data you are trying to protect. BlurPilot detects and blurs inside the browser; page content, URLs, rules and custom words never leave the device. The security overview lists every network call and permission for your DPO.

Frequently asked questions

Is accidentally showing a customer's email address on Zoom a GDPR breach?

It can be. If someone on the call had no right to see that customer's personal data, it is an unauthorized disclosure under Article 4(12) GDPR, even if it was accidental. A single address glimpsed by a trusted party may well be low risk, but record it internally either way.

Do I have to report every screen-sharing mistake to the regulator?

No. Under Article 33(1) you notify the supervisory authority within 72 hours unless the breach is unlikely to result in a risk to people's rights and freedoms. You must still document every breach under Article 33(5), including the ones you decide not to report.

Does it count if the call was internal?

It can. Showing personal data to colleagues who have no need to access it, such as payroll or HR records, is unauthorized access within your own organization. The risk depends on the data and on the colleagues' confidentiality obligations.

Is a recorded webinar worse than a live call?

Usually. A recording can be paused, copied and shared indefinitely, and a public webinar reaches an unknown audience. Both raise the likelihood and severity of harm, which is what decides whether you must notify the regulator and the people affected.

Does deleting or blurring the recording undo the breach?

No. The disclosure happened when the data was shown. Editing or deleting the recording limits further exposure and belongs in your record as remedial action, but it does not erase what live viewers saw.

Does the UK GDPR work the same way?

Yes. The UK GDPR keeps the same definition of a personal data breach and the same 72-hour notification rule. The regulator is the Information Commissioner's Office (ICO), whose guidance says to record all breaches, whether or not they are reported.

Is a data-blurring browser extension itself a GDPR risk?

It can be if it uploads page content. Choose one that processes pages on your device. BlurPilot detects and blurs inside the browser and never uploads page content, URLs, rules or custom words; its license server stores only what licensing needs, such as an email, plan and expiry.

Sources

  1. GDPR Article 4: Definitions
  2. GDPR Article 25: Data protection by design and by default
  3. GDPR Article 32: Security of processing
  4. GDPR Article 33: Notification of a personal data breach to the supervisory authority
  5. GDPR Article 34: Communication of a personal data breach to the data subject
  6. ICO, Personal data breaches: a guide
  7. PCI Security Standards Council, FAQ on PAN masking and truncation
  8. IBM, Cost of a Data Breach Report 2025