English version: scroll down

In mijn blog ‘Zwarte doos om AI-agents te bewaken?’ beschreef ik waarom autonome AI-agents een flight recorder noodzakelijk maken. Als een agent zelfstandig beslissingen neemt, moeten we achteraf kunnen reconstrueren wat hij heeft gedaan, welke instructies hij kreeg, welke data hij gebruikte en welke actie daarop volgde. Dat is geen luxe. Het is een voorwaarde voor vertrouwen.

In de luchtvaart accepteren we het niet dat een vliegtuig honderden mensen vervoert zonder dat achteraf kan worden onderzocht wat er tijdens een vlucht gebeurde. De flight recorder is niet een bewijs dat een vliegtuig veilig is. Het is een instrument om gebeurtenissen vast te leggen, veiligheid aantoonbaar te maken en ervan te leren. Precies die beweging moeten we nu ook in de digitale wereld maken. 

Ook daar ontstaan steeds meer systemen die autonoom kunnen handelen. AI-agents nemen beslissingen, microservices reageren op elkaar, cloudplatforms schalen automatisch en data beweegt door ketens die we zelf niet meer kunnen overzien. Ergens in die keten kan iets gebeuren wat niemand heeft voorzien. Dan is de eerste vraag wat er is gebeurd. De black box kan ons daarbij helpen. Maar daarna volgen belangrijkere vragen: waarom gebeurde het, hadden we het kunnen zien aankomen en wie had moeten handelen?

Een black box registreert wel, maar begrijpt niets

Dat was precies het punt van mijn latere blog ‘De black box weet alles. Behalve wat er mis is’. We meten inmiddels bijna alles, maar meten is nog geen begrijpen. Een complex digitaal systeem lijkt steeds meer op een levend organisme. Miljoenen processen werken tegelijkertijd samen en kleine afwijkingen kunnen elkaar versterken. Een probleem kan ergens diep in een keten beginnen en pas veel later zichtbaar worden.

Klassieke monitoring ziet dan vooral symptomen. Een latency loopt op, een database reageert trager, een API geeft meer fouten of een AI-agent wijkt af van zijn normale gedrag. Maar welk signaal is de oorzaak en welk signaal slechts een gevolg? Daarom moeten we verder dan logging. Van registreren naar begrijpen, van meten naar diagnostiek en uiteindelijk naar het vinden van de oorzaak. De flight recorder vertelt wat er is gebeurd; de digitale dokter probeert te begrijpen waarom het systeem uit balans is geraakt. Wat is de ‘root-cause’?

En dan komt het bestuur in beeld

Precies hier wordt de nieuwe publieke managementletter van NOREA interessant. NOREA maakt digitale weerbaarheid nadrukkelijk tot een bestuurlijke opdracht. Niet alleen de CIO of CISO, maar het bestuur als geheel moet sturen op digitale weerbaarheid. Daarbij gaat het om inzicht in digitale ketens, samenhangende governance, structureel beveiligen en bijsturen, bewuste risicoacceptatie en adequate verantwoording.

Daarmee ontstaat een volgende laag. De black box registreert. De digitale diagnostiek probeert te begrijpen. Maar wie bepaalt vervolgens wat er moet gebeuren? Dat is het bestuur. Dat betekent niet dat bestuurders zelf firewalls moeten configureren of incidenten moeten analyseren. Het betekent wel dat zij verantwoordelijk zijn voor het organiseren van het systeem waarmee de organisatie digitaal gezond en weerbaar blijft. En juist daar komen Governance, Risk Management en Compliance samen.

Governance bepaalt waarom en hoe

Governance gaat over de basisvragen. Wat vinden we als organisatie belangrijk? Welke digitale diensten zijn kritiek? Welke data moeten we beschermen? Welke afhankelijkheden accepteren we? Welke risico’s vinden we aanvaardbaar en welke niet?

Maar governance gaat ook over de inrichting. Wie is eigenaar? Wie mag beslissen? Wie moet worden geïnformeerd? Welke escalatieladder geldt wanneer iets misgaat? En wanneer moet een bestuurder zelf aan tafel komen? Een volwassen governance-model maakt daarmee niet alleen duidelijk wat veilig moet zijn, maar ook waarom, hoe en met welke middelen we dat organiseren.

Risk management maakt het operationeel

Daarna komt risicomanagement. Weten we welke risico’s we lopen? Weten we welke systemen en leveranciers daarbij betrokken zijn? Kunnen we een afwijking tijdig constateren? Weten medewerkers hoe ze die moeten melden? Is duidelijk wie vervolgens handelt en wanneer er moet worden opgeschaald?

Een goed risicomanagementproces beschrijft niet alleen wat we vooraf verwachten. Het organiseert ook wat er tijdens een incident moet gebeuren. Daarmee wordt de black box onderdeel van een groter systeem. Logging, monitoring en AI-observability leveren de informatie. Risicomanagement bepaalt wat met die informatie moet gebeuren. En dat moet niet alleen op papier werken. Het moet werken wanneer het echt misgaat.

Compliance moet het bewijs leveren

