KETENVERANTWOORDELIJKHEID

DSR Round Table over ketenverantwoordelijkheid

Wie is verantwoordelijk als niemand de hele digitale keten beheerst?

De digitale keten wordt steeds complexer. Maar de verantwoordelijkheid groeit niet automatisch mee. Wie is eigenaar van het risico als een applicatie van de ene partij komt, in de cloud van een andere draait en door een derde wordt beheerd? En wie neemt de regie als er iets misgaat? Tijdens de DSR Round Table over ketenverantwoordelijkheid ontstond geen eenvoudig antwoord. Wel een scherpe conclusie: digitale autonomie, governance en resilience beginnen met weten waar je afhankelijk van bent.

TEKST: SANDER HULSMAN BEELD: EVENTSHOOT

Het scenario waarmee de discussie wordt geopend, is bijna alledaags. Een organisatie wordt getroffen door een ernstig digitaal incident. De applicatie komt van een producent, draait in de cloud en wordt beheerd door een externe dienstverlener. De organisatie zelf heeft geen volledig inzicht in de onderliggende infrastructuur. Wie is verantwoordelijk?

Het is precies het soort vraag waarop in de praktijk al snel naar contracten, SLA’s en leveranciers wordt gewezen. Maar aan tafel blijkt al snel dat daarmee het probleem niet is opgelost. De verantwoordelijkheid van de producent, de leverancier en de eindgebruiker loopt door elkaar heen. En juist op de punten waar verantwoordelijkheden elkaar raken, ontstaan de grootste risico’s.

Hans van Linschoten

Verantwoordelijkheid niet uit te besteden

Hans van Linschoten, directeur van Whitesky.cloud, begint vanuit de praktijk van de leverancier. Een managed serviceprovider kan volgens hem alleen verantwoordelijkheid nemen voor wat hij daadwerkelijk beheert en belooft. De grenzen daarvan moeten volgens hem vooraf helder worden gemaakt. “Als je een managed service levert aan een partij, dan ben je als managed servicebedrijf toch echt verantwoordelijk voor datgene wat je belooft te leveren.”

Tegelijkertijd is ook voor Van Linschoten duidelijk dat verantwoordelijkheid in een keten nooit volledig bij één partij kan liggen. Een dienstverlener is immers afhankelijk van de opdrachtgever en van andere leveranciers. Die afhankelijkheden moeten volgens hem worden vertaald naar concrete afspraken en SLA’s.

Erik Witte

Dat lijkt logisch, maar de discussie wordt interessanter wanneer Erik Witte, CEO van Methodino, de verantwoordelijkheid bij de eindgebruiker neerlegt. “De leverancier kan een deel van het risico overnemen. Hij kan implementeren, beheren en monitoren. Maar de continuïteit van de organisatie zelf blijft de verantwoordelijkheid van de klant.” Witte formuleert het scherp: “Je kunt je eigen risicoacceptatie niet uitbesteden.” Daarmee verschuift de discussie van de klassieke vraag van wie er schuld heeft naar een veel relevantere vraag: wie is eigenaar van het risico?

Techniek houdt op, governance begint

Dat is volgens de deelnemers uiteindelijk geen vraag voor alleen de CISO of IT-manager. Het is een bestuurlijke vraag. Een organisatie kan haar infrastructuur uitbesteden, maar niet de beslissing welke risico’s acceptabel zijn. Ze kan een cloudprovider inschakelen, maar daarmee verdwijnt de verantwoordelijkheid voor continuïteit niet. Ze kan securitymaatregelen inkopen, maar niet het oordeel over de vraag of de organisatie voldoende weerbaar is.

Voor Witte zit daar ook een informatieprobleem onder. “Verschillende afdelingen kijken vanuit hun eigen perspectief naar dezelfde omgeving. Security ziet andere dingen dan operations, architectuur of risk. Daardoor kan iedereen zijn werk goed doen en toch kan het totaalbeeld ontbreken.”

Een CISO die alleen weet welke controls zijn ingericht, heeft nog niet noodzakelijk inzicht in het risico van de hele keten

