The privacy module: notice versions and data-subject request tracking

We covered the technical side of data protection in a general article: minimisation, access permissions, anonymity. This one looks at the daily operation — who publishes the privacy notice, who reads it, where requests land and how the records are kept.

Two concrete obligations

From an intranet's perspective, data protection produces two practical jobs.

The information obligation: employees must know which of their data is processed and why, and that must be demonstrable.

Data-subject requests: an employee's right to access, rectify and in certain cases request erasure of their data has to be attached to a workable channel.

The whole module is built around those two; the rest is decoration.

Why versioning is mandatory

"We published the privacy notice" doesn't survive an audit. What has to be shown is: who saw which version, and when.

When the text is updated, earlier acknowledgements have to lapse. Otherwise someone who read the notice two years ago counts as informed about today's processing activities — which they aren't.

This is the same versioning logic as the document centre, for the same reason: the acknowledgement must attach to the version, not to the document. We detail it in our documents article.

Where should the notice live?

Making the notice available as a downloadable file isn't enough; it has to be reachable inside the application, with the acknowledgement captured there.

The practical flow: when a new version is published, the employee sees the text at their next sign-in, confirms they have read it, and continues. The acknowledgement is stored with the version number and a timestamp.

There is a balance here: asking the whole company to re-acknowledge after every small correction turns acknowledgement into a meaningless click. The system needs to distinguish a substantive change (a new data type, a new purpose, a new recipient) from a correction (a typo, formatting); only the first should trigger re-acknowledgement.

The request channel

To stop data-subject requests getting lost in an inbox, a trackable channel is needed. What has to be recorded: date of request, type, owner, status and response date.

Response times have statutory limits; having the system track the clock and surface approaching deadlines is the simplest way to manage that compliance risk. A strip in the admin panel showing pending work puts that tracking into the daily routine.

Who should see it?

Request records are sensitive. Only the data protection owner, and where necessary the legal team, should see them — not the employee's manager.

That restriction must be enforced in the data layer. Hiding a record in the interface isn't enough; an unauthorised user must not be able to reach it with a direct data request. We apply the same principle to ethics reports — covered in our ethics hotline article.

The link to offboarding

When an employee leaves, how long which data is kept must be written down. That decision becomes actionable when it turns into an item on the exit checklist: closing the account, returning assets, ending access and recording the start of the retention period.

We cover the process in our onboarding and exit article and the asset side in a separate article.

The audit trail

For compliance to be demonstrable an unalterable record is needed. At minimum: permission changes, access to sensitive data, exports containing personal data and record deletions.

The log itself is expected not to be editable after the fact; a journal that can be edited carries no evidential value.

Export permissions

An often-overlooked risk: a permission that allows downloading the entire employee list is in practice a leak channel. It should be open only to the roles that genuinely need it, and every export should be logged.

No module flag — deliberately

Unlike the others, this isn't a feature that can be switched on and off. Because it corresponds to a legal obligation, it stays permanently visible in the admin panel.

We take the same approach to the audit log, staff shuttles and the exit process: where a job is legally or operationally mandatory, framing it as an optional module offers a false kind of flexibility.

Measurement

• Acknowledgement rate — the share of employees who have accepted the current version.
• Average response time — days from request to resolution.
• Requests approaching the deadline — open records nearing the statutory limit.

The second is the number most often asked for in an audit, and it can't be produced reliably from a hand-maintained spreadsheet.