Stel de vraag eens hardop in de directievergadering: welk bedrijfsproces valt morgen stil als onze belangrijkste Amerikaanse cloudleverancier zijn dienstverlening aan ons opschort? Niet door een storing, maar door een sanctiepakket, een handelsconflict of een beslissing in een rechtszaal duizenden kilometers verderop. De meeste organisaties kunnen die vraag niet beantwoorden. Niet omdat het antwoord geruststellend is, maar omdat niemand hem ooit gesteld heeft.
Waarom dit geen IT-vraag meer is
Europese organisaties draaien in overgrote meerderheid op software, cloud en beheerde diensten van buiten Europa. Dat was jarenlang een puur praktische keuze: het beste product, de beste prijs. Het is inmiddels ook een geopolitieke positie. Digitale afhankelijkheden zijn een drukmiddel geworden in de verhoudingen tussen grote machten, en beslissingen over waar je data staat, wie je sleutels beheert en onder welk recht je leverancier valt, hebben gevolgen voor beschikbaarheid, vertrouwelijkheid en juridische blootstelling die ver buiten je eigen invloed liggen.
Daar komt bij dat leveranciers zelf een aanvalsroute zijn geworden. Een compromittering van een softwareleverancier, een beheerpartij of een SaaS-platform raakt in één keer alle klanten. Steeds vaker wordt een organisatie afgeperst met data die niet bij haarzelf is gestolen, maar bij een partij die die data voor haar verwerkte. Je kunt je eigen beveiliging op orde hebben en toch in het nieuws komen.
Waarom de klassieke risicoanalyse hier faalt
De gebruikelijke methoden, een leveranciersvragenlijst, een certificaat opvragen, een risicomatrix invullen, zijn gebouwd voor technische en contractuele risico's. Ze hebben geen antwoord op "wat als de leverancier morgen niet meer mág leveren" of "wat als onze data onder een ander rechtsstelsel opvraagbaar blijkt". Die scenario's staan in geen enkel standaardframework, en dus blijven ze buiten beeld.
Wat wél werkt, is het scenario zelf doorlopen. Neem een concreet proces, bijvoorbeeld orderverwerking, zorgplanning of salarisbetaling, en loop de keten af: welke diensten zitten erin, van wie, onder welk recht, met welke uitwijk? Wat breekt er bij een dag uitval, bij een week, bij permanent verlies? Dat levert binnen een dagdeel een lijst met afhankelijkheden op die niemand eerder als één geheel had gezien, en meestal ook twee of drie plekken waar een eenvoudige maatregel het risico sterk verkleint.
Wat je concreet kunt doen
- Ken je afhankelijkheden. Een actueel overzicht van leveranciers, platforms, koppelingen en toegangen, met per kritisch proces welke ervan onmisbaar zijn. Dit is dezelfde inventaris die je nodig hebt bij een incident; je maakt hem dus toch al.
- Onderscheid onmisbaar van vervangbaar. Niet alles hoeft Europees of dubbel uitgevoerd. Wel moet je weten welke twee of drie diensten je organisatie stilleggen als ze wegvallen, en daar een uitwijk of een exitplan voor hebben.
- Beheer je eigen sleutels waar het ertoe doet. Voor de meest gevoelige data: versleuteling met sleutels die jij beheert, zodat toegang door een leverancier of een buitenlandse overheid technisch geen betekenis heeft.
- Leg toegang van leveranciers vast en bewaak hem. Beheerpartijen en leveranciers hebben vaak ruime, langlopende toegang. Behandel die als wat het is: een geprivilegieerde identiteit in jouw omgeving. Beperk, log, beoordeel periodiek en trek in bij vertrek.
- Zet het in contracten. Eisen aan beveiliging, incidentmelding, dataretourage en beëindiging horen in de overeenkomst, niet in een goed gesprek.
- Maak er een bestuursonderwerp van. De vraag "wat als onze leverancier niet meer mag leveren" is geen technische vraag. Wie hem in de bestuurskamer stelt en periodiek herhaalt, is verder dan het overgrote deel van de organisaties.
Regelgeving als aanleiding, niet als doel
De Cyberbeveiligingswet, DORA en aanverwante regels vragen inmiddels expliciet om beheersing van risico's in de leveringsketen en om aantoonbare voorbereiding op verstoring. Dat kun je zien als een lijstje. Je kunt het ook gebruiken als aanleiding om de scenario's hierboven één keer goed te doorlopen, de uitkomsten in je risicoregister te zetten en ze jaarlijks te herhalen. Dan is het bewijs voor de toezichthouder een bijproduct van iets wat je toch al wilde weten. Dat is precies hoe we het binnen Managed Compliance aanpakken: niet als project met een einddatum, maar als cyclus waarin leveranciers en afhankelijkheden een vast onderdeel zijn.