Keeping process documentation private

Why screenshots in a guide are a data protection question

Process documentation is made in live systems. A support agent at Northwind, a made-up company, records how to refund an order in the CRM, and the screenshot of the refund screen shows the customer's name, delivery address and order history. The guide was about the refund button; the picture also carries a customer record.

• It is personal data. Art. 4(1) GDPR defines personal data as any information relating to an identified or identifiable person. An image counts when it identifies someone directly or indirectly, as GDPR Local puts it for photos; a name and an address on a screen do that.
• Capture only what the step needs. Art. 5(1)(c) asks for data minimisation and Art. 25 for data protection by default. For a guide, that means a test account or demo data first, and redaction second.
• Colleagues count too. Avatars, "assigned to" columns and audit logs name the people who work in the system. They keep their rights of access under Art. 15, and a screenshot can outlive their time at the company.

This section applies the articles to documentation work. It is not legal advice: the data protection officer, or the national supervisory authority, decides the specific case. How to blur, crop and redact a screenshot properly is covered in screenshots in documentation.

Where the screenshot goes decides the paperwork

The same Northwind refund guide, made with two kinds of recorder: one that keeps the files on the machine it runs on, and one that uploads them to its vendor's cloud.

An upload is not forbidden. It is paperwork and trust: under Art. 28 the vendor becomes a processor and needs a contract, and a transfer outside the EU falls under Chapter V. A recorder that uploads nothing removes the processor question for the screenshots themselves. It does not remove the question of what the screenshots show.

What a browser extension can see

A browser extension is a small program that runs inside the browser with the permissions it declares in a manifest file. Chrome turns some of those permissions into warnings at install time. For a recorder, these are the ones to read, with the warning text from Chrome's permissions list:

• activeTab: temporary access to the current tab, granted only when the user clicks the extension. No warning.
• tabs: titles and addresses of open tabs. Warning: "Read your browsing history".
• scripting: running code in a page the extension has access to. No warning on its own.
• Host permissions: access to sites without a click. For all sites the warning is "Read and change all your data on all websites".
• downloads: saving files. Warning: "Manage your downloads".
• storage: keeping settings and data inside the browser. No warning.

Host permissions can be required, granted at install, or optional, asked for at the moment a feature needs them and withdrawn later, as Chrome's guide to permission warnings recommends. In chrome://extensions, under Details, site access can be set to on click, on specific sites, or on all sites.

What permissions do not tell you is whether data leaves the machine. A permission to read a page says what the extension can reach, not where it sends it. That takes the check below.

How to check what an extension sends

Three minutes, no tools beyond Chrome:

1. Open chrome://extensions and the extension's Details. Read the permissions and the site access, and set site access to on click.
2. Turn on Developer mode at the top right. Under Inspect views, click the service worker link: it opens DevTools for the extension's background code, as Chrome's debugging tutorial shows. Open the Network panel and leave it recording.
3. Do the real job once: record a short task and export it. Then read the request list. An extension that uploads shows requests to its own servers; one that does not leaves the list empty.
4. Open the extension's own pages, such as the popup and the editor, and inspect them too: each has its own DevTools and its own Network panel.

What the check covers, and what it does not:

• It covers the version you ran, on that day, for the job you did. An update can change the behaviour; repeat the check after one.
• Code an extension runs inside a web page shows its requests in that page's own DevTools, mixed with the site's requests.
• For everything the browser sends in one session, chrome://net-export writes a full log to a file.

How IT approves and rolls out an extension

The usual setup is to block every extension and allow approved ones by ID. In the Google Admin console, per Google's help on apps and extensions, the path is Devices > Chrome > Apps & extensions, and the Chrome Web Store setting offers three modes:

• allow all apps, admin manages a blocklist;
• block all apps, admin manages an allowlist;
• block all apps, admin manages an allowlist, users may request extensions.

Each approved extension is then added by its ID and either allowed or installed for everyone. Without the Admin console, the same rules are set as policies: ExtensionInstallBlocklist set to * plus ExtensionInstallAllowlist with the approved IDs, through Group Policy or the registry on Windows and configuration profiles on a Mac, as Google's guide to managing extensions and the Chrome policy list describe.

Two more controls are worth knowing. Admins can block extensions by the permissions they ask for, and can keep all extensions off named sites, such as the HR system, with runtime blocked hosts. An extension can also read settings an admin sets by policy, through Chrome's managed storage, which the extension can read but not change.

An approval sheet to hand to IT

Fill this in for the tool before you ask. It answers most of what IT and the DPO will ask first.

Extension

Name, version, Chrome Web Store link, extension ID (32 letters, shown under Details)

Permissions

As listed in the manifest, with the warning each one shows

Host permissions

Which sites; required at install or optional at use time

Store privacy

What the privacy section of the Web Store listing says is collected

Data stored

Where the screenshots and guides are kept: on the computer, or on the vendor's servers (and where)

Managed policy

Whether the extension reads admin settings from managed storage

Network check

Date, version tested, job done, requests seen (none, or to which hosts)

Where to keep finished SOPs

Once exported, a guide is a file, and it is as private as the place it is kept. A file share or an intranet page with access rights protects it; a public share link does not.

• Review guides that contain personal data when the people in them leave or the process changes. Replace the screenshot instead of keeping a stale one.
• Prefer self-contained exports, such as a PDF or a single HTML file. What is in the file is visible, and nothing links back to a vendor's copy.

Doing it with a recorder that uploads nothing

Every check on this page works for any tool. The table above shows why the simplest answer to the processor question is a recorder that never sends the screenshots anywhere.

Sources