Op 12 oktober 2026 waren de website, app en klantenservice van Albert Heijn niet beschikbaar. Online bestelde boodschappen konden niet worden bezorgd. Ook de elektronische schapkaartjes toonden nog actieprijzen van de week ervoor. Het bedrijf sprak van een cybersecurity-incident en meldde dat het uit voorzorg systemen had uitgeschakeld. Wat er precies was gebeurd, was op dat moment niet bekend. (NOS, 12 oktober 2026)
Dit incident heeft mij aan het denken gezet. Eerst over de techniek achter de winkels. Daarna over een risico dat ik nog een stuk ongemakkelijker vind dan een ransomware-aanval.
Vraag: Kun je uit de storing afleiden wat er is gebeurd?
Nee. De verschijnselen vertellen ons welke diensten niet beschikbaar waren, maar niet wat de oorzaak was. Ransomware is een mogelijkheid, maar op basis van openbare berichtgeving kan ik niet vaststellen of dat hier speelde.
Ook de gelijktijdige problemen bij verschillende merken bewijzen niet dat er één centraal systeem is binnengedrongen. Daarvoor zouden we de infrastructuur en de interne bevindingen moeten kennen. Dat geldt ook voor de uitleg over kassa’s en schapkaartjes: zonder informatie over de inrichting van AH kunnen we niet weten welke lokale systemen, koppelingen of noodvoorzieningen daar precies achter zitten.
Bij een storing als deze merk ik hoe snel ik zelf een technisch scenario begin te vormen. De uitval van verschillende diensten en het preventief uitschakelen van systemen roepen allerlei mogelijke verklaringen op. Maar zulke signalen bewijzen op zichzelf niet wat er precies is gebeurd. Ik wil daarom scherp blijven onderscheiden wat ik weet, wat ik vermoed en wat ik alleen als mogelijkheid zie. Een verklaring kan logisch klinken zonder dat er bewijs voor is.
Vraag: Hadden de winkels zelfstandig kunnen blijven werken?
Ik heb daar zelf ervaring mee. Zo’n achttien jaar geleden ontwierp en rolde ik een omgeving uit met 120 centrale databases en 120 lokale kopieën, verspreid over het land. Alle mutaties vonden centraal plaats. De lokale kopieën werden dagelijks via eenrichtingsreplicatie bijgewerkt en alleen-lezen gebruikt voor rapportages en analyses. Het doel, dat hiermee bereikt werd, was het beperken van de belasting van het WAN.
Hetzelfde uitgangspunt kan ook bijdragen aan de continuïteit van winkelprocessen. Als AH verkoop- en voorraadmutaties lokaal vastlegt en deze asynchroon naar de centrale database repliceert, hoeft de centrale verbinding niet voor iedere mutatie beschikbaar te zijn. En als de winkel lokaal over de benodigde informatie beschikt, kunnen bepaalde functies mogelijk doorgaan wanneer centrale systemen tijdelijk onbereikbaar zijn.
We weten niet of de systemen van AH zo zijn ingericht, welke gegevens de schapkaartjes nodig hebben en of een lokale database die functie daadwerkelijk zou kunnen ondersteunen. Een lokale kopie lost bovendien niet automatisch alles op. De gegevens moeten actueel genoeg zijn, de lokale systemen moeten veilig beheerd kunnen worden en er moet een plan zijn voor wat er gebeurt wanneer de verbinding terugkomt.
Mijn oude ontwerp was gemaakt voor een andere situatie en met een ander doel: minder WAN-belasting. Toch blijft de architectuurvraag relevant. Welke functies moeten op een vestiging zelfstandig kunnen doorgaan, welke gegevens zijn daarvoor nodig en hoe lang kan dat verantwoord?
Daar hoort ook de terugweg bij. Kassabonnen en voorraadmutaties kunnen lokaal worden vastgelegd en later worden doorgegeven, maar als dat te lang niet lukt, kan de centrale voorraadadministratie steeds verder afwijken van de werkelijkheid. Dan wordt bevoorrading lastiger. Hoe lang een winkel zonder centrale gegevensuitwisseling kan werken, hangt af van de processen, voorraden, buffers en handmatige noodprocedures. Een algemeen aantal dagen kun je daar niet op plakken.
Vraag: Is ransomware niet relatief eenvoudig op te lossen met goede contingency planning?
Een goed herstelplan en bruikbare back-ups zijn belangrijk, maar ze betekenen niet automatisch dat een groot bedrijf binnen enkele uren weer veilig operationeel is. Eerst moet duidelijk zijn welke systemen zijn geraakt en of de omgeving schoon genoeg is om op te starten. Daarna moeten koppelingen, gegevens en transacties worden gecontroleerd en soms opnieuw verwerkt.
Een back-up kan bestanden terugzetten. Hij vertelt niet vanzelf of de aanvaller nog toegang heeft, of de teruggezette gegevens betrouwbaar zijn en of alle achterliggende processen weer goed samenwerken.
Dat maakt ransomware voor mij niet onbelangrijk. Het maakt alleen duidelijk dat herstel meer vraagt dan een back-up terugzetten. Toch houdt ransomware vaak een zichtbaar spoor achter: systemen zijn versleuteld, diensten vallen uit of er verschijnen meldingen.
Wat ik veel verraderlijker vind, is een aanval waarbij de verwerking ongemerkt wordt beïnvloed.
Vraag: Wat als niet de data zelf verandert, maar de gegevens die het systeem aansturen?
Dan kan het systeem blijven werken en toch steeds verkeerde uitkomsten produceren. Denk aan configuratie, referentiegegevens, parameters of andere waarden die bepalen hoe een proces zich gedraagt. Als die worden aangepast, kan een algoritme nog steeds keurig uitvoeren wat het is opgedragen — alleen is de opdracht veranderd.
Dat is geen vaststelling over Albert Heijn. Het is een algemeen risico bij organisaties die veel processen datagedreven aansturen.
Precies daar zit voor mij een blinde vlek. Operationele gegevens krijgen vaak veel aandacht: wie heeft een transactie uitgevoerd, wat is er verkocht, welke klantgegevens zijn gewijzigd? Maar stuurgegevens kunnen minstens zo bepalend zijn voor de uitkomst. Toch worden ze soms behandeld als technische configuratie en vallen ze buiten vergelijkbare afspraken over eigenaarschap, wijzigingen en controle.
Als je niet kunt terugvinden wie een stuurwaarde heeft aangepast, wanneer dat gebeurde en waarom, wordt onderzoek bijzonder lastig. Het systeem hoeft geen foutmelding te geven. De verwerking kan technisch correct verlopen terwijl de uitkomst niet meer klopt.
Vraag: Wat zou je dan willen kunnen controleren?
Je wilt wijzigingen aan stuurgegevens kunnen herleiden en beoordelen. Dat vraagt onder meer om vastgelegde versies, een betrouwbare wijzigingshistorie, duidelijke autorisaties en controle op opvallende veranderingen. Ook moet je kunnen reconstrueren welke versie van de stuurgegevens bij een bepaalde verwerking is gebruikt.
Daarnaast zijn controles op uitkomsten belangrijk. Niet alleen: “heeft het systeem zonder foutmelding gedraaid?”, maar ook: “zijn de resultaten nog verklaarbaar en passen ze bij wat we verwachten?”
Voor mij hoort dat bij datagovernance. Gegevens die de verwerking sturen, verdienen aandacht die past bij hun invloed op het bedrijfsproces. Dat geldt ook als ze in een configuratietabel staan en niet in een tabel die iemand direct als “bedrijfsdata” herkent.
Een storing bij een supermarkt laat zien hoe afhankelijk dagelijkse processen van informatievoorziening zijn. Maar de vraag die mij het meest bezighoudt, is niet alleen hoe snel systemen weer beschikbaar zijn. Ik wil ook weten hoe je kunt aantonen dat ze daarna weer op de juiste gegevens en regels werken.