SOC 2 and Screen Sharing: Keeping Customer Data Controlled on Calls and Recordings
Demos, support calls and vendor sessions put customer data on screen — and recordings turn that moment into a stored record. Here's how screen sharing intersects SOC 2's confidentiality and privacy criteria, and the practical controls that keep data in scope. Not audit or legal advice.
Screen sharing touches SOC 2 wherever a live session or its recording exposes customer data. The two criteria most in play are Confidentiality (protecting information designated as confidential) and, if you've opted into it, Privacy (handling personal information in line with your notice). The practical takeaway is simple: control who's on the call, control what customer data appears on screen, and treat recordings as a data store with real retention and access implications.
How screen sharing intersects SOC 2
SOC 2 isn't a checklist of tools — it's about whether your controls actually protect data in practice. Screen sharing creates three exposure points auditors and customers reasonably care about:
- Customer data on demos and support calls. Walking a prospect through your product on a real tenant, or debugging a ticket in a live admin panel, routinely puts other customers' names, emails, IDs and revenue on screen — often in front of people from a different organisation.
- Recordings as a data store. A recorded demo or support session is a new record containing customer data. That brings retention, access-control and deletion questions squarely into scope: where is it stored, who can watch it, and when is it deleted?
- Vendor and third-party calls. When a vendor shares their screen with you — or you share yours with them — customer data can cross an organisational boundary your confidentiality commitments never intended.
Practical controls that map to confidentiality
None of these is 'SOC 2 in a box,' but each is a concrete, evidence-able control you can point to:
| Risk | Practical control |
|---|---|
| Whole screen shared, exposing other tabs and apps | Share a single window; keep tools holding customer data closed or out of frame. |
| A live tenant showing many customers' records at once | Blur the columns, rows and identifiers you aren't discussing; reveal only the record in scope. |
| Support call on a real account with PII on screen | Use a demo or sandbox account where possible; blur names, emails, phone and card numbers before sharing. |
| Recording stored with broad access and no expiry | Decide whether to record at all; restrict who can access it, set a retention limit, and delete when done. |
| Unnecessary attendees on a call with confidential data | Restrict attendees to those with a need to know; use a waiting room and lock the meeting. |
| Notifications or chat previews naming customers | Turn on Do Not Disturb; box-blur message panes; keep a panic blur ready. |
Where in-page blur fits as a control
In-page blur maps cleanly to a confidentiality control: it reduces the confidential information disclosed during a session to only what the audience needs to see. Because the blur is painted into the page as real pixels, it also protects the recording — the frosted version is what gets captured, so the stored file doesn't quietly become a copy of your customer database. It's a technical, data-minimisation control that supports your confidentiality commitments; it doesn't replace access reviews, encryption, retention policies or your control narrative.
- 1
Prefer demo data
For anything customer-facing, present a sandbox or seeded account with synthetic data. Blur is your fallback for when you must show a real tenant.
- 2
Blur customer data in the page
With BlurFirst, box-blur list views and identifier columns, then click individual names, emails, IDs or amounts to hide just those. Start blurring with Ctrl/⌘ ⇧ Y.
- 3
Run Scan before you present
Click Scan to auto-detect and blur emails, phone numbers, card numbers, SSNs and API keys locally in one pass. It matches patterns, not free-text names, so check anything it can't detect.
- 4
Restrict attendees and share one window
Admit only people with a need to know, lock the meeting, and share a single window so background tabs stay private.
- 5
Control the recording
Decide whether to record; if you do, review it for stray customer data, restrict access, set a retention limit and delete it when it's served its purpose. Panic-blur with Ctrl/⌘ ⇧ H if something unexpected loads.
A checklist before a call that shows customer data
- Confirm whether the session needs real customer data at all — prefer a demo or sandbox account.
- Restrict attendees to those with a need to know; lock the meeting and use a waiting room.
- Share a single window, not your whole screen, and turn on Do Not Disturb.
- Blur identifier columns, lists and PII in the page, and run Scan for emails, phones, cards and keys.
- Reveal only the record or metric in scope — confidentiality in practice.
- Decide whether to record; if you do, restrict access, set a retention limit, and delete when done.
- Note the control in your process docs so it's repeatable and evidence-able, not ad hoc.