Dat is precies waar governance volgens hem concreet moet worden. Dus niet nog een dashboard toevoegen, maar zorgen dat de organisatie weet wat er technisch werkelijk gebeurt en welke afhankelijkheden daaruit voortkomen. Witte: “Je kunt je eigen risicoacceptatie nooit uitbesteden. Daarvoor moet je als organisatie continu kunnen vaststellen wat er technisch werkelijk gebeurt en wat dat betekent voor je risico’s.”

Dat is een wezenlijk verschil. Een CISO die alleen weet welke controls zijn ingericht, heeft nog niet noodzakelijk inzicht in het risico van de hele keten. Bestuurlijke verantwoordelijkheid begint juist bij het kunnen verbinden van die technische werkelijkheid aan een besluit.

Keten stopt niet bij leverancier

Een van de meest concrete discussies ontstaat wanneer de deelnemers praten over veranderingen bij leveranciers. Wat gebeurt er wanneer een leverancier zonder overleg van onderliggende cloudprovider wisselt? Of wanneer een subcontractor een andere component in een product stopt? Voor een organisatie die haar risicoanalyse heeft gebaseerd op de oorspronkelijke situatie kan zo’n wijziging grote gevolgen hebben.

Hanc de Bokx

Hanc de Bokx, eigenaar van 1A First Alternative, herkent dat probleem, maar kiest bewust voor een andere manier van organiseren. Zijn bedrijf probeert het aantal kritieke afhankelijkheden klein te houden en haalt onderdelen die strategisch belangrijk zijn waar mogelijk weer naar zich toe. “Dat is een bewuste keuze. Je weet dan echt wat er gebeurt.”

Voor De Bokx gaat digitale autonomie bovendien verder dan security. Ook economische afhankelijkheid hoort volgens hem erbij. “Wanneer één partij een dominante positie krijgt, heeft dat uiteindelijk gevolgen voor prijs, flexibiliteit en keuzevrijheid.” Dat maakt autonomie voor hem geen ideologisch verhaal over wel of geen Amerikaanse technologie, maar de praktische vraag hoeveel controle je zelf over je dienstverlening houdt.

Frank Olsthoorn

Dezelfde gedachte komt terug bij Frans Olsthoorn, medeoprichter van EUnifyer. Hij kijkt vooral naar de afhankelijkheid van grote technologieplatforms en naar de mogelijkheid om daadwerkelijk uit te wijken wanneer dat nodig is. Voor EUnifyer is dat niet alleen een theoretische exitstrategie. Het bedrijf ontwikkelt een digitaal noodpakket waarin bijvoorbeeld e-mail, agenda, contacten en bestanden beschikbaar blijven wanneer een Microsoft-omgeving niet meer beschikbaar is. Daarmee moet een organisatie kunnen blijven werken wanneer de primaire omgeving uitvalt.

Olsthoorn ziet daarin ook een bredere Europese dimensie. “Als we kijken naar het juridische stuk, zou ik zeggen dat Amerikaanse afhankelijkheid op dit moment het grootste risico gewoon is.” Hij voegt daar nadrukkelijk aan toe dat dit niet betekent dat Microsoft of andere Amerikaanse technologie per definitie moet verdwijnen. Het probleem zit volgens hem in een situatie waarin één partij structureel toegang, infrastructuur en daarmee feitelijk de continuïteit van een organisatie kan bepalen.

Autonomie is niet alles zelf doen

Daarmee ontstaat een interessante nuance in het debat. Digitale autonomie wordt gemakkelijk vertaald naar zelf technologie bouwen, Europese leveranciers kiezen of zoveel mogelijk open source gebruiken. Aan tafel blijkt het vraagstuk ingewikkelder.

Autonomie draait uiteindelijk minder om het bezit van technologie dan om keuzevrijheid

Erik Witte maakt het onderscheid expliciet. Het maakt volgens hem voor het fundamentele governancevraagstuk niet eens zoveel uit of een organisatie Microsoft-technologie, open source of andere standaarden gebruikt. “De kern is of de organisatie weet welke risico’s zij loopt en waarom zij die accepteert.”

Ook Hanc de Bokx waarschuwt voor een te simpele redenering rond open source. “Het gebruik van open source neemt de verantwoordelijkheid niet automatisch weg. Als een component niet meer wordt onderhouden, ontstaat nog steeds een risico.”

