administracion.gob.es

Context

administracion.gob.es is the Punto de Acceso General, Spain’s central government-services portal. Through it, citizens and businesses access procedures across ministries and affiliated bodies, the 060 phone service, calendars, civil-service competitions, and electronic registries. The data controller is the Directorate-General for Public Administration under the Ministry for Digital Transformation and the Civil Service, Madrid, Calle Mármol 2. The Data Protection Officer is dpd@digital.gob.es. The platform is Magnolia.

Scan: 99 requests, three hosts. Ninety-seven requests to the site’s own domain, two to Google. Capture duration: 5.7 seconds; full page load completed at 1166 ms. Captured on May 31, 2026, on the homepage.

Two documents on a single portal page describe the processing: a privacy policy with a processing record, and a cookie policy.

Who receives data directly

Google.

Declared versus actual

The document opens with a promise phrased more emphatically than usual: through the central access point, personal data is not collected without consent, and under no circumstances does this data become subject to processing or transfer to third parties except with the unambiguous consent of the data subject. The processing record reinforces this in a separate line: transfers — not foreseen.

The scan shows the opposite on all three counts, and the discrepancies fall into four groups.

First: there is no consent, and none was ever intended. No consent-management mechanism exists on the portal: no platform, no banner, no category-selection script. The cookie policy doesn’t hide this — it states it outright: the site presumes the user accepts the use of cookies, and suggests they use browser settings if they wish otherwise. Such implied consent as a legal basis for analytics cookies has been excluded in Spain: the Spanish Data Protection Agency’s guidance has not permitted silent acceptance since 2020, and the site itself classifies analytics under the “cookies de análisis” category, which requires prior consent.

Second: the tag is baked into the markup. The request to Google’s tag manager goes out at +438 ms, and the capture directly identifies the initiator: parsing of the main document’s markup, line 93. In other words, the counter is not launched by a script that could wait for anything — it’s parsed by the browser alongside the first stylesheets and page libraries. The GA4 event goes out at +5665 ms, transmitting to Google a client identifier, screen resolution of 1536x864, the Windows platform, system bitness and architecture, a full list of browser versions, interface language, page address, and page title. Screen resolution and the set of browser client hints are fingerprinting parameters.

Third: Google is named, but described incorrectly. The cookie policy lists Google Analytics and immediately characterizes its cookies as “first-party, session, analytics.” They are not first-party: the processor is Google, and it is to Google’s servers that the request goes out. Nor are they session-based: the client identifier, per the timestamp embedded within it, was created at 09:17:03 UTC, sixteen seconds before the capture began — meaning it dates from an earlier visit to the site and is not confined to the current session. The stated four cookies correspond to the Universal Analytics generation, whereas the GA4 stream is what actually runs. That said, the description of what the analytics collects is honest and detailed — down to the city derived from the IP address; the problem lies in the legal classification, not the inventory.

Separately, regarding the second tool. The Dynatrace RUM agent loads from the site’s own domain, followed by two beacons to the path /rb_, carrying a session identifier in the address and bodies of 1434 and 16142 bytes. This is real-user-experience monitoring — measuring performance and errors tied to a session. It is not mentioned once, either in the privacy policy or the cookie policy.

Fourth: the document is so outdated it obstructs the exercise of rights. The section on changing settings suggests restricting, blocking, or deleting “cookies del Ministerio de Industria, Energía y Turismo.” That ministry has not existed since 2018 and has no relation to the data controller — a reader who reaches the cookie-management section receives instructions for a different organization entirely. Management links include one to Internet Explorer, whose support ended in 2022. The description of the USUARIO_SESION cookie states that the user identifier, first name, last name, and roles are stored Base64-encoded: this is a data representation, not a protective measure, and framing it this way in the section on storage of personal data misleads the reader about the actual level of protection.

Technically, it’s worth noting: the site sets no Content-Security-Policy header of its own — only a report-only header arriving from Google’s infrastructure alongside the tag manager’s response. Among protective headers, the site sends strict transport security with preload, a restriction on being embedded in a frame from an external source, a content-type-sniffing restriction, and a referrer policy. The Server header is hidden.

Consent: what is proven and what is not

