What your municipality can learn from the Dutch DPA report on the Tax Administration

Picture this: you are the privacy officer at a Dutch municipality. The Work and Income department uses a set of risk rules to select social assistance applications for an extra check. Nobody remembers exactly why the rules were chosen; they have been running for years. Staff can see almost everything in the systems, and an old folder of investigation files sits "temporarily" on a shielded drive.

Sound familiar? Then the report the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) published on the Tax Administration on 11 November 2026 is written for you too.

What the AP found

The AP has applied intensified supervision to the Tax Administration since 2024, because from 2019 to 2022 it received more sanctions than any other public body. In its news item and report of 11 November 2026 the AP gives two scores per topic: compliance (does the organisation comply with the GDPR) and effectiveness (does it tackle the problems quickly and with results). Compliance also takes into account whether the improvement is secured for the long term. The GDPR requires not only appropriate measures, but also that you review and update them (Article 24 GDPR).

The intensified supervision runs until mid 2029 for now. The next edition is due in January 2028. Below are the lessons that apply to any organisation, with a municipality as the example.

Lesson 1: justify every selection tool and test it for discrimination

The Tax Administration uses about a hundred selection tools to select tax returns and applications for checks. In 2025 it reported that the selection criteria of more than half rested on general experience or were not documented. By mid 2026 three had been reviewed. The AP is clear: anyone working with selection criteria by definition distinguishes between groups of people. You must justify that distinction precisely, and test whether the outcome is not unintentionally unfair. Without that justification the processing quickly becomes discriminatory and therefore unlawful.

For the municipality this means: list all risk rules and profiles, for example in social assistance, debt relief or enforcement. Record for each rule why it exists, which data it uses and how you tested for unequal outcomes. Also decide in advance what happens if a tool turns out to discriminate: who switches it off, and within what time. That was exactly what the Tax Administration still lacked.

Lesson 2: can you show that a person really reviews the outcome?

According to the Tax Administration, more than three quarters of its selection tools involve human intervention. For the rest there is none, or the Tax Administration does not know. The AP therefore holds that the Tax Administration cannot yet show compliance with the GDPR.

Article 22 GDPR in principle prohibits decisions based solely on automated processing that produce legal effects or similarly significantly affect a person. A decision only falls outside it if a person is meaningfully involved: someone with the authority and the knowledge to assess the outcome on its merits and change it. A routine sign-off is not enough. So check for each tool whether the outcome is such a decision, and who actually takes it. For a Dutch municipality the route to a fully automated decision is narrow: Article 40 of the Dutch GDPR Implementation Act (UAVG) makes no exception for decisions based on profiling; such a decision is then only possible if a specific law allows it and provides suitable safeguards (Article 22(2)(b) GDPR). Read more in our article on automated candidate screening, where the same rules apply.

Lesson 3: logging only protects data if someone reviews the logs

In January 2026 the AP sent the Tax Administration a confidential letter on logging, review of logging and access management. By mid 2026 there were plans, but no concrete improvements yet. The AP points to criminal cases in which civil servants, including a municipal official, are suspected of leaking data to criminals. You only see who consults data without a work-related need if you review the logs regularly and systematically.

For the municipality: record in which systems you log look-ups, who reviews the logs and how often, and limit access to what staff need for their work. This follows from the duty of appropriate security (Article 32 GDPR).

Lesson 4: a temporary vault is not a retention period

In 2019 the Tax Administration moved millions of documents into a shielded digital vault. As an emergency measure the AP found that defensible, but for years afterwards nothing happened. The AP holds that the Tax Administration systematically breached the law by not destroying or archiving those data on time. Personal data may not be kept longer than necessary (Article 5(1)(e) GDPR), not even in a shielded environment.

So also look at your own "temporary" folders, old drives and export files. Every shielded environment needs an owner, a retention period under the applicable archival selection list, and a plan to destroy the data or transfer them to the archive.

Lesson 5: search everywhere when handling an access request

The AP found that the Tax Administration cannot show that access requests are handled on time: there are no reliable figures, each directorate works its own way and staff are unclear how wide their search must be. The AP stresses that the vault and other shielded environments must be part of the search.

A resident must receive a reply to an access request without undue delay and in any event within one month. If a request is complex or there are many requests, you may extend that period by at most two months, but you must tell the resident within the first month, with the reasons (Articles 12(3) and 15 GDPR). Register requests centrally, track the deadlines and record which systems and archives you always search.

Lesson 6: the record of processing includes partnerships

