Softwarewijzigingen veilig testen: hoe voorkom je dat een release een datalek veroorzaakt?

Wat gebeurde er bij het CJIB?

Door een fout in een nieuwe software-release werden bij het Centraal Justitieel Incassobureau gedurende ongeveer een etmaal circa 6.000 vorderingen van verkeersboetes, strafzaken en overheidsincasso's aan verkeerde personen gekoppeld. Enkele tientallen mensen konden via MijnCJIB informatie inzien die niet voor hen bestemd was. Ook zijn brieven met onjuiste informatie verstuurd.

De fout werd op 26 augustus 2026 vastgesteld. MijnCJIB is vervolgens offline gehaald en bleef dat tot 30 augustus. Daarmee is de blootstelling beperkt, maar het incident laat zien hoe één fout in de verwerking van gegevens in korte tijd veel dossiers kan raken.

Een belangrijke nuance is dat uit de openbare informatie niet blijkt hoe het CJIB vooraf heeft getest, welke testgevallen zijn uitgevoerd of welke testdata is gebruikt. Daarover kunnen we dus geen conclusie trekken. De casus is wél een bruikbaar voorbeeld om te kijken welke beheersmaatregelen organisaties rond softwarewijzigingen nodig hebben.

Een release is pas beheerst wanneer je vooraf de risico's kent, realistische uitzonderingen hebt getest, verantwoordelijkheden zijn gescheiden, terugkeer mogelijk is en na ingebruikname actief wordt gecontroleerd op afwijkingen.

Waarom change management bij informatiebeveiliging hoort

Change management, ook wijzigingsbeheer genoemd, is het gecontroleerd aanvragen, beoordelen, testen, goedkeuren, invoeren en evalueren van wijzigingen. Het doel is dat een noodzakelijke verbetering geen onverwachte verstoring, beveiligingszwakte of foutieve gegevensverwerking veroorzaakt.

Bij informatiebeveiliging gaat het om vertrouwelijkheid, integriteit en beschikbaarheid. Een verkeerde koppeling raakt de vertrouwelijkheid omdat iemand gegevens van een ander kan zien. Een onjuiste brief of mutatie raakt de integriteit van informatie. Het tijdelijk sluiten van een portaal raakt de beschikbaarheid. Eén release kan dus alle drie de aspecten tegelijk beïnvloeden.

Een werkbaar change-proces hoeft geen bureaucratische vergadermachine te zijn. De zwaarte moet aansluiten bij het risico. Een kleine tekstwijziging vraagt een andere beoordeling dan een aanpassing in de koppeling tussen personen, dossiers, betalingen of medische gegevens.

• Leg vast wat verandert, waarom dat nodig is en welke systemen en processen worden geraakt.
• Beoordeel vooraf de mogelijke gevolgen voor gegevens, gebruikers en continuïteit.
• Bepaal wie ontwikkelt, test, functioneel accepteert en toestemming geeft voor ingebruikname.
• Plan het moment van invoering, de controle erna en de terugvaloptie wanneer het misgaat.
• Bewaar bewijs van de uitgevoerde tests, acceptatie, release en nacontrole.

Test buiten productie, maar behandel de testomgeving serieus

Wijzigingen rechtstreeks in productie testen vergroot de kans dat klanten, cliënten, medewerkers of ketenpartners de gevolgen ervaren. Gebruik daarom gescheiden ontwikkel-, test- en productieomgevingen waar de aard en omvang van het systeem dat rechtvaardigen.

Een testomgeving is alleen geen vrijplaats. Juist daar hebben ontwikkelaars, leveranciers en testers vaak ruimere toegang. Beveilig daarom ook de testomgeving met passende toegangsrechten, logging, patching, back-ups, bewaartermijnen en afspraken over het verwijderen van data.

Voorkom bovendien dat testfuncties echte e-mails, brieven, betalingen, meldingen of ketenberichten versturen. Externe koppelingen kun je waar mogelijk vervangen door een gecontroleerde testvoorziening, zodat een testrecord nooit per ongeluk een echte ontvanger bereikt.