Autonomie draait daarmee uiteindelijk minder om het bezit van technologie dan om keuzevrijheid. Kun je overstappen? Kun je data meenemen? Kun je een andere leverancier inschakelen? Kun je een dienst tijdelijk zelf of via een andere partij laten draaien? En vooral: weet je vooraf wat daarvoor nodig is? Dat laatste blijkt tijdens de round table een belangrijk punt. Een exitstrategie die alleen in een contract staat, is nog geen werkbare exitstrategie.

Mark Meerbeek

Exitstrategie begint op dag één

Mark Meerbeek, medeoprichter van De AI Fabriek en strategisch partner van Scaleway in Nederland, brengt het gesprek terug naar de praktijk van organisaties die diensten en IT-omgevingen uitbesteden. Hij vertelt over een gemeente die overstapt van eigen beheer naar een gezamenlijk IT-model met meerdere gemeenten. Zijn eerste vraag bij zo’n nieuwe samenwerking is opvallend eenvoudig: wat is de exitstrategie? Het antwoord was er aanvankelijk niet.

De nieuwe samenwerking was vanuit het perspectief van de betrokken partijen ingericht alsof vertrek geen reële optie was. Maar juist dat is volgens Meerbeek een denkfout. “Ik denk dat je aan het begin van een nieuwe samenwerking al een exitstrategie moet bespreken. Of in ieder geval in je strategie opgenomen moet hebben.” Dat is misschien wel een van de meest praktische lessen uit de discussie. Exit is geen onderwerp voor het moment waarop een samenwerking mislukt. Het is een onderdeel van het ontwerp van die samenwerking.

Hanc de Bokx gaat nog een stap verder. Bij 1A is ondersteuning bij een overgang volgens hem standaard onderdeel van de dienstverlening. Data blijven beschikbaar en het bedrijf werkt mee aan een transitie. Erik Witte ziet daar een directe relatie met inzicht in afhankelijkheden. “Wie continu inzicht heeft in de werkelijke technische afhankelijkheden in de keten, kan ook veel beter bepalen wat nodig is om van leverancier of technologie te wisselen. Dat lijkt bijna een paradox: hoe beter je je leverancier kent, hoe minder afhankelijk je van die leverancier hoeft te zijn.”

Hans Quist

Bestuurlijke verantwoordelijkheid

Voor Hans Quist, CISO van de Provincie Zeeland, ligt de bestuurlijke verantwoordelijkheid nog nadrukkelijker op tafel. Zijn perspectief is dat van een organisatie die niet alleen met technische risico’s te maken heeft, maar ook met publieke verantwoordelijkheid. Bij de opening van de discussie is zijn antwoord op de vraag wie uiteindelijk verantwoordelijk is bij een ernstig digitaal incident helder: niet de leverancier, maar de organisatie en uiteindelijk het bestuur. De ontwikkeling van wet- en regelgeving maakt die bestuurlijke verantwoordelijkheid bovendien steeds explicieter.

Quist werkt daarbij niet alleen binnen zijn eigen provincie. De twaalf provinciale CISO’s werken nauw samen en delen dreigingsinformatie. Ook is er een interprovinciaal ISAC. De governance ligt dus niet uitsluitend binnen één organisatie; ook overheidsorganisaties moeten gezamenlijk leren omgaan met digitale afhankelijkheden. Zijn perspectief maakt duidelijk waarom ketenverantwoordelijkheid uiteindelijk een bestuurlijke kwestie is. “Een organisatie kan niet volstaan met de constatering dat een leverancier een bepaalde fout heeft gemaakt. Het bestuur moet kunnen uitleggen waarom de organisatie van die leverancier afhankelijk was, welke risico’s daarbij hoorden en welke maatregelen waren genomen om de impact te beperken.”

Grootste kwetsbaarheid in digitale keten

Aan het einde van het eerste deel krijgt iedere deelnemer een eenvoudige vraag: wat is op dit moment de grootste kwetsbaarheid in de digitale keten? Het eerste antwoord is bijna voorspelbaar: de mens. Maar Frans Olsthoorn kiest een ander perspectief: Amerikaanse afhankelijkheid. Mark Meerbeek wijst op iets anders: het onbekende. Zeker met de snelle ontwikkeling van AI ontstaan nieuwe manieren waarop data en processen worden gebruikt die organisaties zelf niet altijd overzien.

