Website Technology Audits and the GDPR

The legal framework

A website is a processing operation. Whenever a visitor loads a page, their IP address reaches your server and, usually, servers of third parties whose scripts, fonts, maps, video players or analytics are embedded. The legal duties that follow are spread over several rules.

• Transparency (Articles 12 to 14 GDPR). Visitors must be told who is responsible, why data is processed, on what basis, who receives it, where it goes and how long it is kept. The privacy notice must describe what the site actually does.
• Lawfulness (Article 6). Each purpose needs a legal basis. For tracking, that is generally consent, which the ePrivacy rules require anyway for storing or reading information on the device (Article 5(3) of the ePrivacy Directive).
• Controller roles (Articles 26 and 28). The Court of Justice held in Fashion ID (Case C-40/17) that a website operator that embeds a third-party plug-in can be a joint controller for the collection and transmission of the visitor's data to that third party. A processing agreement is needed for providers acting as processors.
• Transfers (Chapter V). Many embedded services send data to servers outside the EEA, which needs a transfer basis. See international data transfers.
• Security and privacy by design (Articles 25 and 32). Encrypted connections, access controls, form handling and defaults that collect no more than necessary.
• Accountability (Article 5(2)). You must be able to show the above, which includes the record of processing.

What an audit examines

A technology audit compares the privacy notice and the consent banner with what the website really does. It typically covers:

• all cookies, pixels, local storage and scripts loaded, before and after consent, with the party behind each;
• the behaviour of the consent banner: whether tags are blocked until consent, whether rejection works, whether the consent is recorded;
• third-party requests, such as fonts, maps, video, chat widgets, tag managers, and the countries of the servers receiving them;
• forms: what is collected, with which legal basis, where it goes (CRM, email tool, spreadsheets) and for how long it is kept;
• the privacy notice and cookie policy against these findings;
• security basics such as HTTPS, headers and the handling of data in forms.

The result is a list of findings by risk, with the legal rule, the evidence and the fix.

In practice

A Limburg manufacturer relaunches its website with an agency. Its privacy notice, drafted two years ago, mentions a single analytics tool. The audit finds seven: the analytics tool, an advertising pixel, a heat-map tool, a chat widget, an embedded video player that sets cookies, a font service loaded from a US server and a form plug-in that stores submissions on a third-party server. Four of them load before the visitor makes a choice in the banner.

The audit leads to concrete decisions. The heat-map tool is removed, since the manufacturer cannot justify it. The video player is switched to a mode that sets no cookies until playback. Fonts are hosted locally. The tag manager is configured to wait for consent. The form data now goes to the manufacturer's own CRM, with a processing agreement with the CRM provider. The privacy notice and cookie policy are rewritten to match, and the register has new entries for each tool.

Why repeat it

Websites change constantly: a marketing team adds a tag, a plug-in updates, an agency swaps a supplier. A one-off audit becomes stale. Run it again after major changes and at a fixed interval, and assign an owner for tag approvals.

Frequently asked questions

Is a cookie banner enough?

No. The banner is one part. The tags must really be blocked until consent, the notice must be accurate and the third-party relationships must be documented.

Does a purely informational website have to comply?

Yes. A static site that loads an analytics script, a map or a font service processes visitors' personal data. A site that loads nothing from third parties and keeps minimal server logs has a much lighter footprint.

Who is liable, the agency or the website owner?

The owner is responsible as controller. The agency can be liable to the owner under their contract, so the contract should say who must deliver a compliant configuration.

Do we need a DPIA for tracking on our website?

Not always. Extensive profiling, tracking across sites or processing of sensitive data may call for one. The screening of the DPIA function helps decide.

How this connects

Website audits feed directly into DPO as a Service: findings become register entries in the privacy register and tasks that your team and the DPO follow in the client portal. Consent design is covered in Cookies and Consent.