Daar komt compliance om de hoek kijken. Kunnen we met een audittrail aantonen dat onze beheersmaatregelen daadwerkelijk werken of hebben gewerkt? Kunnen we aantonen dat we compliant waren vóór een cyberaanval? Maar misschien nog belangrijker: kunnen we aantonen dat we tijdens die aanval volgens ons eigen plan en de vastgestelde scenario’s hebben gehandeld?

Wie heeft het incident gemeld? Wie heeft het beoordeeld? Wie heeft de escalatie gestart? Welke medewerkers zijn betrokken? Welke beslissingen zijn genomen? Wanneer is het bestuur geïnformeerd? Welke communicatie heeft plaatsgevonden? En hebben we gehandeld zoals vooraf was afgesproken?

Dat is een heel andere vorm van compliance dan het jaarlijks afvinken van een checklist. De echte test van compliance begint op het moment dat het misgaat. Een organisatie moet dan niet alleen kunnen zeggen dat zij compliant was, maar kunnen aantonen dat zij ook compliant handelde. De audittrail wordt daarmee de digitale getuige van de organisatie. Niet alleen van wat systemen hebben gedaan, maar ook van wat mensen en bestuurders hebben besloten.

Van evidence naar accountability

Daarmee komen de eerdere ideeën samen. Security by evidence betekent dat we kunnen aantonen wat er gebeurt en welke beheersmaatregelen bestaan. Maar security by accountability gaat een stap verder. Het vraagt wie verantwoordelijk is voor het organiseren van die beheersing, voor het bewaken ervan en voor het nemen van beslissingen wanneer de werkelijkheid afwijkt van het plan.

OODA helpt om tijdens een incident te observeren, te begrijpen, te beslissen en te handelen. PDCA zorgt ervoor dat we daarna leren en verbeteren. GRC zorgt ervoor dat dit alles onderdeel wordt van de normale besturing van de organisatie. Dat maakt digitale weerbaarheid geen project, maar een bestuurlijk systeem. En precies daar ligt de betekenis van de NOREA-managementletter.

Digitaal bestuur kun je niet uitbesteden

De digitale werkelijkheid heeft nauwelijks nog organisatorische grenzen. Cloudleveranciers, softwareleveranciers, AI-diensten en onderleveranciers vormen samen een keten waarvan organisaties afhankelijk zijn. Die technische afhankelijkheid kan worden uitbesteed. De bestuurlijke verantwoordelijkheid daarvoor niet.

Een leverancier kan verantwoordelijk zijn voor zijn platform. De CISO kan verantwoordelijk zijn voor het securitybeleid. IT kan verantwoordelijk zijn voor de technische uitvoering. De auditor kan vaststellen of beheersmaatregelen werken. Maar het bestuur blijft verantwoordelijk voor de vraag of de organisatie haar digitale risico’s kent, hoe zij die beheerst, welke risico’s zij accepteert en of zij aantoonbaar kan handelen wanneer het misgaat. Dat is de stap van security by evidence naar security by accountability.

En die accountability wordt steeds minder vrijblijvend. Nieuwe Europese wet- en regelgeving maakt de verantwoordelijkheid van bestuurders voor digitale weerbaarheid explicieter. Bij onvoldoende bestuur en toezicht kunnen niet alleen organisaties worden aangesproken; bestuurders kunnen ook persoonlijk met aansprakelijkheid en, in ernstige gevallen, strafrechtelijke consequenties worden geconfronteerd. 

Daarmee verandert de vraag definitief. Niet meer: “Is onze IT veilig?” Maar: “Kunnen wij als bestuur aantonen dat we onze digitale risico’s kennen, beheersen, monitoren en dat we volgens plan handelen als het misgaat?” Dat is volwassen digitaal bestuur. En dat kun je niet uitbesteden.

Photo by Markus Winkler

———————–   Translated by ChatGPT —————-

From Black Boxes to Accountability: Why Digital Governance Cannot Be Outsourced

In my earlier blog, “A Black Box for Monitoring AI Agents?”, I explored why autonomous AI agents need something similar to a flight recorder. When an agent makes decisions on its own, we need to be able to reconstruct what happened afterwards. What did the agent do? What instructions did it receive? What data did it use? And what action followed?

That is not a luxury. It is a prerequisite for trust.

In aviation, we would never accept an aircraft carrying hundreds of people without being able to investigate what happened during a flight. A flight recorder is not proof that an aircraft is safe. It is a tool for recording events, demonstrating what happened, and learning from them.

That is exactly the capability we now need to build into the digital world.

More and more digital systems are capable of acting autonomously. AI agents make decisions. Microservices interact with one another. Cloud platforms scale automatically. Data moves through increasingly complex chains of systems and suppliers that few organisations can fully oversee.

Somewhere in that chain, something may happen that nobody anticipated. The first question will be: what happened? A black box can help answer that question. But the more important questions come afterwards: why did it happen? Could we have seen it coming? And who should have acted?

A black box records, but it does not understand

That was the central idea behind another blog I wrote: “The Black Box Knows Everything. Except What Is Wrong.” We are now able to measure almost everything. But measuring is not the same as understanding.

