PCI DSS and Screen Sharing: Avoiding Cardholder Data Exposure
Practical (not legal) guidance on keeping cardholder data off your screen shares and recordings — what CHD appears in payment dashboards and support tools, why a capture is a disclosure and scope risk, and controls that reduce exposure.
Screen-sharing or recording a screen that shows cardholder data is a disclosure of that data — and it can pull whatever tool captured it into your PCI DSS scope. Practically, that means you should keep the primary account number (PAN) masked, never record sessions that display cardholder data, share a single window rather than your whole desktop, and blur card fields before anyone sees them. This is practical guidance to reduce exposure, not legal or QSA advice — confirm your specific obligations with your acquiring bank or a Qualified Security Assessor.
The goal here isn't to make you compliant — compliance covers how you store, transmit and control access to card data across your whole environment. It's to stop the everyday screen share or Loom recording from quietly becoming a place cardholder data lives.
What cardholder data can end up on screen
Cardholder data (CHD) is the PAN plus, where present, the cardholder name, expiration date and service code. Sensitive authentication data — the CVV/CVV2, full track data and PINs — must never be stored at all. Any of these can appear on screen during ordinary work:
- Payment dashboards (for example a payments provider's console) showing a PAN, expiry, or the cardholder's name on a transaction or customer record.
- Support and CRM tools where an agent views an order tied to a card, or a customer reads their number aloud while you're both looking at the account.
- Order and admin systems that surface the last four — or, in poorly designed screens, the full PAN — next to a name and address.
- Virtual terminals where a CVV is typed to take a payment over the phone — exactly the field that must never be captured.
Why a screen share or recording is a scope and disclosure risk
Two things happen when CHD lands in a capture. First, it's a disclosure: everyone on the call, plus anyone who later gets the recording, has now seen data you're obligated to protect. Second, it's a scope problem: a recording of a PAN is a stored copy of a PAN, so the recorder, the meeting host, the cloud storage and the retention policy behind it all get drawn into the conversation about how CHD is handled. The cleanest way to keep those systems out of scope is to keep CHD out of the capture in the first place.
Practical controls to keep CHD off your shares
No single control is enough — layer them. In-page blur is one control among several, useful for the moment card data is on the browser screen:
- Mask the PAN by default — display only the first six and/or last four where your app allows it, and don't show the full PAN unless there's a documented business need.
- Never capture the CVV/CVV2 — it must never be stored, so it must never be on a recording. Take card-not-present payments off the shared screen where you can.
- Share a single window or tab, not the whole desktop, so CHD in another tab or app stays out of frame.
- Turn recording OFF for any session that might show cardholder data; if a recording is genuinely required, blur the card fields first.
- Blur the PAN, expiry, cardholder name and any CVV entry field in the page before you present or record.
- Restrict who's on the call to people with a legitimate need — screen sharing instantly widens the audience for whatever's on screen.
- Review saved recordings and their retention: delete anything that captured CHD, and confirm where copies are stored.
| Risk | Practical mitigation |
|---|---|
| Full PAN visible in a payment dashboard or order record | Use the app's masking (first six / last four); blur the field in-page if the app still shows the full PAN |
| CVV entered in a virtual terminal during a shared session | Never record; blur the CVV field; ideally take the payment off the shared screen entirely |
| A recording of a support call captures a customer's card | Disable recording for CHD sessions; if it was recorded, redact before storage and set a short retention |
| A whole-desktop share exposes another customer's data in a second tab | Share a single window; close unrelated tabs holding CHD before you start |
| The recorder or meeting host now stores CHD, expanding scope | Keep CHD out of captures entirely so those tools stay out of scope; blur before capture |
How to blur cardholder data before you present
- 1
Install and pin the extension
Add BlurFirst from the Chrome Web Store (also Edge, Brave, Vivaldi, Opera) and pin it.
- 2
Open the payment or order screen and start blurring
Bring up the console, support tool or virtual terminal and press Ctrl/⌘ ⇧ Y.
- 3
Blur the card fields
Click the PAN, expiry or cardholder-name element to hide just it, or drag a box over the whole card panel. On Pro, run Scan to auto-detect card-number patterns locally in the browser.
- 4
Save a per-site profile (Pro)
Save the blurs for your payment tool so the fields hide automatically on load. The profile stores only a CSS selector — never the card data itself — and nothing you blur ever leaves the browser.
- 5
Confirm the environment, then present
Turn on Do Not Disturb, share a single window, and keep Ctrl/⌘ ⇧ H ready to blur everything if a card appears unexpectedly.