In December 2024, a serious data breach was disclosed at JCC Software, an external software supplier that provides the digital appointment system to multiple Dutch municipalities. Through this system, which is used by Municipality of Amersfoort among others, hackers gained access to sensitive personal data.
However, the impact was not limited to Amersfoort. Because the same supplier also worked for Municipality of Dinkelland and Municipality of Tubbergen, data from residents of these municipalities was also compromised. This involved names, addresses, contact details, and BSN numbers. This incident painfully demonstrates that digital service delivery in the public sector does not stop at organizational boundaries, but is part of a shared digital supply chain where risks can multiply.
What went wrong here: one supplier, multiple municipalities
The core of this incident lies in the scale at which software suppliers operate. Municipalities often deliberately choose the same suppliers to save costs and standardize processes. This is efficient, but also creates concentration risk. In this case, one supplier managed an appointment system for multiple municipalities, where data from different organizations was processed within the same technical environment. When that environment was compromised, the consequences were immediately multiple. For administrators, this is an important insight: outsourcing reduces operational burden, but increases impact when things go wrong. An incident at a supplier is rarely an isolated problem; it affects all organizations that depend on that supplier.
The role of the test server: a small error with major consequences
A striking and instructive aspect of this data breach is the way the attackers gained entry. They gained access through a test server that was still connected to the production system. Test environments are used to develop and verify new functionality, but should be strictly separated from systems where real personal data is processed.
In practice, however, test environments often prove to be less strictly secured and insufficiently cleaned up. In this case, that connection provided an entry point to production data. For non-technical readers, this is essential to understand: it was not an advanced attack on the core systems of municipalities, but the exploitation of organizational and technical negligence.
Old data: hidden risk in the chain
Additionally concerning is that through this test server, data was also exposed that should have been deleted long ago. This points to inadequate data management and insufficient oversight of data retention. From an administrative perspective, this is an important signal. Data that is no longer needed for service delivery provides no value, but does create risk. Especially with sensitive personal data such as BSN numbers, this can lead to long-term damage for citizens, for example in the form of identity fraud. The incident shows that privacy legislation such as the GDPR does not only require policy documents, but discipline throughout the entire digital chain, including at suppliers.
The impact on citizens and trust
For residents of the affected municipalities, this incident is significant. They provided their data to their municipality in the trust that it would be handled safely. That this trust is damaged by an external supplier does not make it any less serious for citizens. From an administrative perspective, this is a difficult dilemma: the cause lies outside one’s own organization, but the responsibility toward residents remains. Additionally, municipalities must invest time and resources in communication, support, and oversight, while direct control is limited. This underscores that reputational damage and loss of trust are often the greatest consequences of supply chain incidents.
Why this is a textbook example of supply chain risk
This data breach meets all characteristics of a classic supply chain incident. The vulnerability was not at the primary organization, but at a shared supplier. The impact was not local, but spread across multiple municipalities. And the cause was not one error, but a combination of factors: shared infrastructure, insufficient separation of environments, and retention of old data. For executives and CISOs, this is a clear signal that supply chain risk management must also be maturely implemented in the public sector. It is not only about contracts and SLAs, but about insight into technical dependencies and governance in the chain.
Administrative lessons: from assumptions to demonstrable control
An important lesson from this incident is that trust in suppliers must be supplemented with demonstrable control. Administrators do not need to know how a test server works technically, but must be able to ask: are test and production systems strictly separated? How is it verified that old data is actually deleted? And what happens when a supplier serves multiple organizations? For CISOs, the task here is to translate these questions into clear requirements, periodic checks, and clear escalation agreements. Without that administrative involvement, these types of risks remain under the radar until something goes wrong.
Broad relevance for public and semi-public organizations
Although this incident concerns municipalities, the lessons are more broadly applicable. Healthcare institutions, educational organizations, and housing corporations also work with external software suppliers that process sensitive personal data for multiple clients simultaneously. The dependence on shared digital platforms is increasing, and with it the importance of chain responsibility. Positive is that incidents like this start the conversation about digital resilience and governance. The data breach at JCC Software shows that supply chain risk is not an abstract IT theme, but a concrete administrative issue that directly touches on trust, continuity, and public responsibility.
