Co-browsing and GDPR: consent, scope and retention

Co-browsing consent is the visitor's explicit, in-browser agreement to share the page they are on with a support agent, given after being told what that agent will be able to see and do. Co-browsing under the GDPR is mostly a scope question, not a consent-banner question. A shared-page session means a named person at your company can see a page rendered for one identified visitor, possibly including data that visitor typed. What makes it lawful is being able to say what is shared, on what legal basis, for how long, and under which contract.

Search for this and you will mostly find cookie-consent material. That is a different problem. Cookie banners are about storing and reading information on a device, which is an ePrivacy question. A co-browsing session is about processing what is on a screen, which is a GDPR question, and the two have different rules and different answers.

This article is a practical checklist, not legal advice. Your data protection officer or counsel decides what applies to you.

What does a co-browsing session actually share?

Co-browsing shares a rendering of a web page the visitor is already on, in real time, with a support agent. It is narrower than screen sharing, which shares a surface the visitor selects: a tab, a window or a display. The difference matters because the narrower scope is what makes the risk assessable at all.

But "narrower" is a property of a particular product, not of the category. Across vendors, co-browsing sessions differ on at least four axes:

• What is in scope. The current page only, or any page on your domain, or any page at all.
• What the agent can do. View and point, or also click, type, navigate and submit.
• What is hidden. Which fields are masked, and whether masking is applied before the data leaves the browser or only on the agent's display.
• What persists. Nothing, a log line, or a recording of the session.

Two products both called "co-browsing" can sit at opposite ends of all four. Write down where yours sits before you write anything in a privacy notice.

Does co-browsing need consent under the GDPR?

For a session the visitor asks for, legitimate interests is usually the workable basis, because the processing is what they requested and they expect it. Consent becomes the right basis where the visitor must be able to refuse without losing the service, which is exactly the case for a shared view of their screen. Article 6 of the GDPR lists the available bases.

The practical reading is that you need two things, not one. You need a lawful basis for the processing, and you need the visitor's actual agreement to start the session, because starting it without asking would be both unexpected and unnecessary. The text of Article 6 is the primary source worth reading rather than a summary of it.

Where consent is your basis, the GDPR's definition sets the bar: freely given, specific, informed and unambiguous, by a clear affirmative action. The European Data Protection Board publishes the guidance that supervisory authorities apply. Three consequences follow for a co-browsing request:

• It cannot be bundled with accepting a call or agreeing to a recording. Those are separate purposes and need separate decisions.
• It cannot be pre-ticked or implied by continuing to browse.
• It has to be as easy to withdraw as to give, which in practice means a visible stop control, not a buried setting.

Device storage is a separate question

If your widget writes an identifier to the visitor's browser, that write is governed by ePrivacy rules and is usually covered by your consent tool, independently of anything co-browsing does. Ask your vendor one precise question: when does the first write happen, at page load or at first interaction? The answer determines whether the widget must sit behind your consent banner.

What the request has to say

The request the visitor sees is the promise you are making, and the product must not exceed it. A request that undersells the capability is not informed consent, even if the capability is never used. Name who is asking, what they will see, what they cannot do, and how to stop.

A workable request is short and specific. "Olivia would like to see this page with you. She can point at things. She cannot click or type, and she will not see other tabs or your password fields. You can stop sharing at any time." Every clause in that sentence is checkable against the product.

In GreetDock's co-browsing the visitor accepts before the page is shared, the team can use a pointer, spotlight and pen, and the product cannot click, type or navigate for the visitor. Sensitive input values, other tabs and desktop applications are not shared, and the visitor has a visible stop control. Those are GreetDock's documented boundaries, which is the only kind of claim worth putting in a privacy notice.

Masking: what "hidden" has to mean

Hidden must mean the value never leaves the visitor's browser, not that it is blurred on the agent's screen. A blur applied after transmission means the data was still sent, still crossed a network, and may still sit in a log. Ask where the masking happens, and treat "the agent cannot see it" as an incomplete answer.

Then ask which fields are covered. Password inputs are usually masked by default. Payment fields, national identifiers, free-text notes and anything your own application renders as plain text often are not, because the vendor cannot know your markup. The configuration work of naming those fields is yours, and it is the step most often skipped between a demo and a launch.

Who is the controller, and what must the DPA say?

In the normal arrangement you are the controller and the co-browsing vendor is the processor, which means Article 28 requires a written contract before any processing starts. If you are an agency running a widget on a client's site, the chain has three links: your client is the controller, you are a processor, and the vendor is a sub-processor.

That chain decides who answers a visitor who asks what was seen during a session. It should be settled in writing before launch, not discovered when the question arrives. Read the vendor's data processing agreement and specifically its sub-processor annex, because that is where the actual list of companies touching the data lives.

Two things to check in any DPA for this feature:

• The sub-processor list is specific. Named companies and the role each plays, not a category like "cloud infrastructure".
• Hosting location is stated for each processing step. The application and database, any real-time relay that carries the session, and any AI processing can sit in different places. GreetDock documents its arrangement on the security page.

Retention, and how a session ends

Decide what survives the session before you enable it. A co-browsing session that stores nothing has almost no retention problem. The moment a session is recorded, you have created a record that must be stored securely, found on request, and deleted on a schedule you can state.

Give each record type its own line: the consent event, any session log, any recording, and the conversation thread the session happened inside. A single sentence saying "as long as necessary" is not a retention schedule and will not survive a question from a customer's security review.

Recording a call is a separate decision from sharing a page, and in several member states it carries stricter national rules than the GDPR alone. If you are considering both, treat them as two projects.

A pre-launch checklist

Run this before the feature is visible to a single visitor. Each item is a question with a written answer, and the answers together are most of what a security reviewer will ask for.

The useful property of this list is that it is answerable. If a question cannot be answered about your setup, that is the finding, and it is better found now.

Co-browsing sits inside a wider set of choices about talking to website visitors, alongside chat and browser calls: see the guide to live chat, calls and co-browsing for how the three fit together, and what to do when nobody is free for the availability side.

GreetDock is built in Vilnius, Lithuania, and is in private beta. You can read the privacy policy or apply for early access.