Operating a website that collects, processes, or transmits personal data is not a passive activity under the GDPR; it creates active compliance obligations that apply from the moment the website is accessible and continuously throughout its operation. Unlike a paper-based processing activity where the data collection is visible and discrete, a website's data processing footprint is often invisible to its operators: third-party scripts load cookies and tracking technologies, fonts and analytics tools make outbound connections to external servers, contact forms transmit data to CRM systems, and embedded widgets collect behavioural data in ways that the website owner may not have reviewed in detail since the site was built.
A website technology audit systematically identifies these data flows, maps them against the GDPR's requirements, and identifies compliance gaps. It is not a one-off exercise: technology stacks change, new tools are added, third-party scripts are updated, and the regulatory framework evolves. Organisations that conduct an initial audit without a mechanism for ongoing monitoring are likely to find that their compliance position degrades as the website evolves.
A comprehensive GDPR website technology audit covers five principal areas. First, cookie and tracker identification: a technical scan of the website to identify all cookies and tracking technologies loaded, their categories, their purposes, and the third parties they transmit data to. This includes first-party cookies, third-party cookies, local storage, session storage, pixels, and any other mechanism for storing or accessing information on the user's device.
Second, consent mechanism review: assessment of the cookie consent management platform against the requirements of the ePrivacy Directive and the GDPR. This includes the consent interface design (no dark patterns, equal prominence for reject), the technical implementation (cookies not set before consent is obtained and consent correctly blocked if declined), the consent record, and the withdrawal mechanism. Regulators have published specific guidance on what does and does not constitute valid consent, and the audit should assess compliance against that guidance.
Third, third-party data flows: identification of which third-party services receive personal data through the website (analytics providers, advertising networks, CRM platforms, customer support tools, marketing automation systems) and assessment of the legal basis for each data flow, the adequacy of the data processing agreements with each processor, and, where data is transferred to third countries, the transfer mechanism relied upon.
Fourth, privacy notice compliance: review of the website's privacy notice against the transparency requirements of Articles 13 and 14 GDPR. The notice must describe all processing activities accurately, identify the controller and DPO contact details, specify the legal basis for each processing activity, describe data subject rights and how to exercise them, and provide information about international transfers and retention periods. Common failures include notices that describe purposes in vague terms, omit reference to specific third-party processors, or do not reflect the actual processing activities identified in the technical audit.
Fifth, data subject rights infrastructure: assessment of whether the mechanisms for exercising data subject rights (DSAR submission, consent withdrawal, erasure requests) are functional, accessible, and connected to the backend processes that fulfil them. A DSAR link in the privacy notice that leads to a broken form, or a cookie withdrawal mechanism that does not actually prevent cookies from being set, are compliance failures in their own right.
Website technology audits consistently identify the same categories of failure across organisations of all sizes. Google Analytics loaded without consent is the most common finding, typically because the analytics script is loaded unconditionally in the website's base template rather than being gated on consent. Third-party fonts loaded from Google Fonts or similar CDNs transmit the user's IP address to the font provider without a legal basis and without disclosure in the privacy notice. Marketing automation tools (HubSpot, Salesforce, Marketo) loading tracking scripts that set cookies before consent is obtained. Privacy notices that were written at launch and not updated to reflect the current technology stack. Contact forms that do not clearly identify the controller or describe the processing of form data.
An initial audit should be conducted before or shortly after launch of any new website or after a major technology migration. Thereafter, a full audit should be conducted at least annually. Additionally, a targeted review should be conducted whenever significant changes are made to the website's technology stack (adding a new analytics tool, switching email marketing platform, embedding a new third-party widget, or making changes to the cookie consent mechanism). The practical trigger for a targeted review should be any change that adds a new external data flow or modifies an existing one.
A website technology audit and a DPIA are related but distinct. The audit identifies what processing is occurring; a DPIA assesses the risks of high-risk processing activities and identifies mitigation measures. Where the audit identifies processing that meets the GDPR's threshold for a DPIA (systematic and extensive profiling with significant effects, large-scale processing of special category data, systematic monitoring of publicly accessible areas) a DPIA must be conducted for those activities. The audit findings provide the factual input for the DPIA's description of the processing.
Not if the fonts are loaded directly from Google's servers in the default configuration. Loading fonts from Google Fonts CDN causes the user's browser to send a request to Google's servers, transmitting the user's IP address to Google, which constitutes a transfer of personal data to a third party. Supervisory authorities, including the Austrian DSB, have found this to violate the GDPR's transparency and transfer requirements. The compliant solution is to self-host fonts: download the font files and serve them from your own server, eliminating the external data transmission.
The controller (the organisation operating the website and determining the purposes of the data processing) is responsible for GDPR compliance, regardless of whether the website was built by an external agency. The agency may be a processor under the GDPR for the development work, but this does not transfer the compliance obligation. The controller must ensure that the website it operates complies with the GDPR, which means reviewing the technology choices made by the agency, maintaining an up-to-date cookie policy and privacy notice, and conducting ongoing audits as the site evolves.
%402x.svg){kind=icon}
%402x.svg){kind=small}
%402x.svg){kind=icon}
