Support session recording is worth it when it answers a question you’ll really ask, such as “what did the agent see and click before that setting changed?”, and when you can keep the recording masked, short-lived and visible only to the people who review access. For routine read-only investigations, access history plus application audit events usually tell you enough, without making a second copy of a customer’s account.
The tension is simple. A support agent impersonating a customer is already looking at someone else’s data. A recording copies that view into a new store that more people can open, for longer. That can be good evidence. It’s also more personal data to protect.
What does a support session recording prove?
A recording shows what was rendered in the agent’s browser and what they clicked. It doesn’t prove what your backend did.
| Question | Session recording | Application audit event | Access record |
|---|---|---|---|
| Who was allowed in, and why? | No | No | Yes |
| What did the agent see and click? | Yes, within what masking allows | No | No |
| Was an invoice or setting actually changed? | Only what the screen showed | Yes, from the transaction | No |
| Did a request fail or get blocked? | Sometimes, if an error was visible | Yes | No |
| When did access start and end? | Roughly | No | Yes |
That’s why recordings complement audit logs rather than replace them. A success toast on screen isn’t evidence that an operation committed, and masking may hide the very field you’d want to inspect. The impersonation audit log guide covers recording the actor, subject and outcome on the server.
Recordings are most useful for three things: reviewing a disputed or unexpected change, understanding how an agent navigated when the audit trail shows what but not why, and coaching. They’re least useful as a default for every look-around.
What are the privacy costs of recording support sessions?
The main cost is a second, durable copy of customer data that wasn’t needed to fix the problem.
A support session can show the customer’s records, their own customers’ details, messages and documents. Once recorded, that content can outlive the ticket, reach reviewers who never needed it, and become part of every access request, export and deletion you handle.
If GDPR applies to you, two of its Article 5 principles (opens in a new tab) map directly onto this decision. Personal data should be “adequate, relevant and limited to what is necessary” for the purpose (data minimisation), and kept in identifiable form no longer than necessary (storage limitation). This isn’t legal advice, but it’s a useful test: can you name the purpose of each recording, and does the content and retention match it?
Defaults also vary between tools. In rrweb, the open-source library behind many replay products, the maskAllInputs option defaults to false (opens in a new tab). Whatever you use, check what’s captured out of the box rather than assuming it’s masked.
When should you record support impersonation sessions?
Record when the evidence will change a decision and someone owns the review. Skip it when it won’t.
| Session type | Recommendation | Why |
|---|---|---|
| Read-only investigation of a bug | Usually don’t record; keep access history and audit events | The agent can’t change anything, and the ticket explains the purpose |
| Write session to fix customer data | Record, with full masking and targeted reveals | Changes are where disputes come from |
| Access to sensitive accounts (admins, regulated data) | Record if policy requires it, with tight replay access | Higher stakes justify the extra data |
| Emergency or break-glass access | Record, and review every session | Normal approvals were bypassed or shortened |
| Training new agents | Use staging accounts, not real customer recordings | Training doesn’t need real customer data |
Whatever you choose, write it down with the reviewer, the retention period and the reveal list. An unreviewed archive of recordings is all cost and no benefit.
How should masking work in support recordings?
Mask everything by default and reveal only what a reviewer needs. Do it in the browser at capture time, so masked content never leaves the page.
A practical setup:
- Full masking as the baseline. Keep layout, navigation and clicks so the replay still makes sense, but replace text and block media.
- Targeted reveals. Reveal specific named regions, such as an order summary or an error panel, rather than turning masking off for a whole page.
- Sensitive fields stay masked everywhere. Passwords, one-time codes, card numbers and secrets shouldn’t be revealable by any setting.
- Block embeds. Document viewers, images and iframes can carry far more than the page around them.
Masking applies to the recording, not to what the agent sees live. If agents shouldn’t see certain fields at all, that’s a response-minimization job for your application. See what read-only support access can still expose.
How long should you keep recordings, and who should replay them?
Keep them for a defined review window, delete them automatically, and limit replay to the people who review access.
- Retention. Pick a period that matches the purpose, such as the window in which a customer could dispute a change. Delete on schedule, and make sure expiry removes access to the recording, not just the files.
- Replay access. Security, compliance or a support lead reviewing the session, plus perhaps the agent reviewing their own session. Not the whole support team.
- Audit the replays. Who watched which recording, and when, is itself access to customer data. OWASP’s logging guidance (opens in a new tab) applies here: protect event data from tampering and from unauthorized access, modification and deletion.
- No casual exports. A downloaded replay file escapes your retention and access controls.
Should you tell customers that support sessions are recorded?
Generally, yes. A customer who finds out later that support recorded their account is far more upset than one who read about it in your terms.
Put it where customers look: your privacy notice, support terms or data processing agreement. Say when sessions are recorded, what’s masked, how long recordings are kept and who can view them. Whether you also need consent depends on your contracts and jurisdictions, so ask your legal team. Internal approval of a support session is a different thing from customer consent; the customer consent guide covers how they fit together.
How does Devora handle support session recording?
In Devora, recording is optional and off by default (opens in a new tab). An organization administrator turns it on under Settings → Recording, choosing “Write sessions only” or “All impersonation sessions”. The activity timeline is a separate switch, also off by default.
The rest of the Devora recording policy (opens in a new tab) follows the principles above:
- Masking. Full masking is the default. Administrators can choose partial or minimal profiles and maintain always-mask, always-block and reveal lists. Password, email and phone inputs, one-time codes, card fields and similar inputs stay masked in every profile and can’t be revealed. Masking runs in the browser at capture time.
- Policy in the dashboard, not code. Developers can’t loosen capture from the SDK. Each session snapshots the policy when it’s created, so changes apply to new sessions.
- Automatic retention. Recordings are kept for a fixed retention period and then deleted. Expiry immediately revokes replay access and schedules deletion.
- Narrow replay. Only an organization owner or administrator, or the agent who owns that exact session, can replay it. Each replay goes through a short-lived, audited viewer grant, and there is no raw replay export.
When a session ends, access closes at once. Recording and activity data the tab captured before the end is still accepted if it reaches Devora within 60 seconds (opens in a new tab), except after a data erasure, and this never extends access.
Two boundaries matter. Capture happens in the agent’s browser, so Devora enforces whether capture is allowed and applies limits, but can’t independently verify what a browser uploads. And your organization remains responsible for end-user notice and lawful basis. The recording also doesn’t replace your own audit events. For how replay compares with live access in debugging, see when session replay isn’t enough.
Test your recording policy in staging
Use a staging account with fake data that looks real, including a password field, a card field and a named region. These are pass conditions to check, not results we’ve run.
| Check | Expected outcome |
|---|---|
| Read-only session with “Write sessions only” selected | No recording made |
| Write session with full masking | Layout and clicks visible; text and media masked |
| Revealed region in a write session | Only that region’s text visible |
| Password, card and one-time code fields | Masked whatever the reveal lists say |
| Replay by an agent who didn’t run the session | Refused |
| Replay by an administrator | Allowed, and the replay is recorded |
| Policy change during a running session | The running session keeps its original policy |
| Recording past its retention period | Replay access gone |
| Audit event for the change made in the session | Present in your application, independent of the recording |
If you want optional, masked recording with automatic retention alongside approvals and scoped access, create a Devora account and try one staging session. Recording is off until you turn it on. The security overview summarizes the rest.
Sources
- EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 5 (opens in a new tab)
- rrweb: Guide, recording options (opens in a new tab)
- OWASP Logging Cheat Sheet (opens in a new tab)
- Devora: Recording privacy and activity logs (opens in a new tab)
- Devora: Session lifecycle, data recorded just before the end (opens in a new tab)