Gebruik synthetische of echt geanonimiseerde testdata waar dat kan

Een kopie van productiegegevens maakt een testomgeving snel realistisch. Tegelijkertijd verplaats je daarmee echte persoonsgegevens naar een omgeving met een ander doel, andere gebruikers en vaak minder strikte toegangsbeperkingen. Zodra bij een test, pilot of proefproject persoonsgegevens worden verwerkt, blijft de AVG van toepassing.

Synthetische testdata wordt speciaal voor het testen gemaakt en beschrijft geen echte personen. Goed geanonimiseerde data is niet meer naar een persoon te herleiden. Pseudonimisering is iets anders: wanneer gegevens met aanvullende informatie opnieuw aan iemand kunnen worden gekoppeld, blijven het persoonsgegevens.

Kies testdata niet alleen op privacy. De set moet ook functioneel bruikbaar zijn. Bouw realistische variatie in en neem grensgevallen op, zoals dubbele namen, meerdere dossiers per persoon, verhuizingen, ontbrekende velden, afwijkende tekens, uitzonderlijke bedragen en gelijktijdige wijzigingen. Juist in die combinaties ontstaan vaak fouten die een standaardtest niet laat zien.

Technisch testen is iets anders dan functioneel accepteren

Een technische test kan aantonen dat code draait, een interface reageert en een koppeling geen foutmelding geeft. Daarmee staat nog niet vast dat het bedrijfsproces de juiste uitkomst oplevert. Een systeem kan technisch precies doen wat is gebouwd en toch een dossier aan de verkeerde persoon koppelen.

Laat daarom ook proceseigenaren of deskundige gebruikers functionele acceptatietesten uitvoeren. Zij kennen de betekenis van gegevens, uitzonderingen in het proces en de gevolgen van een fout. Leg vooraf acceptatiecriteria vast, zodat goedkeuring niet afhankelijk is van een algemeen gevoel dat de release lijkt te werken.

Zorg waar mogelijk voor functiescheiding. De ontwikkelaar kan eigen werk controleren, maar hoort bij risicovolle wijzigingen niet als enige te bepalen dat de release naar productie mag. Een tweede paar ogen verkleint de kans dat dezelfde aanname zowel in de bouw als in de test blijft zitten.

• unit- en integratietests voor de technische werking
• regressietests om te controleren of bestaande functies blijven werken
• functionele tests op volledige processen en gegevensstromen
• negatieve tests en uitzonderingssituaties
• autorisatietests: ziet iedere rol alleen wat zij mag zien?
• acceptatie door een bevoegde proceseigenaar of gebruiker

Maak privacy en beveiliging onderdeel van de testgevallen

Privacy- en beveiligingscontroles worden soms pas na de functionele test bekeken. Dan is de belangrijkste vraag al te smal geformuleerd: werkt de nieuwe functie? Voeg daarom vooraf testgevallen toe die onderzoeken voor wie gegevens zichtbaar zijn, aan wie berichten worden verzonden, welke gegevens in logging terechtkomen en wat er bij een onvolledig of fout record gebeurt.

Bij wijzigingen in identificatie, dossierkoppelingen, autorisaties, exports, berichtenverkeer en interfaces is dit extra belangrijk. Controleer de verwerking van begin tot eind. Een juiste invoer kan onderweg alsnog aan een verkeerd account, document, bericht of extern systeem worden gekoppeld.

Bereid vooraf een rollback of andere veilige terugval voor

Een terugvalplan beschrijft hoe je de wijziging uitschakelt of terugdraait wanneer de uitkomst afwijkt. Denk aan het terugplaatsen van een eerdere softwareversie, het uitschakelen van een feature flag, het herstellen van een databasewijziging of het tijdelijk stoppen van een koppeling.

Bepaal vóór de release wie over terugdraaien beslist, welke signalen daarvoor aanleiding geven en hoeveel tijd beschikbaar is. Test ook de terugvalroute. Een rollback die alleen op papier bestaat kan tijdens een incident alsnog mislukken, bijvoorbeeld omdat gegevensstructuren inmiddels zijn veranderd.

