A GDPR-compliant intranet: what to watch for with employee data

By its nature an intranet processes employees' personal data: name, title, contact details, department, leave requests, sometimes date of birth and a photograph. That data falls under the GDPR — and under KVKK for companies operating in Turkey — which makes choosing an intranet a legal decision as much as a technical one.

This article is general information; consult your legal counsel for obligations specific to your company.

Start with data minimisation

The soundest compliance strategy is the data you never process. The question to ask during setup is simple: is this field genuinely necessary? If a date of birth is there for celebrations, day and month without the year is enough. A personal mobile number should not be collected while a corporate line exists.

The same principle applies to notification channels: channels requiring a personal number should be off by default and opt-in, while corporate channels can work on an opt-out model.

Privacy notices and version tracking

Employees need to know which of their data is processed and why. An intranet is expected to support that in two ways: the notice must be reachable inside the application, and it must be versioned. When the text is updated, a record of who saw which version has to be kept; otherwise the claim that someone was informed cannot be evidenced.

Data-subject requests

Employees have the right to access and rectify their data, and in certain circumstances to request erasure. So that these requests don't get lost in an inbox, a trackable channel inside the intranet is a practical necessity: the request record, the owner, the status and the response time should all be visible.

Access permissions: hiding is not enough

The most common technical mistake is hiding a field only in the interface. The real restriction must live in the data layer; otherwise an unauthorised user can reach that information through a direct data request. When evaluating a vendor the question is precise: "Who cannot see this field, and where is that restriction enforced?" If the answer points only at the interface, it is insufficient. We describe our approach on the security page.

The same logic applies to tenant isolation: in a multi-tenant product, the impossibility of reaching another company's data has to be guaranteed at the database level.

Flows that require anonymity

In components like an ethics hotline, anonymity is not a preference but a precondition for use. The critical detail: anonymity cannot be left to the client. If the "don't send the identity" decision is taken in the browser, the record can still arrive with an identity attached. In a correct design the identity is stripped on the server, at the moment of writing.

A similar threshold applies to pulse surveys and mood checks: results should only be shown aggregated above a minimum number of respondents, so that individual answers cannot be inferred in small teams.

Retention periods and offboarding

How long data is kept must be written down. When a leaver's account is closed, what remains — the announcements they wrote, the recognition they received, the assets assigned to them? Those answers belong in the offboarding process, and the intranet should be able to track those steps.

Hosting and sub-processors

Where the data is held, which sub-processors are involved and whether there is any cross-border transfer should be obtained in writing before purchase. This information is an inseparable part of the security questions in our selection guide.

Evidence: the audit trail

The dimension of compliance most often overlooked is that the work must be demonstrable. In an audit, "we published the privacy notice" is not enough; you need to show who saw which version and when, when a data-subject request arrived and how many days it took to answer.

That is why the scope of the audit trail matters: permission changes, access to sensitive data, exports containing personal data and record deletions should all be logged at a minimum. The log itself is expected to be tamper-evident; a journal that can be edited afterwards carries no evidential value.

Export functionality deserves separate attention: a permission that allows downloading the entire employee list is, in practice, a data-leak risk and should be opened only to the roles that need it.

A short checklist

• Does every field collected have a justification?
• Is the privacy notice versioned and accessible?
• Is there a trackable channel for data-subject requests?
• Are permission restrictions enforced in the data layer?
• In anonymous flows, is the identity stripped server-side?
• Are retention periods and the offboarding process defined?

Get in touch with any compliance questions.