A complex digital environment increasingly resembles a living organism. Millions of processes operate simultaneously, and small deviations can reinforce one another. A problem may begin deep inside a digital chain and only become visible much later, somewhere completely different.

Traditional monitoring mostly sees symptoms. Latency increases. A database becomes slower. An API starts producing more errors. An AI agent begins behaving differently from normal. But which signal represents the cause, and which is merely a consequence? That is why we need to move beyond logging.

From recording to understanding. From measurement to diagnostics. And ultimately, to identifying the root cause. The flight recorder tells us what happened. The digital doctor tries to understand why the system became unbalanced. What is the ‘root-cause’?

And that is where the board enters the picture

This is where NOREA’s public management letter on digital resilience becomes particularly relevant. NOREA makes digital resilience explicitly a matter of governance. It is not simply the responsibility of the CIO or the CISO. The board and executive leadership as a whole must take responsibility for steering the organisation’s digital resilience.

That requires insight into digital dependencies and supply chains, coherent governance, continuous security and improvement, conscious risk acceptance, and meaningful accountability.

This adds another layer to the story. The black box records. Digital diagnostics tries to understand. But who decides what needs to happen next? Ultimately, that is a governance question. This does not mean that board members should configure firewalls or personally analyse security incidents. But it does mean that they are responsible for ensuring that the organisation has a system capable of keeping it digitally healthy and resilient.

And that is precisely where Governance, Risk Management and Compliance come together.

Governance determines why and how

Governance starts with the fundamental questions. What matters to us as an organisation? Which digital services are critical? Which data must we protect? Which dependencies are we willing to accept? Which risks are acceptable — and which are not?

But governance is also about structure and decision-making. Who owns the risk? Who has the authority to make decisions? Who needs to be informed? What happens when something goes wrong? Which escalation path applies? And when does an issue require direct involvement from the board?

A mature governance model therefore defines more than what needs to be secure. It also explains why, how, and with which resources the organisation intends to achieve that security.

Risk management makes governance operational

Then comes risk management. Do we understand the risks we face? Do we know which systems, suppliers, and dependencies are involved? Can we detect deviations early enough? Do employees know how to report them? Is it clear who takes action and when escalation becomes necessary?

Good risk management is not only about predicting what might happen. It is also about organising what happens when something actually does go wrong.

This turns the black box into part of a much larger system. Logging, monitoring, and AI observability provide the information. Risk management determines what the organisation does with that information. And that process cannot exist only on paper. It has to work under pressure, when an incident is actually happening.

Compliance must provide the evidence

This is where compliance becomes essential. Can we use an audit trail to demonstrate that our controls actually work — or worked when they were needed? Can we demonstrate that we were compliant before a cyberattack occurred? But perhaps the more important question is this:

Can we demonstrate that we acted according to our plans and predefined scenarios during the attack itself?

Who reported the incident? Who assessed it? Who initiated the escalation? Which people were involved? Which decisions were made? When was the board informed? What communication took place? And did the organisation act in the way it had agreed to act beforehand? That is a very different view of compliance from completing an annual checklist.

The real test of compliance begins when something goes wrong. An organisation should not only be able to say that it was compliant. It should also be able to demonstrate that it acted compliantly. The audit trail therefore becomes the organisation’s digital witness. Not only recording what systems did, but also documenting what people and leaders decided.

From evidence to accountability

This brings the different ideas together. Security by evidence means being able to demonstrate what is happening and which controls are in place. But security by accountability goes a step further.

It asks who is responsible for organising those controls, monitoring them, and making decisions when reality no longer follows the plan.

The OODA loop helps organisations observe, understand, decide, and act during an incident. PDCA ensures that they learn and improve afterwards. GRC ensures that all of this becomes part of the organisation’s normal governance and management processes. That transforms digital resilience from a temporary project into a permanent management system. And that is where the significance of NOREA’s management letter becomes clear.

Digital governance cannot be outsourced

The digital world has very few organisational boundaries left. Cloud providers, software vendors, AI services, and subcontractors together form complex ecosystems on which organisations increasingly depend. The technology can be outsourced. The infrastructure can be outsourced. Operations can be outsourced. But governance responsibility cannot.

A supplier may be responsible for its platform. The CISO may be responsible for security policy. IT may be responsible for technical implementation. An auditor may assess whether controls are functioning effectively. But the board remains responsible for the fundamental questions.

Does the organisation understand its digital risks? Does it know how those risks are managed? Which risks is it consciously willing to accept? And can it demonstrate that it is capable of acting effectively when things go wrong? That is the transition from security by evidence to security by accountability.

And that accountability is becoming increasingly explicit. European legislation and regulation are placing greater emphasis on management responsibility and oversight in the area of digital and cyber resilience. The question is therefore changing fundamentally.

It is no longer simply: “Is our IT secure?” The real question is:

“Can we, as a board, demonstrate that we understand our digital risks, manage them, monitor them, and act according to plan when something goes wrong?”

That is what mature digital governance looks like.

And you cannot outsource it.