RU EN
www.
Technical audit · 16.06.2026

amsterdam.nl

Official website of the City of Amsterdam
NL

Amsterdam.nl is the official website of the City of Amsterdam. Homepage scan: 72 requests, 10 domains. The city handles its web statistics exemplarily: on its own Piwik PRO platform, with the visitor's IP not stored, per policy — such statistics are anonymized and do not require consent. The scan shows no third-party advertising, no Google Analytics, and no social media pixels. But before consent, the page initializes a third-party co-browsing tool: it registers a device identifier on the third-party service's servers and opens a persistent connection. The screen display itself only occurs when the user contacts support, but the connection and third-party identifier are created upon page load, before the user's choice.

Request timeline

1314 ms · survey service
The Usabilla survey service loads — a feedback-collection tool that is, per policy, anonymous.
1505 ms · anonymized city statistics
The city's own statistics load on the Piwik PRO platform. Per policy, the visitor's IP is not stored — the statistics are anonymized and exempt from consent.
1960–1961 ms · monitoring and support chat
Dynatrace performance monitoring and the support chat infrastructure connect. These are technical and functional services.
2294 ms · co-browsing loads
A third-party co-browsing tool (screen-sharing for support) loads.
2599 ms · device identifier registration
The co-browsing tool registers a device identifier on the third-party service's servers. That is, an identifier is created with a third party before consent.
3605 ms · persistent connection to third-party service
Co-browsing opens a persistent connection via web socket to the third-party service. The connection is established upon page load, before the user's choice.
own banner present, consent not given
The site has its own consent banner, and in this session consent was not given. The statistics are anonymized, but by this point the co-browsing connection and third-party identifier have already been established. Not a single cookie was set during the session.

Declared versus actual

✓ Piwik (statistics) — declared
✓ Co-browsing (per policy) — declared

Detected trackers

Indicators of GDPR non-compliance

Context

www.amsterdam.nl is the official website of the City of Amsterdam (Gemeente Amsterdam): municipal services, information for residents, requests to city departments. The data controller is the Municipality of Amsterdam. The site is informational and service-oriented.

Scan: 72 requests to 10 domains, homepage, captured in a clean Edge browser without a VPN or ad blocker. The site has its own consent banner. The technical stack includes anonymized statistics, support tools, and monitoring.

Who receives the data

Observed here: Cobrowse.io (co-browsing), Salesforce (support chat).

The city runs its web statistics on its own Piwik PRO platform, with the visitor’s IP not stored, per policy — this is anonymized statistics. Support uses a chat built on the Salesforce platform and a third-party co-browsing tool that lets an agent see the user’s screen when they reach out. Additionally, Dynatrace performance monitoring and a survey service are running. The scan shows no third-party advertising, no Google Analytics, and no social media pixels.

Yes, the site has its own consent banner, and in this session consent was not given. Not a single cookie was set during the session.

The web statistics are set up correctly: they are anonymized (IP not stored) and exempt from consent. The co-browsing tool, however, establishes a connection and an identifier with a third party before the user’s choice.

Before consent, the following fire:

  • anonymized city statistics (Piwik PRO) — exempt from consent;
  • co-browsing initialization — device identifier registration and a persistent connection to a third-party service;
  • performance monitoring and support chat (technical and functional).

The statistics are not a concern here — they are anonymized. The key issue is co-browsing: the screen display itself only occurs when the user contacts support, but the preparatory connection and third-party identifier arise on a simple page load. Co-browsing is not required for the page to function, so such a connection before consent requires a legal basis.

What works in the site’s favor

This is worth highlighting. The city runs its statistics anonymized, without storing IP addresses, and uses no Google Analytics, no social media pixels, and no advertising networks. The main risk — a scatter of advertising trackers — is entirely absent here. The support tools (chat, co-browsing) are functional, not advertising-related.

Conclusion

Amsterdam.nl is, on the whole, a restrained municipal site with one narrow issue. The web statistics are anonymized and don’t require consent, and there is no advertising or third-party analytics at all. But the third-party co-browsing tool registers a device identifier and opens a persistent connection to a third-party service upon page load — before the user has given consent, even though the screen display itself is only needed when the user contacts support. The key takeaway for the reader: even a tool that is functional in purpose must, if it establishes a connection and identifier with a third party, be initialized only after consent or only at the moment the user actually requests support. It would be enough to defer the co-browsing connection until the user reaches out — and the site would be clean.

Evidence

How to verify: download the file and compute its checksum — sha256sum file.har (Linux, macOS) or certutil -hashfile file.har SHA256 (Windows); it must match the one shown. The conclusions apply to the scope of this measurement — see the limitations of the method.