Proven: there is no consent mechanism on the portal. Across all 99 requests, there is not a single request to a consent-management platform and not a single script bearing the corresponding hallmarks. Known platform names and general patterns in request addresses were checked — zero matches.

Proven: the counter’s loading does not depend on the user’s choice. The initiator of the request to the tag manager is recorded in the capture as parsing of the main document’s markup, with a line number given. The tag sits directly in the HTML and executes during its parsing; there is no condition preceding it, and by its very construction it cannot wait for a choice.

Proven: the identifier existed before the capture began. The client identifier is transmitted to Google in the request body, meaning it is recorded on the device. The timestamp embedded within it points to 09:17:03 UTC — sixteen seconds before the capture’s first request. The main document was requested with a forced-refresh header, consistent with a repeat visit to an already-visited page.

Confirmed by the site’s own document. The phrasing about presumed cookie acceptance and the pointer to browser settings is how sites that don’t operate a consent mechanism typically describe their own behavior. There is no description in the policy of a banner, choice withdrawal, or category settings.

Not proven and not required: the absence of a text notice in the markup. Response bodies have been stripped from the published file, so the presence or absence of an informational notice in the HTML cannot be checked from it. The conclusion is not built on this, but on the fact that the counter’s loading is baked into the markup and does not depend on any notice whatsoever.

Separately: the browser sent a DNT: 1 header during the capture. This had no effect on the composition or volume of the transmissions. The GA4 request carries markers of non-personalized advertising and Digital Markets Act mode — meaning the advertising component is limited; this does not affect the analytics transmission carrying the client identifier.

Limits of observation

The scan covers a single page — the homepage — in a single state. The observation records browser behavior, not the internal workings of the services: server-side processing, contractual relationships with recipients, and the services’ own settings on their owners’ side are not verified by a browser-based scan. Legal assessment falls to the competent authority — the Spanish Data Protection Agency (Agencia Española de Protección de Datos).

The file is published stripped of personal data: Cookie headers in requests, response bodies, the page title, the analytics session identifier, and the bodies of the monitoring beacons have been removed. The set of cookies on a device therefore cannot be reconstructed from the published file, and no conclusion in this analysis relies on it. The fact that the analytics identifier was recorded rests on something else and is verified directly: the identifier was transmitted to Google in the request body, visible in the file.

The monitoring tool is served and receives data on the portal’s own domain. Whether this data subsequently goes out to Dynatrace’s servers or is processed on the administration’s own infrastructure cannot be established by a browser-based scan — only the fact that the tool is active and undescribed in the documents is recorded.

Identification of services relies on domains, address patterns, and file names: Google — via googletagmanager.com and analytics.google.com with a stream identifier; Dynatrace — via the agent name ruxitagentjs, the beacon pattern /rb_, and the session-identifier format. The USUARIO_SESION cookie was not observed in the scan: the session ran without logging into an account, and its contents are analyzed only from the policy’s description.

Conclusion

Spain’s central government-services portal promises, in the very first line of its policy, that data is not collected without consent and is under no circumstances shared with third parties, and its processing record lists transfers as not foreseen. A few paragraphs later, the same document states that the portal presumes the user’s default consent to cookies. The scan shows what this results in: the Google tag is baked into the homepage markup and fires at the 438th millisecond, and at the 5665th, a client identifier goes out to Google together with screen resolution, platform, a list of browser versions, and interface language. There is no consent mechanism on the portal in any form.

Google, meanwhile, is named in the policy — but its cookies are declared first-party and session-based, even though Google is the processor and the identifier outlived the previous visit. The Dynatrace monitoring tool, running on the pages and transmitting session-tied data, is not mentioned at all. The section on cookie management directs readers to a ministry abolished in 2018 and to a browser whose support ended in 2022.

For a portal through which citizens access every government procedure in the country, the gap between what’s declared and what actually happens indicates non-compliance with the requirements on consent and transparency. Remediation: introduce a consent mechanism that actually controls the loading of analytics, and remove the presumption of default acceptance from the policy; move the tag out of the markup and under that mechanism’s control; correct the classification of Google Analytics cookies and bring their inventory in line with the stream actually in use; describe the monitoring tool and the data it transmits; rewrite the cookie-management section, removing the reference to the abolished ministry and the outdated instructions; and either remove the “no transfers foreseen” line from the processing record or bring practice into line with it.