The Tax Administration's record covered 98 percent of the processes in its own domain architecture; how many processes fall outside it, the Tax Administration does not know. On top of that the AP itself found processing that was missing, including in partnerships such as the Regional Information and Expertise Centres (RIECs). The quality of the completed fields also fell short. Municipalities often take part in the same partnerships. Include that processing in your record (Article 30 GDPR) and have its quality reviewed periodically, not only for new entries.

Lesson 7: keep the BSN out of references and documents that reach third parties

The Tax Administration uses the BSN in payment references and claim numbers, which also reach banks and other third parties. According to the AP this is not necessary and therefore unlawful. For citizens the BSN disappears from the payment reference at the end of 2026. A statutory identification number may only be used to implement the law that prescribes it or for purposes laid down by law (Article 46 UAVG). Even where a municipality uses the BSN for its own tasks, that does not make it necessary in payment references, letters to third parties or exports. So check where it appears there.

Lesson 8: home-made applications and the privacy organisation

The AP still found many locally developed applications: tools built outside the regular IT process, which therefore do not always meet the GDPR and the Dutch government information security baseline (BIO). At a municipality these are often spreadsheets and small databases with residents' data. Map them, and decide for each one: bring it into line or stop.

The AP also holds that the Tax Administration's privacy organisation does not yet work properly: roles are unclear, steering is too weak and the workload is high. Even for data breaches and DPIAs, where compliance is in order, the AP wants the Tax Administration to record what was done with the advice of the data protection officer. Do the same: note for each DPO advice whether you follow it and why.

What the AI Act adds

The high-risk rules of the AI Act only apply to AI systems. Systems based on rules defined solely by natural persons to automatically execute operations are outside the definition, according to recital 12. Note, however: if the rules or thresholds are (partly) derived from data, for example with a statistical or learning model, the tool may well be an AI system. Where that line lies is explained in our article on the Commission guidelines on the definition. The GDPR lessons above apply to every selection tool.

If the tool is an AI system and the municipality, or a party acting on its behalf, uses it to assess whether someone is eligible for an essential public assistance benefit or service, or to grant, reduce, revoke or reclaim it, it falls under Annex III, point 5(a). Recital 58 expressly mentions social security benefits and social assistance. A risk profile that assesses applicants on personal characteristics is generally profiling; in that case the exception in Article 6(3) does not help and the system is high-risk. Under Regulation (EU) 2026/1744 those obligations apply to new systems from 2 December 2027.

For the municipality this means, among other things, human oversight by people with the necessary competence, training and authority (Article 26(2)), registration of the use in the EU database, and not using a system that is not registered there (paragraph 8), informing residents to whom the system is applied (paragraph 11) and a FRIA before first use (Article 27). If the DPIA already covers a part, the FRIA may refer to that part (paragraph 4). If the system is already in use before 2 December 2027, the high-risk obligations, including the FRIA, only apply once its design is significantly changed after that date. For systems intended for use by public authorities you must comply by 2 August 2030 in any event (Article 111(2)). The tool in the example, which has been running for years, therefore falls under that transitional rule. More in the FRIA for municipalities.

Bank and school, briefly

A bank works with transaction monitoring and internal alert registers. The same lessons apply: justify the criteria, review the logging, delete on time and search everywhere for access requests. Whether a recorded alert concerns a criminal offence is assessed with the three criteria from the case law of the Court of Justice, which the Dutch Supreme Court applied on 6 November 2026; see our article on bank registers and Article 10 GDPR. Under the AI Act credit scoring is high-risk (Annex III, point 5(b)), but systems used to detect financial fraud are excluded there, and transaction monitoring under anti-money laundering law does not fall under point 5(b).

A school will mostly recognise the lessons on home-made spreadsheets with pupil data, access rights and access requests from parents and pupils. AI systems for admission, evaluating learning outcomes or detecting prohibited behaviour during tests are listed in Annex III, point 3.

What to do now

1. List all selection tools and risk profiles, with the justification and the discrimination test for each rule.
2. Record for each tool who takes the decision and how that person can change the outcome.
3. Arrange for the logs of look-ups to be reviewed periodically, and limit access rights.
4. Give every shielded environment an owner, a retention period and a clean-up plan, and include it in the search for access requests.
5. Check the record of processing for partnerships and for use of the BSN.
6. Note in the DPIA whether a tool is an AI system and whether Annex III point 5 applies.

To check which obligations under the GDPR and the AI Act apply to your own selection tool, use the free case check. The overview of recent AP decisions and reports is under GDPR enforcement.

What remains open

• When human intervention is meaningful. According to the AP, the Tax Administration's assessment framework does not yet give a clear answer. A legal exploration by the Tax Administration itself may help.
• DPIAs. The AP announces a letter with further findings on the Tax Administration's DPIAs for the end of 2026.
• Logging. The findings on logging are confidential; the report gives no details.