Soms kan een release technisch worden teruggedraaid, terwijl foutief verwerkte of verstuurde gegevens al moeten worden hersteld. Neem daarom ook gegevenscorrectie, communicatie, privacybeoordeling en eventuele melding van een datalek op in het scenario.

Controleer direct na ingebruikname op afwijkingen

Een geslaagde acceptatietest geeft vertrouwen, maar productie heeft meer gebruikers, meer koppelingen en meer variatie. Plan daarom na een risicovolle release een periode van verhoogde controle. Je wilt een fout liever na vijf transacties vinden dan na 6.000.

Leg vooraf vast welke signalen je volgt en wat normaal gedrag is. Kijk niet alleen naar technische beschikbaarheid en foutcodes, maar ook naar zakelijke uitkomsten: aantallen koppelingen, onverwachte mutaties, teruggestuurde berichten, afwijkende verzendingen, klachten en verschillen tussen bron- en doelsystemen.

• automatische waarschuwingen bij technische fouten en afwijkende volumes
• steekproeven op de juistheid van dossiers, accounts, brieven en transacties
• reconciliatie tussen brongegevens en verwerkte resultaten
• duidelijke bereikbaarheid van het release- en incidentteam
• een afgesproken beslismoment om door te gaan, te pauzeren of terug te draaien
• een evaluatie waarin fouten en verbeterpunten worden vastgelegd

Uitbesteden verandert de regieverantwoordelijkheid niet

Veel softwarewijzigingen worden door een externe ontwikkelaar, SaaS-leverancier of IT-dienstverlener uitgevoerd. Vraag dan hoe releases worden getest, wie functioneel accepteert, welke omgevingen worden gebruikt en hoe testdata wordt beschermd. Een algemene mededeling dat de leverancier volgens best practices werkt geeft weinig inzicht in de feitelijke beheersing.

Leg in afspraken vast hoe risicovolle wijzigingen worden aangekondigd, welk bewijs beschikbaar is, hoe incidenten worden gemeld en wie een rollback kan starten. Houd als organisatie voldoende kennis en toegang om de werking te beoordelen. De leverancier bouwt of beheert het systeem; de organisatie blijft verantwoordelijk voor het proces en de gegevens die zij eraan toevertrouwt.

Checklist voor een veilige software-release

Gebruik voor iedere wijziging een risicogerichte checklist. Bij een eenvoudige standaardwijziging volstaat een compacte registratie. Voor een kritieke gegevensverwerking wil je iedere onderstaande vraag concreet kunnen beantwoorden.

• Is duidelijk wat verandert en welke gegevens, systemen en processen geraakt worden?
• Is de wijziging buiten productie technisch én functioneel getest?
• Zijn grensgevallen, foutscenario's en bestaande functies meegenomen?
• Is synthetische of echt geanonimiseerde testdata gebruikt waar dat kan?
• Zijn privacy, autorisaties, koppelingen en uitgaande berichten expliciet getest?
• Heeft iemand anders dan de ontwikkelaar de wijziging beoordeeld en geaccepteerd?
• Zijn invoering, communicatie, verantwoordelijkheden en beslismomenten vastgelegd?
• Is een werkbare rollback of andere veilige terugval voorbereid en getest?
• Is direct na ingebruikname extra monitoring en functionele controle ingericht?
• Worden uitkomsten, afwijkingen, herstelacties en geleerde lessen aantoonbaar vastgelegd?

Veilige softwarewijzigingen vragen om aantoonbare beheersing

Informatiebeveiliging gaat niet alleen over aanvallers buiten de organisatie. Een onbedoelde fout in een release kan dezelfde vertrouwelijkheid, integriteit en beschikbaarheid raken die je tegen cyberaanvallen probeert te beschermen.

De oplossing is niet dat iedere wijziging maanden moet duren. De oplossing is een voorspelbaar proces waarin de diepgang van beoordeling en testen past bij het risico. Met passende testdata, onafhankelijke acceptatie, een werkbare terugval en gerichte monitoring kan een organisatie sneller zien wanneer de praktijk afwijkt van de verwachting.