Original (audit)
HAR file: nl/amsterdam-nl-2026-06-16.har
SHA-256: ae68ef81ba5b1c50c487bfb9ea140a41fecfd07ae017526f3c35f5849f08e3d5
Re-check snapshot
Awaiting changes
HAR files are stored on EU infrastructure (Proton Drive). SHA-256 is published for integrity verification.
Want a response from the company about this audit? → Open the tool

Fill in once — it will be inserted into every letter below:

All fields are required to print the document — this is a formal requirement of the letter itself (the particulars of an official submission), not data collection: nothing is sent or saved anywhere, it all stays in your browser and disappears when you close the page. See the methodology for details.

Step 1. Data access request (GDPR Art. 15)

Send this letter directly to the company first — before contacting the regulator it has the right to respond (GDPR Art. 12(3) — 30 days).

Subject: Data access request (GDPR Art. 15) — amsterdam.nl

To: [insert the company's address — DPO / support / legal department]
From: [Your name], [contact email]

I request access to my personal data processed in connection with the website amsterdam.nl.

1. Categories of data and purposes of processing (Art. 15(1)(a)-(c))
Based on an independent technical analysis of the site, I request confirmation and detailed disclosure of the following categories of processing:

1) The site has its own consent banner, and in this session consent was not given. The city runs its web statistics correctly: on its own Piwik PRO platform with a non-anonymized IP that, per policy, is not stored — such statistics are anonymized and exempt from consent. The problem lies elsewhere. Before consent, the page initializes a third-party co-browsing tool (screen-sharing for support): it registers a device identifier on the third-party service's servers and opens a persistent connection via web socket. In other words, a connection is established and an identifier created with a third party before the user has made any choice. The screen-sharing itself only happens when the user contacts support, but the preparatory connection and third-party identifier arise on a simple page load. Co-browsing is not a function necessary for the page to work, so establishing such a connection before consent requires a legal basis under Dutch cookie law.


2. Recipients, retention periods, and transfers outside the EEA (Art. 15(1)(c)-(d), 46)
I also request the full list of third-party recipients, the applicable retention period for each category, and the legal basis for any transfer of data outside the EEA. The full technical audit with evidence (saved network log, SHA-256 checksum) is published at: https://gdpru.eu/en/audits/nl-amsterdam-nl/

3. Automated processing and profiling (Art. 15(1)(h))
Please state whether I am subject to automated decision-making or profiling, and if so, disclose the logic involved.

Sincerely,

[Your name]
[contact email]
[Country]


[Date]
IMPORTANT: before filing a complaint with the regulator, first contact the company directly and give it 30 days to respond. Without this step the regulator may reject the complaint. Details and a template letter to the company are in the Methodology.
Ready-to-send complaint letter

Where to file: Dutch Data Protection Authority (AP) — autoriteitpersoonsgegevens.nl

The regulator reviews complaints in its national language. There is an officially translated template from the European Data Protection Board (EDPB) — you can use it instead of or alongside this letter: Official EDPB complaint form (PDF, your language)

Subject: Complaint regarding personal data processing — amsterdam.nl

1. Subject of the complaint
I am filing a complaint regarding the processing of my personal data by the website amsterdam.nl.

2. Circumstances
I visited the website amsterdam.nl and found indications that the processing of my personal data does not comply with the GDPR. The technical analysis published on gdpru.eu on 16 June 2026 (open methodology, reproducible measurements) documents the following indications:

1) The site has its own consent banner, and in this session consent was not given. The city runs its web statistics correctly: on its own Piwik PRO platform with a non-anonymized IP that, per policy, is not stored — such statistics are anonymized and exempt from consent. The problem lies elsewhere. Before consent, the page initializes a third-party co-browsing tool (screen-sharing for support): it registers a device identifier on the third-party service's servers and opens a persistent connection via web socket. In other words, a connection is established and an identifier created with a third party before the user has made any choice. The screen-sharing itself only happens when the user contacts support, but the preparatory connection and third-party identifier arise on a simple page load. Co-browsing is not a function necessary for the page to work, so establishing such a connection before consent requires a legal basis under Dutch cookie law.

Full technical documentation is published at: https://gdpru.eu/en/audits/nl-amsterdam-nl/

3. GDPR provisions I ask you to examine
Art. 6(1)(a) GDPR and art. 11.7a Telecommunicatiewet — third-party co-browsing tool establishes a connection and identifier before consent

4. Request
I request that you examine the circumstances described and, if non-compliance is confirmed, apply the measures provided for in Article 58(2) GDPR.

5. Attachments
The full evidence base — the HAR file, its SHA-256 checksum and the quotation from the site's privacy policy documenting the stated contradiction — is published and verifiable at the link in point 2 above.

Sincerely,

[Your name]
[contact email]
[Country]


[Date]