“Onze IT is uitbesteed, dus dit ligt bij de leverancier.”
Daar zit voor mij meteen een belangrijk risico.
De uitvoering kan bij de leverancier liggen. De gevolgen van uitval, dataverlies of een beveiligingsincident liggen uiteindelijk bij jouw organisatie.
Daarom wil je kritieke IT-leveranciers niet alleen beoordelen op prijs, service en tevredenheid.
Je wilt weten of je voldoende zekerheid hebt over beveiliging, continuïteit en herstel.
Stap 1: bepaal eerst of de leverancier werkelijk kritiek is
Vraag:
- valt een essentieel proces stil zonder deze partij;
- verwerkt de leverancier gevoelige gegevens;
- heeft hij beheerrechten;
- is overstappen moeilijk;
- is herstel sterk afhankelijk van deze partij;
- gebruikt de partij kritieke onderaannemers.
Hoe meer “ja”, hoe zwaarder de beoordeling.
Stap 2: begrijp de dienst en verantwoordelijkheidsgrens
Dit klinkt eenvoudig, maar hier gaat het vaak al mis.
Leg vast:
- wat de leverancier beheert;
- wat de organisatie zelf beheert;
- wie verantwoordelijk is voor accounts;
- wie patcht;
- wie monitort;
- wie back-up verzorgt;
- wie incidenten detecteert;
- wie herstel uitvoert.
Een onduidelijke grens leidt tijdens incidenten vrijwel altijd tot vertraging.
Stap 3: vraag naar concrete beveiligingsmaatregelen
Ik zou niet alleen vragen:
“Zijn jullie ISO 27001-gecertificeerd?”
Vraag ook:
- valt onze dienst binnen de scope;
- hoe is beheerderstoegang beveiligd;
- wordt MFA verplicht;
- hoe worden kwetsbaarheden beheerd;
- hoe wordt logging gemonitord;
- hoe worden medewerkers gescreend waar relevant;
- hoe wordt onze data gescheiden;
- hoe worden wijzigingen beheerst.
Het antwoord “we volgen best practices” is voor mij te vaag.
Stap 4: vraag om bewijs
Bewijs kan bestaan uit:
- ISO 27001-certificering;
- SOC/ISAE-rapport;
- auditrapport;
- penetratietest;
- kwetsbaarheidsrapportage;
- restore-test;
- SLA-rapportage;
- incidentstatistieken;
- controlverklaring.
Beoordeel niet alleen of een document bestaat.
Kijk naar:
- scope;
- datum;
- uitzonderingen;
- relevante bevindingen.
Stap 5: beoordeel continuïteit
Vraag:
- wat is de afgesproken beschikbaarheid;
- welke RTO en RPO gelden;
- wanneer is herstel getest;
- welke afhankelijkheden bestaan;
- wat gebeurt bij ransomware;
- hoe snel kan de dienst elders worden hersteld;
- welke capaciteit is beschikbaar bij een groot incident.
Een SLA van 99,9% zegt niets over de kwaliteit van herstel na een complexe cyberaanval.
Stap 6: beoordeel incidentmanagement
Leg vooraf vast:
- binnen welke termijn incidenten worden gemeld;
- wie contactpersoon is;
- welke informatie je ontvangt;
- hoe vaak updates komen;
- wie forensisch onderzoek uitvoert;
- hoe data veiliggesteld wordt;
- wie wettelijke meldingen ondersteunt.
Vraag ook naar een recent incident of oefening.
Niet om de leverancier af te rekenen, maar om te zien hoe het proces werkelijk werkt.
Stap 7: kijk naar beheerderstoegang
Externe beheerders hebben vaak zeer ruime rechten.
Controleer:
- individuele accounts;
- MFA;
- privileged access;
- logging;
- tijdelijke rechten;
- periodieke reviews;
- offboarding;
- onderaannemers.
Een gedeeld administratoraccount zou voor mij direct aanleiding zijn om door te vragen.
Stap 8: kijk naar de leveranciersketen
Vraag welke onderaannemers essentieel zijn.
Bijvoorbeeld:
- cloudprovider;
- datacenter;
- supportpartner;
- authenticatiedienst;
- back-upprovider.
Je wilt weten waar concentratierisico zit en welke wijzigingen gemeld worden.
Stap 9: beoordeel contract en SLA inhoudelijk
Ik zou minimaal willen zien dat afspraken bestaan over:
- beveiliging;
- toegang;
- incidentmelding;
- logging;
- back-up;
- herstel;
- auditrecht;
- assurance;
- onderaannemers;
- data-eigendom;
- exit;
- verwijdering van data.
Contractuele tekst is geen garantie, maar wel een belangrijk sturingsmiddel.
Stap 10: test de exitvraag
Stel:
“Als we binnen drie maanden weg moeten, wat hebben we nodig?”
Kijk naar:
- exportformaten;
- documentatie;
- configuraties;
- data;
- accounts;
- overdracht;
- kosten;
- afhankelijkheid van intellectueel eigendom;
- escrow waar relevant.
Een moeilijk vertrek vergroot leveranciersrisico.
Hoe beoordeel je de antwoorden?
Ik zou per onderwerp niet alleen een score geven.
Noteer:
- risico;
- bewijs;
- openstaande onzekerheid;
- eigenaar;
- vervolgactie.
Bijvoorbeeld:
| Onderwerp | Status | Bewijs | Open punt |
|---|---|---|---|
| MFA beheeraccounts | Groen | Configuratie + auditrapport | Geen |
| Restore | Oranje | Back-uprapportage | Geen recente volledige restore-test |
| Incidentmelding | Oranje | Contract | Geen duidelijke eerste meldtermijn |
| Exit | Rood | Geen | Export en overdracht niet uitgewerkt |
Dat geeft veel meer grip dan één leverancierscijfer.
Welke vragen stelt een CFO?
Voor finance zou ik vooral kijken naar:
- continuïteitsimpact;
- concentratierisico;
- financiële gezondheid;
- exitkosten;
- aansprakelijkheidslimieten;
- verzekeringen;
- herstelkosten.
Welke vragen stelt een CIO of IT-manager?
Daar ligt de nadruk op:
- technische controls;
- beheerrechten;
- integraties;
- logging;
- patching;
- monitoring;
- herstel;
- change management.
Welke vragen stelt bestuur of toezicht?
Die hoeven niet ieder controlrapport te lezen.
Ik zou willen weten:
- welke leveranciers kritiek zijn;
- waar belangrijk bewijs ontbreekt;
- waar de grootste restrisico's zitten;
- welke acties achterlopen;
- welke partij de organisatie disproportioneel afhankelijk maakt.
Dat is bestuurbare informatie.
Mijn belangrijkste leveranciersvraag
Als ik één vraag moest kiezen, dan is het:
“Welk bewijs hebben we dat deze leverancier onze kritieke afhankelijkheid daadwerkelijk beheerst?”
Daarmee ga je vanzelf voorbij aan verkoopbrochures en algemene certificeringen.
Voor een bredere aanpak van leveranciersrisico, lees ook:
Third-party risk management: hoe houd je grip op digitale leveranciersrisico's?
Passende vervolgstap
Van inzicht naar gerichte verbetering
Wil je onafhankelijk vaststellen waar de belangrijkste risico’s en verbeterpunten liggen? Kynexis helpt om de vraag scherp te formuleren en de uitkomst bestuurlijk en praktisch bruikbaar te maken.
Bekijk Risicoanalyse informatiebeveiliging →