Dat maakt het risico van vandaag anders dan het risico van tien jaar geleden. Niet alleen omdat technologie verandert, maar omdat de keten zelf verandert terwijl organisaties proberen die keten te beheersen. Een AI-toepassing kan bijvoorbeeld verschillende modellen, cloudplatforms en databronnen combineren. Een cloudomgeving kan onderliggende leveranciers wijzigen. Een managed serviceprovider kan afhankelijk zijn van een derde partij. Een leverancier kan worden overgenomen. Wetgeving kan veranderen. Een contract kan nog steeds hetzelfde zijn terwijl de technische werkelijkheid erachter allang veranderd is. Daarmee wordt resilience iets anders dan een back-up of disaster recovery-plan.

Shared responsibility is alleen zinvol als daar ook shared understanding tegenover staat

Resilience betekent kunnen handelen

De vraag is uiteindelijk niet of een organisatie iedere verstoring kan voorkomen. Dat kan niet. De vraag is of zij kan handelen wanneer een verstoring zich voordoet. Wie neemt de regie? Welke informatie is betrouwbaar? Welke diensten zijn kritiek? Welke alternatieven zijn beschikbaar? Hoe snel kan een organisatie overstappen? Welke data zijn beschikbaar? En wie mag op welk moment beslissen? Daarvoor is inzicht nodig. Niet alleen in de eigen infrastructuur, maar in de afhankelijkheden die daar doorheen lopen. Dat is ook waar de verschillende perspectieven van de deelnemers bij elkaar komen. Voor Van Linschoten begint het bij heldere verantwoordelijkheden tussen partijen. Voor De Bokx bij grip en het bewust beperken van afhankelijkheden. Voor Olsthoorn bij keuzevrijheid en een praktische exit. Voor Meerbeek bij het vanaf het begin meenemen van continuïteit. Voor Quist bij bestuurlijke verantwoordelijkheid. En voor Witte bij het kunnen vaststellen van de technische werkelijkheid waarop risico- en bestuursbesluiten worden gebaseerd. Geen van die perspectieven is op zichzelf voldoende. Juist samen vormen ze de basis voor een weerbare digitale keten.

Shared responsibility wordt shared understanding

De round table levert daarmee geen nieuw model op waarin iedere partij keurig een eigen vakje krijgt toegewezen. Misschien is dat ook precies de verkeerde verwachting. De werkelijkheid is daarvoor te complex. Een producent is verantwoordelijk voor zijn product. Een leverancier voor wat hij levert en beheert. Een klant voor zijn eigen continuïteit. Een bestuur voor de risico’s die de organisatie bewust accepteert. Maar tussen die verantwoordelijkheden zitten afhankelijkheden die niemand alleen kan oplossen. Daarom is shared responsibility alleen zinvol als daar ook shared understanding tegenover staat. Je moet weten hoe de keten eruitziet. Je moet weten waar de kritieke afhankelijkheden zitten. Je moet weten wat er verandert. Je moet weten welke risico’s je accepteert. En je moet vooraf weten wat je doet als een belangrijke schakel wegvalt. Pas dan wordt ketenverantwoordelijkheid meer dan een afspraak op papier. En misschien is dat de belangrijkste conclusie van deze middag wel dat digitale autonomie niet betekent dat je alles zelf doet. Het betekent dat je voldoende inzicht, keuzevrijheid en handelingsvermogen houdt om verantwoordelijkheid te kunnen nemen wanneer de werkelijkheid verandert. Want uiteindelijk blijft de lastigste vraag niet: wie verantwoordelijk is. De lastigste vraag is: wie ervoor zorgt dat de keten als geheel blijft werken als het misgaat.

Video-interviews

Tijden de DSR Round Table zijn er ook afzonderlijke video-interviews met de deelnemers opgenomen. Deze gaan onder andere over meer digitale autonomie, cloud, open source, governance, AI en leveranciersafhankelijkheid.

VORIGE

MENU

VOLGENDE