Het staat in de offerte, in het contract en in de mond van de accountmanager: het systeem staat in een geïsoleerd netwerksegment, de beheerde dienst is veilig ingericht, de back-up is onaantastbaar. Leveranciersclaims testen is de enige manier om te weten of dat waar is, en de uitkomst is vaker ontnuchterend dan geruststellend.
Dit kwartaal werden bij ons drie verschillende soorten leveranciersclaims door een pentest getoetst: een systeem dat geïsoleerd zou staan, een beheerde omgeving die veilig heette te zijn en een back-upvoorziening die tegen alles bestand zou zijn. Daar zit een verschuiving achter: organisaties nemen beweringen niet meer aan op gezag, en dat is de goede reflex. In dit artikel lees je welke claims je hoort te toetsen, hoe zo’n test eruitziet en hoe je het gesprek met de leverancier voert zonder de relatie te beschadigen.
Eerst het eerlijke antwoord
- Een claim in een contract is een belofte, geen bewijs; alleen een test maakt er een feit van.
- De drie meest getoetste claims: netwerkisolatie, de veiligheid van beheerde diensten, en de onaantastbaarheid van back-ups.
- Onder de Cyberbeveiligingswet blijft de zorgplicht bij jou, ook als de claim van je leverancier komt.
- Kondig de test aan en behandel een gefaalde claim als een gewone bevinding: eigenaar, deadline, hertest. Een leverancier die weigert, vertelt je ook iets.
Waarom leveranciersclaims testen geen wantrouwen is
De zorgplicht onder de Cyberbeveiligingswet ligt bij jouw organisatie, ook voor de onderdelen die een leverancier invult. Zie welke maatregelen de zorgplicht vraagt: uitbesteden verplaatst het werk, niet de verantwoordelijkheid. Een toezichthouder die na een incident vraagt waarom je een claim geloofde, accepteert “het stond in het contract” niet als antwoord wanneer toetsen mogelijk was.
Er is ook een praktische reden. Een claim is meestal ooit waar geweest, op de dag van de inrichting. Daarna zijn er koppelingen bijgekomen, uitzonderingen gemaakt en tijdelijke toegangen nooit opgeruimd. De leverancier liegt zelden; omgevingen leven. De echte vraag is of de werkelijkheid nog klopt met het ontwerp van destijds.
De drie claims die je als eerste toetst
“Het staat geïsoleerd.” De klassieker: een kritisch systeem in een eigen netwerksegment. De test is simpel te formuleren: kan iemand die op het gewone kantoornetwerk staat bij dat systeem komen? Een interne pentest beantwoordt dat in dagen, en het antwoord is verrassend vaak ja, via een vergeten koppeling, een beheerstation dat in beide netwerken hangt of een uitzondering die tijdelijk zou zijn.
“Onze beheerde dienst is veilig.” Wie beheer uitbesteedt, krijgt de beveiliging van de beheerder erbij, in beide richtingen. Laat de dienst zelf toetsen: de toegangspaden van de beheerder, de scheiding tussen klanten, de plek waar jouw gegevens staan. Serieuze beheerpartijen laten dit periodiek zelf testen; vraag om dat rapport, en toets zelf wat jouw specifieke inrichting ervan gebruikt.
“De back-up is onaantastbaar.” De belangrijkste claim van allemaal, want hij is je laatste redding bij ransomware. De test: kan iemand met gestolen beheerrechten de back-ups bereiken, wijzigen of verwijderen? Als het antwoord ja is, heb je geen back-upstrategie maar een kopie die meegaat in het incident.
Welke testvorm hierbij past staat in pentest, vulnerability scan of red teaming, en hoe je de afbakening kiest bij je pentestscope bepalen.
Zo voer je het gesprek met je leverancier
Kondig de test aan en betrek de leverancier in de scope. Dat is contractuele noodzaak: testen zonder toestemming kan wanprestatie opleveren, en je wilt dat de leverancier meewerkt bij het herstel van wat er wordt gevonden. Leg het testrecht bij voorkeur vast in het contract; wat daar verder in hoort staat bij wat je in leverancierscontracten vastlegt.
De toon maakt het verschil. Niet “wij vertrouwen jullie niet”, maar “wij moeten dit aantoonbaar maken, ook voor onszelf”. Een volwassen leverancier herkent die vraag, want hij krijgt hem vaker. En een leverancier die pertinent weigert of alleen onder onwerkbare voorwaarden meewerkt, geeft je informatie die je op geen andere manier had gekregen; weeg die mee bij het risicoassessment van leveranciers.
En als de claim sneuvelt: behandel het als een gewone bevinding. Eigenaar, deadline, herstel, en daarna een hertest om vast te stellen dat het gat echt dicht is. De relatie met een leverancier die één keer door een test is gezakt en het heeft hersteld, is sterker dan die met een leverancier die nooit is getoetst.
Veelgestelde vragen over leveranciersclaims testen
Mag ik de omgeving van mijn leverancier zomaar laten pentesten?
Nee, niet zonder afspraak. Testen raakt systemen die de leverancier beheert, en soms ook andere klanten. Kondig de test aan, stem de scope af en leg het testrecht vast in het contract, dan is het bij de volgende ronde vanzelfsprekend.
Mijn leverancier heeft al een certificaat. Is testen dan nog nodig?
Een certificaat toont aan dat het managementsysteem van de leverancier op orde is, niet dat jouw specifieke inrichting klopt. De koppeling tussen jouw omgeving en de zijne, en de uitzonderingen die voor jou zijn gemaakt, vallen buiten zijn certificaat.
Wat als de test de claim bevestigt?
Dan heb je bewijs in plaats van een belofte, en dat bewijs telt bij een audit en een toezichthouder. Een bevestigde claim is geen weggegooid geld; het is het verschil tussen geloven en weten.
Welke claim moet ik het eerst toetsen?
De back-upclaim. Als die niet klopt, faalt je laatste verdediging precies op het moment dat al het andere al is misgegaan. Daarna netwerkisolatie van kritieke systemen, daarna de beheerde diensten met de diepste toegang.
