In december 2024 werd een ernstig datalek bekend bij JCC Software, een externe softwareleverancier die het digitale afsprakensysteem levert aan meerdere Nederlandse gemeenten. Via dit systeem, dat onder andere wordt gebruikt door Gemeente Amersfoort, kregen hackers toegang tot gevoelige persoonsgegevens.
De impact bleef echter niet beperkt tot Amersfoort. Omdat dezelfde leverancier ook werkte voor Gemeente Dinkelland en Gemeente Tubbergen, werden ook gegevens van inwoners van deze gemeenten buitgemaakt. Het ging om namen, adressen, contactgegevens en BSN-nummers. Dit incident maakt pijnlijk duidelijk dat digitale dienstverlening in de publieke sector niet stopt bij de organisatiegrens, maar onderdeel is van een gedeelde digitale supply chain waarin risico’s zich kunnen vermenigvuldigen.
Wat hier misging: één leverancier, meerdere gemeenten
De kern van dit incident ligt in de schaal waarop softwareleveranciers opereren. Gemeenten kiezen vaak bewust voor dezelfde leveranciers om kosten te besparen en processen te standaardiseren. Dat is efficiënt, maar creëert ook concentratierisico. In dit geval beheerde één leverancier een afsprakensysteem voor meerdere gemeenten, waarbij data van verschillende organisaties binnen dezelfde technische omgeving werd verwerkt. Toen die omgeving werd gecompromitteerd, waren de gevolgen direct meervoudig. Voor bestuurders is dit een belangrijk inzicht: uitbesteding vermindert de operationele last, maar vergroot de impact wanneer het misgaat. Een incident bij een leverancier is zelden een geïsoleerd probleem; het raakt alle organisaties die van die leverancier afhankelijk zijn.
De rol van de testserver: een kleine fout met grote gevolgen
Een opvallend en leerzaam aspect van dit datalek is de manier waarop de aanvallers binnenkwamen. Zij kregen toegang via een testserver die nog gekoppeld was aan het productiesysteem. Testomgevingen worden gebruikt om nieuwe functionaliteit te ontwikkelen en te controleren, maar horen strikt gescheiden te zijn van systemen waarin echte persoonsgegevens worden verwerkt.
In de praktijk blijken testomgevingen echter vaak minder streng beveiligd en onvoldoende opgeschoond. In dit geval bood die koppeling een ingang tot productiegegevens. Voor niet-technische lezers is dit essentieel om te begrijpen: het was geen geavanceerde aanval op de kernsystemen van gemeenten, maar het benutten van een organisatorische en technische nalatigheid.
Oude data: verborgen risico in de keten
Extra zorgwekkend is dat via deze testserver ook gegevens werden blootgesteld die al lang verwijderd hadden moeten zijn. Dit wijst op tekortschietend datamanagement en onvoldoende toezicht op dataretentie. Vanuit bestuurlijk perspectief is dit een belangrijk signaal. Data die niet meer nodig is voor dienstverlening, levert geen waarde op, maar wel risico. Zeker bij gevoelige persoonsgegevens zoals BSN-nummers kan dit leiden tot langdurige schade voor burgers, bijvoorbeeld in de vorm van identiteitsfraude. Het incident laat zien dat privacywetgeving zoals de AVG niet alleen vraagt om beleidsdocumenten, maar om discipline in de hele digitale keten, inclusief bij leveranciers.
De impact op burgers en vertrouwen
Voor inwoners van de betrokken gemeenten is dit incident ingrijpend. Zij hebben hun gegevens verstrekt aan hun gemeente in het vertrouwen dat deze veilig worden behandeld. Dat dit vertrouwen wordt geschaad door een externe leverancier, maakt het voor burgers niet minder ernstig. Bestuurlijk gezien is dit een lastig dilemma: de oorzaak ligt buiten de eigen organisatie, maar de verantwoordelijkheid richting inwoners blijft. Daarnaast moeten gemeenten tijd en middelen inzetten voor communicatie, ondersteuning en toezicht, terwijl de directe controle beperkt is. Dit onderstreept dat reputatieschade en vertrouwensverlies vaak de grootste gevolgen zijn van supply-chain-incidenten.
Waarom dit een schoolvoorbeeld van supply chain risk is
Dit datalek voldoet aan alle kenmerken van een klassiek supply-chain-incident. De kwetsbaarheid zat niet bij de primaire organisatie, maar bij een gedeelde leverancier. De impact was niet lokaal, maar verspreid over meerdere gemeenten. En de oorzaak lag niet in één fout, maar in een combinatie van factoren: gedeelde infrastructuur, onvoldoende scheiding van omgevingen en het bewaren van oude data. Voor directies en CISO’s is dit een duidelijk signaal dat supply chain risk management ook in de publieke sector volwassen moet worden ingericht. Het gaat niet alleen om contracten en SLA’s, maar om inzicht in technische afhankelijkheden en governance in de keten.
Bestuurlijke lessen: van aannames naar aantoonbare controle
Een belangrijke les uit dit incident is dat vertrouwen in leveranciers moet worden aangevuld met aantoonbare controle. Bestuurders hoeven niet te weten hoe een testserver technisch werkt, maar moeten wel kunnen vragen: zijn test- en productiesystemen strikt gescheiden? Hoe wordt gecontroleerd dat oude data daadwerkelijk wordt verwijderd? En wat gebeurt er als een leverancier meerdere organisaties bedient? Voor CISO’s ligt hier de taak om deze vragen te vertalen naar heldere eisen, periodieke controles en duidelijke escalatieafspraken. Zonder die bestuurlijke betrokkenheid blijven dit soort risico’s onder de radar, totdat het misgaat.
Brede relevantie voor publieke en semipublieke organisaties
Hoewel dit incident gemeenten betreft, zijn de lessen breder toepasbaar. Ook zorginstellingen, onderwijsorganisaties en woningcorporaties werken met externe softwareleveranciers die gevoelige persoonsgegevens verwerken voor meerdere klanten tegelijk. De afhankelijkheid van gedeelde digitale platforms neemt toe, en daarmee ook het belang van ketenverantwoordelijkheid. Positief is dat incidenten zoals dit het gesprek op gang brengen over digitale weerbaarheid en governance. Het datalek bij JCC Software laat zien dat supply chain risk geen abstract IT-thema is, maar een concreet bestuurlijk vraagstuk dat direct raakt aan vertrouwen, continuïteit en publieke verantwoordelijkheid.
