KETENVERANTWOORDELIJKHEID
Ketenverantwoordelijkheid
Verantwoordelijkheid stopt niet bij de voordeur
Digitale dienstverlening bestaat allang niet meer uit losse systemen en afzonderlijke organisaties. Software, cloud, infrastructuur, leveranciers en gebruikers zijn met elkaar verbonden in steeds complexere ketens. Daarmee ontstaat de nieuwe vraag wie er verantwoordelijk is voor de weerbaarheid van het geheel. In dit dossier onderzoekt DSR wat ketenverantwoordelijkheid betekent, waar die verantwoordelijkheid begint en eindigt en hoe organisaties grip houden op afhankelijkheden die zij niet volledig zelf kunnen beheersen.
TEKST: SANDER HULSMAN BEELD: ENVATO
Een organisatie kan haar eigen IT uitstekend beveiligen en toch kwetsbaar zijn. Dat klinkt misschien vreemd, maar in de digitale werkelijkheid van vandaag is het heel normaal. Een applicatie komt van een softwareleverancier, draait op cloudinfrastructuur van een andere partij, wordt beheerd door een IT-dienstverlener en maakt gebruik van tientallen of honderden andere softwarecomponenten. Daarachter zitten weer andere leveranciers, datacenters, netwerken en infrastructuur.
Wie is dan verantwoordelijk wanneer het misgaat? Precies daar draait ketenverantwoordelijkheid om. Het begrip gaat niet simpelweg over het verdelen van taken tussen leverancier en klant. Het gaat over de vraag hoe je verantwoordelijkheid organiseert wanneer geen enkele partij de volledige digitale keten bezit, beheert of zelfs maar volledig kan overzien. Dat vraagt om meer dan goede contracten. Het vraagt om inzicht in afhankelijkheden, duidelijke governance, bestuurlijke verantwoordelijkheid en het vermogen om te handelen wanneer een schakel wegvalt.
Eigen verantwoordelijkheid vs.
ketenverantwoordelijkheid
Traditioneel kijken organisaties vooral naar hun eigen verantwoordelijkheid. De eigen infrastructuur moet veilig zijn, de eigen processen moeten blijven functioneren en de eigen leveranciers moeten hun afspraken nakomen. Maar een digitale verstoring houdt zich niet aan organisatiegrenzen.
Een cloudprovider kan uitvallen. Een softwarecomponent kan kwetsbaar blijken. Een leverancier kan worden overgenomen. Een geopolitieke ontwikkeling kan een technologieafhankelijkheid ineens relevant maken. Of een derde partij verderop in de keten kan een probleem veroorzaken waar de organisatie zelf nauwelijks zicht op heeft. Daarmee ontstaat een belangrijk onderscheid tussen verantwoordelijkheid voor je eigen omgeving en verantwoordelijkheid voor de gevolgen van je afhankelijkheden.
Ketenverantwoordelijkheid betekent niet dat iedere organisatie verantwoordelijk wordt voor alles wat ergens verderop in de keten gebeurt. Dat zou onwerkbaar zijn. Het betekent wel dat organisaties moeten weten van welke partijen en technologieën zij afhankelijk zijn, welke risico’s daarbij horen en welke verantwoordelijkheid bij iedere schakel ligt. En misschien nog belangrijker: wat gebeurt er wanneer een schakel niet meer kan leveren?
Wie is eigenaar van een ketenrisico? De leverancier? De CISO? De CIO? De business? Het bestuur?
Ketenverantwoordelijkheid vraagt om inzicht
Je kunt verantwoordelijkheid immers moeilijk organiseren als je niet weet waarvoor je afhankelijk bent. Dat klinkt eenvoudig, maar juist de langere digitale ketens zijn steeds moeilijker zichtbaar te maken. De directe leverancier kennen we meestal wel. Maar hoe zit het met de leverancier van die leverancier? En de softwarecomponenten die in een dienst zijn verwerkt? Of de infrastructuur waarop die componenten draaien? Daarmee verschuift het vraagstuk van leveranciersmanagement naar keteninzicht.
Dat thema komt nadrukkelijk terug in het artikel over de extended supply chain naar aanleiding van de European Resilience Summit. Daarin staat de vraag centraal hoe organisaties zicht krijgen op derde, vierde en verdere partijen in de keten. Begrippen als SBOM en HBOM zijn daarbij niet interessant als administratieve verplichting, maar omdat ze kunnen helpen om daadwerkelijk te begrijpen waaruit een digitale omgeving bestaat. Zonder dat inzicht wordt ketenverantwoordelijkheid al snel een papieren werkelijkheid.
Verantwoordelijkheid moet ergens landen
Inzicht alleen is echter niet genoeg. Als iedereen weet dat een risico bestaat, maar niemand weet wie erover gaat, is de organisatie nog steeds kwetsbaar. Daarom is governance een tweede pijler van ketenverantwoordelijkheid. Wie is eigenaar van een ketenrisico? De leverancier? De CISO? De CIO? De business? Het bestuur?
De artikelen in dit dossier laten zien dat het antwoord niet altijd hetzelfde is. Een leverancier kan verantwoordelijk zijn voor de dienstverlening die hij levert. Een klant blijft verantwoordelijk voor de continuïteit van zijn organisatie. En uiteindelijk kan een bestuurder zich niet verschuilen achter het feit dat een bepaalde IT-dienst is uitbesteed.
Dat maakt ketenverantwoordelijkheid ook nadrukkelijk een bestuurlijk onderwerp. Het gaat niet alleen om de vraag of een leverancier zijn SLA haalt. Het gaat om de vraag of een organisatie weet welke afhankelijkheden zij accepteert, waarom zij die acceptabel vindt en wat zij doet als de omstandigheden veranderen.
Een organisatie hoeft niet onafhankelijk te zijn om autonoom te kunnen handelen
Autonomie betekent kunnen kiezen
Daarmee raakt ketenverantwoordelijkheid direct aan digitale autonomie. Autonomie betekent daarbij niet dat organisaties alles zelf moeten bouwen of beheren. Dat zou voor de meeste organisaties onmogelijk en ook niet wenselijk zijn. Het gaat om keuzevrijheid. Kun je je data meenemen? Kun je van leverancier wisselen? Zijn er alternatieven? Kun je een dienst tijdelijk op een andere manier organiseren? Weet je wat daarvoor nodig is?
Dat perspectief komt terug in de verschillende gesprekken en interviews in dit dossier. Open source, open standaarden, Europese cloud en alternatieven voor dominante technologieplatforms zijn daarbij geen doelen op zichzelf. Ze zijn middelen om afhankelijkheden beheersbaar te houden en handelingsruimte te creëren.
Een organisatie hoeft dus niet onafhankelijk te zijn om autonoom te kunnen handelen. Maar zij moet wel voorkomen dat een afhankelijkheid verandert in een situatie waarin zij feitelijk geen keuze meer heeft.
Resilience begint waar preventie ophoudt
Dat brengt ons bij het vierde element: resilience. Ketenverantwoordelijkheid wordt uiteindelijk getest wanneer het misgaat. Een organisatie kan haar eigen systemen beveiligen, maar wat gebeurt er wanneer een cruciale leverancier uitvalt? Wie neemt dan de regie? Welke informatie is beschikbaar? Welke alternatieven zijn er? Hoe snel kan de organisatie herstellen?
Het artikel over de European Resilience Summit laat zien dat dit vraagstuk veel verder gaat dan digitale security. Een luchthaven, gemeente of andere grote organisatie functioneert als een ecosysteem waarin tientallen of duizenden partijen van elkaar afhankelijk zijn. Een verstoring bij één partij kan daardoor gevolgen hebben voor vele anderen.
Resilience betekent dan niet dat iedere verstoring moet worden voorkomen. Dat is onmogelijk. Het betekent dat je weet wat er kan gebeuren, dat je hebt geoefend en dat je kunt herstellen wanneer een schakel uitvalt. Ketenverantwoordelijkheid gaat daarmee uiteindelijk niet over het beheersen van de hele keten, maar over het organiseren van voldoende inzicht, verantwoordelijkheid en handelingsvermogen binnen die keten.
Als morgen een cruciale schakel wegvalt, weten we dan wie wat moet doen?
Vier perspectieven op één vraag
De vier artikelen in dit dossier belichten dat vraagstuk ieder vanuit een ander perspectief.
In het verslag van de DSR Round Table staat de verdeling van verantwoordelijkheid centraal. Producenten, leveranciers en eindgebruikers bespreken wie eigenaar is van risico’s, hoe governance moet worden ingericht en hoe organisaties hun digitale autonomie en resilience kunnen versterken.
De video-interviews met de deelnemers gaan vervolgens dieper in op hun individuele perspectieven. Digitale autonomie, cloud, open source, governance, AI, leveranciersafhankelijkheid en continuïteit komen daarin vanuit verschillende rollen aan bod.
Het artikel over de European Resilience Summit verbreedt het perspectief naar de maatschappelijke en fysieke keten. Schiphol, cloudinfrastructuur, publieke organisaties en Europese digitale autonomie laten zien dat resilience niet ophoudt bij de eigen IT-omgeving.
Het artikel over de extended supply chain gaat nog een laag dieper, want hoe krijg je zicht op de partijen die je zelf niet eens kent? Met aandacht voor derde- en vierde partijen, SBOM’s, HBOM’s, supply-chainrisico’s en de vraag hoe verantwoordelijkheid over meerdere lagen kan worden georganiseerd.
Samen laten de vier artikelen zien dat ketenverantwoordelijkheid geen technisch deelonderwerp is van cybersecurity of IT. Het is een manier om naar digitale afhankelijkheid te kijken.
Verantwoordelijkheid organiseren
Daarmee is ook duidelijk wat ketenverantwoordelijkheid niet betekent. Het betekent niet dat een leverancier alle risico’s van een klant moet overnemen. Het betekent niet dat een klant zich achter een contract kan verschuilen. En het betekent evenmin dat iedere organisatie volledige controle moet krijgen over iedere schakel in de keten.
Het gaat erom dat verantwoordelijkheden expliciet zijn, dat afhankelijkheden zichtbaar zijn en dat partijen weten wat ze van elkaar mogen verwachten. En dat zij vooraf nadenken over het moment waarop iets niet meer werkt. Want uiteindelijk is dat misschien de beste test voor ketenverantwoordelijkheid, want als morgen een cruciale schakel wegvalt, weten we dan wie wat moet doen?
Als het antwoord daarop ja is, is er sprake van meer dan alleen een contractuele keten. Dan ontstaat een weerbare digitale keten. Dat is het centrale thema van dit DSR-dossier: niet hoe organisaties alle afhankelijkheden kunnen voorkomen, maar hoe zij verantwoordelijkheid, inzicht en handelingsvermogen kunnen organiseren in een wereld waarin afhankelijkheid onvermijdelijk is. 