g4s.ee

Context

g4s.ee is the website of a security company; the controller is AS G4S Eesti, registry code 10022095, Vesipapi 2, Tallinn. The site is served via Apache and keeps a strict header posture: Content-Security-Policy (default-src 'self' with a narrow allowlist), HSTS with preload, Permissions-Policy (including interest-cohort=()), Referrer-Policy origin-when-cross-origin, X-Content-Type-Options nosniff, X-Frame-Options DENY.

The capture is a single recording with navigation across the site: 373 requests, 14 nodes, about four minutes, recorded on 8 September 2026. Processing is described by the ‘Policy and cookies’ document with a cookie declaration.

Who receives data directly

Functionally — LiveChat (support chat), Google (Maps, reCAPTCHA, Fonts) and a single YouTube thumbnail. There are no analytics or advertising recipients in this capture; the Google Tag Manager container generates no request to analytics.

Declared vs. actual

Here the declared and the actual diverge in a rare direction: the site processes data not more, but less, than it describes.

The policy is detailed: it discloses LiveChat as a processor (LiveChat Inc with sub-processors), declares the use of Google Analytics with a caveat about anonymising the IP address, mentions Facebook and LinkedIn in the cookie declaration, and references the Cookiebot platform with a ‘Cookie Declaration’ that can be changed or withdrawn at any time. That is, on paper both an analytics-and-advertising stack and a consent management mechanism are declared.

In fact, in this capture none of the declared trackers fired. Across 373 requests there is no request to Google Analytics, to Facebook, to LinkedIn. The Google Tag Manager container loads, but no downstream request to analytics or advertising follows it. The Cookiebot platform is not in the recording either — that is, the consent management mechanism the policy references is not observed on the page. And the absence of a CMP here leads to nothing: there is simply nothing to gate, since no analytics or advertising requests arise.

What remain are functional components contacting third parties without an explicit consent gate. The LiveChat support widget loads its tracking.js on entry; LiveChat is disclosed in the policy as a processor, and the widget itself serves the chat. The Google Maps map is pulled in on navigating to a page with a map, reCAPTCHA on navigating to a form, the web fonts from the stylesheets; all of them carry the IP address to Google. This is functional and protective delivery, not advertising-and-analytics tracking; it is noted as a caveat, not as a discrepancy.

Consent: what is proven and what is not

Proven: the declared analytics-and-advertising stack did not fire in this capture. No request to Google Analytics, Facebook or LinkedIn across 373 requests. The Google Tag Manager container launches no downstream tags.

Proven: there is no consent management platform in the recording. No request to Cookiebot or any other CMP is found in the file, although the policy references Cookiebot.

Proven: the functional components load without a gate. LiveChat tracking.js — at +1114 ms; reCAPTCHA — on navigating to a form; Google Maps — on navigating to a page with a map.

Not proven, and not required: the exact consent state. Since no tag with a consent signal fired, there is no machine flag of ‘given/refused’ in the recording; what matters is that the declared stack made no outward request.

Observation boundaries

The capture covers several pages of the site and records browser behaviour, not the services’ internal workings: the configuration of the Google Tag Manager container, server-side processing and contracts with recipients are not verified by a browser-level capture. The absence of requests to analytics means that no analytics collection is observed in the browser in this capture; what the container would send under a different set of tags or on other pages is not established from the recording. The content-management-system media (g4s-strapi-media.s3…amazonaws.com) is classified as first party; the LiveChat widget as the functional part.

The file is published redacted of personal data: cookie values in requests have been removed. Response headers, the load order and initiators are preserved, so the composition of the requests and the absence of downstream analytics are verified directly against the published file.

The legal assessment is made by the competent authority — Andmekaitse Inspektsioon.

Conclusion

The audit is clean. The security company’s website keeps strict security headers and, in this capture, launches no analytics or advertising tracker: the Google Tag Manager container loads but pulls nothing behind it, and the Google Analytics, Facebook and LinkedIn declared in the policy are silent. The discrepancy between the declared and the actual here is in the user’s favour: the site processes less data than it declares.

The caveats concern not tracking but configuration and functional delivery. The policy references the Cookiebot consent management platform and a ‘Cookie Declaration’, but the platform itself is not in the recording — this mechanism is not observed on the page (though there is nothing to gate). The functional components — the LiveChat support chat, the Google Maps map, reCAPTCHA and Google fonts — contact third parties without an explicit consent gate and carry the IP address to Google and LiveChat.

Remediation (as hardening, not as a fix for a violation): bring the policy into line with the facts — if Cookiebot and the declared analytics-and-advertising stack are no longer in use, remove the references to them from the document, and if they are used on other sections, ensure that the consent platform loads and gates them; consider self-hosting the fonts and loading the map and video thumbnails via a facade placeholder so that the IP address does not go to Google before it is needed.