
Vergelijkingen
Continuïteit van een softwareleverancier toetsen: checklist
Begin met een inventarisatie per applicatie: welk bedrijfsproces stopt als de software uitvalt, welke gegevens erin staan, wie de leverancier is, waar het draait (eigen server, hostingpartij of…
Breng kritische software en afhankelijkheden in kaart
Begin met een inventarisatie per applicatie: welk bedrijfsproces stopt als de software uitvalt, welke gegevens erin staan, wie de leverancier is, waar het draait (eigen server, hostingpartij of cloud) en wie beheertoegang heeft. ICT-leveranciers brengen hiervoor de hele IT-omgeving in kaart en vinken aan waar je niet precies weet hoe iets is geregeld; die witte vlekken zijn de eerste actiepunten. Zolang je niet weet wie een omgeving beheert of waar een back-up staat, kun je de continuïteit niet toetsen.
Ken per applicatie een maximaal aanvaardbare uitvaltijd (RTO) en een maximaal aanvaardbaar gegevensverlies (RPO) toe. Een applicatie waarin medewerkers direct klantorders verwerken, krijgt een andere norm dan een rapportagetool die wekelijks wordt gebruikt. Die normen zijn de meetlat waarmee je later de SLA en de herstelafspraken van de leverancier beoordeelt.
Breng daarna afhankelijkheden in kaart die niet in de applicatielijst staan maar wel de continuïteit bepalen: koppelingen met andere systemen (API's, bestandsuitwisseling), de identiteitsvoorziening waarmee gebruikers inloggen, de hostinglocatie, onderaannemers en subprocessors, en certificaten of licenties met een einddatum. Let op concentratierisico: levert één leverancier of hostingpartij meerdere kritische componenten, dan valt bij die partij meer tegelijk weg dan bij een gespreide omgeving.
Toets de afspraken met de IT-leverancier
Het NCSC stelt vragen beschikbaar als handvat voor goede afspraken over het opzetten en de beveiliging van je IT-omgeving. Gebruik die vragen als checklist in het gesprek met de leverancier, niet als algemene intentieverklaring: de waarde zit in het antwoord per vraag, niet in de vraag zelf.
Werk minimaal deze onderwerpen uit en leg ze schriftelijk vast: een verantwoordelijkheidsmatrix (wie doet wat bij beheer, back-up, herstel en beveiliging), het aanmaken en intrekken van accounts en beheertoegangen, patch- en wijzigingsbeheer, escalatieprocedures met namen en bereikbaarheid buiten kantooruren, meldtermijnen bij incidenten, en de procedure bij beëindiging van het contract. Zonder die matrix ontstaat bij een storing discussie over wie had moeten ingrijpen.
Vraag niet om toezeggingen maar om bewijs. Documentatie van de inrichting en van herstelprocedures, loggegevens van beheertoegang, een actueel overzicht van onderaannemers en de resultaten van de laatste hersteltest zeggen meer over de werkelijke continuïteit dan een belofte in een offerte. Krijg je het bewijs niet, dan is dat zelf een uitkomst van de toets.
Beoordeel SLA en servicelevels op werkbaarheid
Sluit waar mogelijk een Service Level Agreement af met werkbare service levels; dat kan grip geven op de continuïteit van de dienst. Werkbaar betekent concreet genoeg om vast te stellen of de leverancier zich aan de afspraak houdt en om er consequenties aan te verbinden.
Controleer per servicelevel hoe het is gedefinieerd en gemeten. Vraag naar de meetmethode en de meetperiode, wie de meting uitvoert, welke uitsluitingen gelden (gepland onderhoud, storingen buiten de invloedssfeer van de leverancier, storingen in je eigen netwerk) en binnen welke termijn je de rapportage ontvangt. Brede uitsluitingen kunnen een hoge beschikbaarheidstoezegging in de praktijk uithollen.
Zet naast beschikbaarheid ook de herstelafspraken op papier: hoe snel wordt een storing opgepakt, hoe snel is de dienst weer bruikbaar (aansluitend op de RTO die je zelf hebt bepaald), welk supportvenster geldt en wat de reactie- en oplostijden per prioriteit zijn. Leg vast wat er gebeurt als een servicelevel niet wordt gehaald, bijvoorbeeld een escalatieroute en een vorm van compensatie of korting.
Beoordeel contractuele waarborgen voor continuïteit en exit
Breng eerst in kaart wat voor SaaS-dienst je afneemt en hoe die juridisch gekwalificeerd moet worden; de aard van de dienst bepaalt welke bepalingen je nodig hebt. Toets daarna de looptijd en opzegtermijn, of het contract stilzwijgend verlengt, hoe prijzen mogen worden aangepast en of de leverancier de algemene voorwaarden of de functionaliteit eenzijdig mag wijzigen. Een eenzijdig wijzigingsrecht raakt direct je continuïteit als functionaliteit verdwijnt of de prijs onbeheersbaar stijgt.
Regel dataportabiliteit expliciet: in welk formaat krijg je je gegevens terug, hoe vaak mag je een export opvragen, welke kosten rekenen leveranciers daarvoor, en hoe lang blijven gegevens na beëindiging beschikbaar voordat ze worden verwijderd. Leg ook vast welke medewerking je bij het vertrek krijgt, van wie en binnen welke termijn. Voor software die op eigen servers draait of sterk is toegespitst op jouw processen, is het daarnaast verstandig te vragen naar een regeling waarmee je bij wegvallen van de leverancier toegang houdt tot de broncode of de documentatie.
Beoordeel wat er gebeurt bij overname, fusie of faillissement van de leverancier: blijft de dienst draaien, gaan contracten over op de koper, en welke opzegrechten krijg je in dat geval? Kijk tot slot naar de aansprakelijkheidsclausule en naar een verzekering voor beroepsaansprakelijkheid of cyberrisico's, zodat duidelijk is welke schade bij de leverancier ligt en welke bij jou.
Toets beveiligingsafspraken en veiligheidseisen
Klanten stellen veiligheidseisen aan SaaS-leveranciers en verwachten dat die aantoonbaar worden ingevuld. Vraag de leverancier om actueel bewijs: een beveiligingscertificering, een assurance-rapport van een onafhankelijke accountant of een recente penetratietest, en om een beschrijving van het kwetsbaarheids- en patchproces. Een certificaat zegt iets over het proces van de leverancier; het vervangt niet de vraag welke maatregelen specifiek voor jouw omgeving gelden.
Maak incidentmelding concreet: binnen welke termijn meldt de leverancier een beveiligingsincident, wat staat er minimaal in de melding (aard, impact, getroffen gegevens, genomen maatregelen), wie doet het forensisch onderzoek en wie betaalt dat, en welke informatie krijg je zonder dat je er zelf om hoeft te vragen. Leg ook vast welke logging jij zelf mag inzien en hoe lang bewaartermijnen lopen.
Regel de toegang van leveranciersmedewerkers tot jouw gegevens en systemen: wie mag inloggen, met welke rechten, is er logging van die toegang, geldt een vier-ogenprincipe voor gevoelige handelingen en hoe snel wordt toegang ingetrokken als een medewerker vertrekt? Vraag daarnaast naar de lijst van onderaannemers en subprocessors, de locaties waar gegevens worden opgeslagen en verwerkt, en de afspraken die met hen zijn gemaakt — jouw continuïteit en gegevensbescherming hangen mede van hen af.
Plan overstap of vertrek vooraf
Overstappen van leverancier of ICT-beheerder vraagt ook iets van je eigen organisatie. Werk vooraf een overdrachtslijst uit met alles wat de nieuwe partij nodig heeft: gegevens en exports in een bruikbaar formaat, documentatie van de inrichting en van koppelingen, licenties en contracten, accounts en beheertoegangen, domeinnamen, certificaten en sleutels, en een actuele lijst van contactpersonen bij leveranciers.
Leg in het contract vast wie bij een vertrek welke medewerking levert, binnen welke termijn en tegen welke kosten, en maak die afspraken op het moment dat je nog kunt onderhandelen — niet pas wanneer je hebt opgezegd. Test de overdracht voordat je die nodig hebt: vraag een voorbeeldexport op en kijk of je de gegevens zelf kunt openen en gebruiken. Een export die je niet kunt inlezen in een ander systeem is geen echte exitmogelijkheid.
Houd bij een overstap rekening met overlap: beide omgevingen moeten enige tijd naast elkaar kunnen draaien om gegevens over te zetten en gebruikers te laten wennen. Bepaal vooraf wie binnen je organisatie de trekker is, welke processen tijdelijk anders verlopen en hoe je gebruikers informeert, zodat de overstap niet stil komt te liggen naast het dagelijkse werk.
Maak continuïteit periodiek meetbaar
Zonder meting blijft de continuïteitstoets een momentopname. Spreek af hoe je incidenten, gemiste servicelevels en afhankelijkheden volgt en bespreek ze in een vast overleg met de leverancier. Gebruik daarvoor de SLA-rapportage naast je eigen waarneming: hoe vaak was de dienst niet beschikbaar, hoe lang duurde het herstel, en hoeveel meldingen bleven boven de afgesproken reactietijd.
Houd een eigen incidentenregister bij met datum, duur, oorzaak, impact op processen en de reactie van de leverancier. Dat register maakt patronen zichtbaar die losse meldingen niet laten zien, en het is het beste onderhandelmateriaal bij de volgende contractbespreking of bij de keuze voor een andere leverancier.
Volg wijzigingen aan de leverancierskant actief: nieuwe releases, functionaliteit die verdwijnt, het einde van support op een versie, en wijzigingen in de lijst van onderaannemers. Neem de risico-inventarisatie uit de eerste stap minimaal jaarlijks door en vul aan waar je nog niet precies weet hoe iets is geregeld; die openstaande punten vormen samen je actielijst.
Weeg sectorale en Europese kaders mee waar die gelden
Europese richtlijnen kunnen direct van invloed zijn op de continuïteit van je organisatie, en in de zorg speelt daarbij dat de veiligheid van bedrijfs- en persoonsgegevens aantoonbaar op orde moet zijn. Bepaal daarom eerst welke kaders voor jouw sector gelden en vertaal die naar vragen aan de softwareleverancier, in plaats van ze als een apart dossier naast je leveranciersmanagement te behandelen.
Voor organisaties die met DORA te maken hebben, draait DORA-naleving om digitale weerbaarheid tegen ICT-risico's; er bestaan gepubliceerde checklists om de naleving daarop te toetsen. Vertaal die aandachtspunten naar concrete vragen: ondersteunt de leverancier een functie die voor jou kritiek is, welke continuïteits- en herstelafspraken horen daarbij, welke informatie mag en moet de leverancier aanleveren, en welke exitstrategie is er als de dienst wegvalt of de leverancier niet meer aan de eisen voldoet?
Verwerk de uitkomsten van die toets in je contract en in je leveranciersregister, met per leverancier de geldende kaders, de kritieke functies, de afgesproken herstel- en meldtermijnen en de datum waarop je de toets opnieuw uitvoert. Neem de uitkomsten door met de leverancier en leg vast wie binnen je organisatie de openstaande punten opvolgt.
Statistieken: Europese richtlijnen en hun impact op continuïteit
- DORA-naleving
- Verplicht voor financiële instellingen in de EU; focust op digitale weerbaarheid.
- NCSC-richtlijnen
- Gids voor veilig uitbesteden van ICT-diensten in Nederland.
- Zorgsector en AVG
- Gegevensbescherming en continuïteit moeten aantoonbaar zijn.



