Steeds meer organisaties leunen volledig op externe IT-diensten. Tegelijk neemt de druk toe om aan wet- en normeisen te voldoen, ook zonder eigen IT-team.

Leveranciers beloven veel, maar leveren zelden transparantie zonder dat daar iets tegenover staat. Juist kleine organisaties hebben daardoor een blinde vlek voor risico’s waar ze wel verantwoordelijk voor zijn.

De vraag is niet óf iets goed geregeld is, maar hoe je zeker weet dát het geregeld is.

1. Klein maar wel verantwoordelijk

De verplichting tot informatiebeveiliging geldt voor elke organisatie, ongeacht omvang of sector.

Kleine organisaties worden steeds vaker geconfronteerd met eisen uit contracten, wetgeving of normenkaders zoals ISO 27001 en NEN 7510. Veel daarvan draaien om het beschermen van informatie, het beheersen van risico’s en het tonen van aantoonbaar beleid.

Informatiebeveiliging lijkt daardoor complex, duur en vooral iets voor grote instellingen met gespecialiseerde afdelingen. Maar die aanname is onjuist.

In de kern is informatiebeveiliging niets anders dan het bewust omgaan met kwetsbare informatie in de context van de activiteiten die een organisatie uitvoert.

Dit vraagt geen omvangrijke structuren, maar wel bewuste keuzes.

Zeker voor organisaties die afhankelijk zijn van IT-leveranciers, cloudomgevingen en digitale dossiers is het geen optie om het onderwerp links te laten liggen.

Misvattingen over schaalgrootte en verantwoordelijkheid

De gedachte dat kleine organisaties buiten schot blijven, leeft breed. Dat is logisch: beperkte capaciteit, geen aparte IT-afdeling, en informele werkstructuren maken het idee aantrekkelijk dat strengere eisen “voor anderen” zijn bedoeld. In werkelijkheid zijn veel verplichtingen onafhankelijk van schaalgrootte:

• De AVG maakt geen onderscheid tussen eenmanszaken of zorginstellingen van 500 medewerkers.
• Klanten, partners en toezichthouders verwachten basale waarborgen, ook bij uitbestede processen.
• De risico’s van gegevensverlies of een digitale storing kunnen voor een kleine organisatie relatief veel grotere gevolgen hebben.

Verantwoordelijkheid kan niet gedelegeerd worden door iets uit te besteden. Juridisch blijft de organisatie zelf eindverantwoordelijk voor gegevensverwerking, ook als een externe partij dit uitvoert.

Risicodenken in plaats van structuurdenken

Veel standaarden zijn risicogebaseerd opgebouwd. Dat betekent dat niet de organisatievorm of personeelsgrootte bepalend is, maar het soort informatie dat verwerkt wordt en de mogelijke gevolgen bij een incident. Het hebben van weinig medewerkers is geen vrijstelling, en ook niet nodig als excuus.

Een klein team kan wél:

• Inzicht krijgen in welke informatie zij gebruiken en opslaan
• Reflecteren op wat mis zou kunnen gaan
• Kijken naar afhankelijkheden van leveranciers en digitale processen
• Beoordelen welke minimale maatregelen daarbij passen

Zo ontstaat een aanpak die niet gebaseerd is op een checklist, maar op redeneren vanuit kwetsbaarheid en impact.

Verplichtingen zonder complexiteit

Er zijn verplichtingen, maar niet alle maatregelen hoeven ingewikkeld te zijn. Veel eisen kunnen relatief eenvoudig worden nageleefd wanneer de basis op orde is. Denk aan:

• Beleid: op papier zetten hoe wordt omgegaan met informatie, rollen en verantwoordelijkheden
• Bewustwording: zorgen dat medewerkers weten waar ze op moeten letten
• Controle: periodiek nagaan of processen nog werken zoals bedoeld
• Documentatie: keuzes vastleggen, ook als iets niet gedaan wordt, maar bewust is afgewogen

Er wordt vaak gedacht dat aan alles voldaan moet worden. In werkelijkheid draait het om onderbouwde keuzes. Een afweging is geen zwakte, maar een kern van verantwoording.

Complexiteit vermijden door focus

Organisaties die alles tegelijk willen regelen, raken snel het overzicht kwijt. Een gerichte focus helpt om het onderwerp behapbaar te houden.

Informatiebeveiliging hoeft niet breed en technisch ingestoken te worden, zolang er een paar hoofdvragen worden beantwoord:

• Welke informatie is belangrijk voor de organisatie?
• Waar wordt die informatie verwerkt en opgeslagen?
• Wat kan er misgaan als die informatie weg is, gelekt wordt of niet beschikbaar is?
• Welke stappen zijn nu al genomen om dat risico te beperken?

Als deze vragen regelmatig worden besproken en de antwoorden worden bijgehouden, is er al sprake van gestructureerde risicobeheersing.

Onderschatting van impact bij kleine organisaties

De impact van incidenten wordt in kleine organisaties vaak onderschat. Dat komt doordat men de kans kleiner acht, of vertrouwt op de leveranciers. Maar juist kleine bedrijven of instellingen hebben minder veerkracht bij uitval of dataverlies.

Herstelmogelijkheden zijn beperkter, juridische kosten relatief hoog en reputatieschade vaak desastreus.

Voorbeelden van vaak genegeerde risico’s:

• Geen inzicht in of controle over back-ups van kritieke systemen
• Geen afspraken met leveranciers over reactietijden of verantwoordelijkheden
• Onvoldoende toegangsbeheer, waardoor informatie onbedoeld gedeeld wordt
• Gebrek aan logging of monitoring, waardoor incidenten niet worden opgemerkt

Deze risico’s vereisen geen geavanceerde technische controles, maar wel overzicht, bewustzijn en coördinatie.

De rol van leveranciers en uitbestede diensten

Veel kleinere organisaties werken volledig via externe IT-partijen. Werkplekken, e-mail, cliëntsystemen of administratie: alles loopt via cloudsoftware of dienstverleners. Dat is op zich geen probleem, zolang duidelijk is:

• Wat de leverancier wel en niet doet
• Wat er overeengekomen is over beveiliging
• Wat de organisatie zelf nog moet controleren of borgen

Het risico zit niet in het uitbesteden zelf, maar in het ontbreken van inzicht en grip.

Belang van basisafspraken en documentatie

Zonder basisdocumentatie is het lastig om aan te tonen wat er gedaan is. Veel eisen uit wetgeving en normen gaan niet over perfecte beveiliging, maar over aantoonbaar beleid.

Kleine organisaties kunnen daar als volgt mee starten:

• Een informatiebeveiligingsbeleid opstellen van maximaal 2 pagina’s
• Rollen en verantwoordelijkheden benoemen, ook als die tijdelijk extern belegd zijn
• Een eenvoudig risico-overzicht maken met scenario’s die relevant zijn
• Leveranciersdocumentatie verzamelen en afspraken vastleggen
• Een register bijhouden van incidenten, ook kleine

Geen enkel document hoeft complex te zijn. Wel moet het up-to-date, toepasbaar en onderbouwd zijn. Zo ontstaat structuur die werkt in de praktijk.

Redelijkheid als uitgangspunt, niet als excuus

Veel organisaties vinden informatiebeveiliging ‘niet redelijk’ als het teveel kost of teveel kennis vraagt. De normen zijn echter opgebouwd vanuit proportionaliteit. Het gaat niet om maximale beveiliging, maar om passende maatregelen. Het excuus dat iets niet redelijk is, vervalt zodra een incident aantoont dat er geen alternatief was.

De volgende benadering helpt om redelijkheid om te zetten in uitvoering:

• Eerst risico’s in kaart brengen
• Dan nagaan wat daarvan de gevolgen zijn
• Vervolgens passende, haalbare maatregelen kiezen
• Ten slotte beslissingen vastleggen en regelmatig herzien

Hierdoor ontstaat een logische, verdedigbare aanpak, ook voor externe toezichthouders of certificerende instellingen.

2. Verantwoordelijkheid stopt niet bij uitbesteden

Organisaties die IT uitbesteden, blijven eindverantwoordelijk voor de informatiebeveiliging van hun processen. Dat verandert niet door het inschakelen van leveranciers, ongeacht hun omvang, expertise of certificeringen.

Toch is het in de praktijk gebruikelijk dat die verantwoordelijkheid verschuift naar de achtergrond zodra er een externe partij bij betrokken is. Niet vanuit onwil, maar vaak uit onwetendheid of gemak. Dat leidt tot onduidelijkheid, valse zekerheid en risico’s die niemand actief beheert.

Zodra kritieke processen of informatiestromen buiten de organisatie worden geplaatst, ontstaat een afhankelijkheid. De illusie dat hiermee ook de verplichtingen verdwijnen, is wijdverspreid, maar niet houdbaar.

Verantwoordelijkheid blijft juridisch en organisatorisch intern

In vrijwel alle wet- en regelgeving, inclusief de AVG en zorgspecifieke normen zoals NEN 7510, geldt het principe dat de uitbestedende partij verantwoordelijk blijft voor wat er met gegevens of processen gebeurt.

Leveranciers zijn uitvoerend, ondersteunend of faciliterend.

Zij nemen geen juridische verplichtingen over, tenzij dit expliciet contractueel is vastgelegd én effectief wordt gemonitord.

Enkele voorbeelden waar verantwoordelijkheid altijd intern blijft:

• Beveiliging van persoonsgegevens die via een SaaS-leverancier worden verwerkt
• Beschikbaarheid van cliëntgegevens in geval van een storing bij een cloudpartij
• Beheer van toegangsrechten, ook als dit technisch is uitbesteed
• Inzicht in audittrails, logging of incidentenrapportages van leveranciers

Het vertrouwen dat een leverancier “alles goed regelt” is geen vervanging voor een structurele beheersing.

Certificeringen zijn geen contract

Veel leveranciers pronken met ISO 27001-certificaten, ISAE-rapportages of andere verklaringen. Hoewel dit kan bijdragen aan vertrouwen, zijn het geen garanties. Deze documenten bieden beperkt zicht op:

• De concrete dienstverlening aan de organisatie zelf
• De effectiviteit van de beveiligingsmaatregelen in de praktijk
• De relevantie van het certificaat voor de gebruikte dienst of omgeving
• De scope van het certificaat (wat valt er wel en niet onder?)

Een certificering is slechts één datapunt. Zonder aanvullende afspraken zegt het weinig over de mate waarin de leverancier werkelijk past binnen het beveiligingsbeleid van de organisatie.

Contractuele afspraken als fundament

Wat wél werkt, is vooraf duidelijke afspraken maken. Contractuele eisen vormen de basis voor wat later gemonitord of beoordeeld kan worden. Zonder zulke afspraken ontstaat direct een zwakke plek in de keten. Veel organisaties vergeten dit, of nemen algemene clausules op zonder ze te concretiseren.

Praktische aandachtspunten bij het vastleggen van afspraken:

• Benoem expliciet welke beveiligingseisen gelden (bijv. versleuteling, back-up, logging)
• Leg vast hoe incidenten gemeld moeten worden
• Geef aan welke documentatie de leverancier beschikbaar moet stellen
• Definieer herzieningsmomenten, zoals jaarlijkse reviews of updates
• Neem eisen op die aansluiten bij de eigen risicoanalyse

Afspraken werken alleen als ze vooraf zijn vastgelegd. Achteraf afdwingen is zelden succesvol.

Geen zicht = geen grip

Zodra de operationele kant volledig bij leveranciers ligt, ontbreekt vaak het zicht op wat er daadwerkelijk gebeurt. Daardoor ontstaat er een beheerloos risico: een afhankelijkheid zonder toezicht.

Dit komt veel voor bij organisaties die:

• Geen overzicht hebben van hun leveranciers en welke diensten zij leveren
• Niet weten welke gegevens via welke kanalen worden verwerkt
• Geen vaste momenten hebben om te evalueren of afspraken worden nagekomen
• Geen aanspreekpunt hebben binnen de organisatie voor leveranciersbeheer

Zonder zicht op prestaties en processen is het onmogelijk om effectief te sturen op beveiliging. Dit leidt vaak tot een situatie waarin incidenten niet worden herkend, laat worden ontdekt of verkeerd worden geïnterpreteerd.

Verantwoordelijkheid moet benoemd worden

De gedachte dat “de IT-club het wel regelt” is riskant zolang niemand binnen de organisatie verantwoordelijk is voor het aansturen, beoordelen en controleren van leveranciers. Taken worden impliciet gedeeld of blijven liggen. Dat leidt tot gebrekkige opvolging en gebrek aan regie.

Wat nodig is:

• Iemand binnen de organisatie moet formeel verantwoordelijk zijn voor leveranciersbeheer
• Deze rol hoeft geen technisch expert te zijn, maar moet wel toezicht kunnen organiseren
• Er moet een overzicht bestaan van wie welke leveranciers aanstuurt
• Er moet periodiek overleg plaatsvinden over prestaties, incidenten en verbeterpunten

Zo ontstaat structurele aandacht, ook als de feitelijke uitvoering bij een externe partij ligt.

Misvatting over schaalbaarheid en monitoring

Een veelgehoord bezwaar is dat leveranciersmonitoring niet haalbaar is voor kleine organisaties zonder IT-kennis. Het klopt dat technische audits of diepgaande beoordelingen lastig zijn. Maar dat is geen vrijstelling voor het hebben van grip. Grip hoeft niet te betekenen: alles zelf controleren.

Het betekent wél:

• Weten wat er gevraagd is
• Weten wat er geleverd wordt
• Zien of de afspraken worden nagekomen
• Kunnen aantonen dat hier aandacht aan is besteed

Hiervoor zijn vaak geen technische middelen nodig, maar praktische structuren zoals vragenlijsten, rapportages, overlegmomenten of check-ins.

Wat gebeurt er zonder afspraken?

Als vooraf geen beveiligingsafspraken worden gemaakt, ontstaat een situatie waarin:

• Er geen standaard is om prestaties aan te toetsen
• Incidenten leiden tot discussie over verantwoordelijkheden
• De leverancier niets verkeerd doet volgens contract, maar de organisatie wel schade lijdt
• Externe audits of toezichthouders constateren dat er geen sturing of borging is

Daarmee is duidelijk dat uitbesteden zonder afspraken leidt tot risico’s die bij de uitbestedende partij blijven liggen, zonder mogelijkheid om erop te sturen.

Afhankelijkheid moet beheerst worden

Afhankelijk zijn van leveranciers is niet verkeerd. Het is een logische keuze voor veel organisaties, zeker als het gaat om IT-diensten. Wat wel noodzakelijk is: die afhankelijkheid beheersbaar maken. Dat kan door:

• Leveranciers structureel te selecteren op basis van informatiebeveiliging
• Afspraken over beveiliging standaard op te nemen in inkoopprocedures
• Evaluatie en toezicht onderdeel te maken van het contractmanagement
• De risico’s van uitbesteding te benoemen in de interne risicoanalyse

Zo wordt informatiebeveiliging onderdeel van het reguliere proces, en geen losstaand project.

3. Beheersmaatregel A.5.22 zonder eigen IT-afdeling

Beheersmaatregel A.5.22 uit de ISO 27001, en NEN 7510 normen, stelt dat organisaties leveranciersdiensten moeten monitoren, beoordelen en beheren.

Op papier klinkt dit als een logische stap in het beheersen van risico’s. In de praktijk wringt het. Zeker voor organisaties zonder eigen IT-afdeling, zonder securitykennis, en zonder capaciteit om diepgaand toezicht te houden. Toch blijft de verplichting overeind: uitbesteden betekent niet loslaten.

De vraag is dus niet óf A.5.22 van toepassing is, maar hoe deze beheersmaatregel werkbaar kan worden gemaakt voor organisaties die volledig afhankelijk zijn van externe partijen voor hun IT.

Monitoren is geen technische controle

Veel interpretaties van A.5.22 gaan uit van technische monitoring: logs controleren, systemen auditen, beveiligingsinstellingen verifiëren. Dat veronderstelt diepgaande kennis én toegang tot systemen. Beide ontbreken vaak bij kleine organisaties. Toch is dat geen vereiste. Monitoring kan ook plaatsvinden op niet-technische wijze:

• Periodiek contact met leveranciers over prestaties en afwijkingen
• Evaluaties op basis van overeengekomen serviceniveaus
• Beoordelen van rapportages of complianceverklaringen
• Vastleggen van signalen uit de praktijk, zoals vertragingen of supportproblemen

De kern is niet technisch toezicht, maar aantoonbare betrokkenheid bij de uitvoering van uitbestede processen.

Beoordelen vraagt om context, niet om tools

Een beoordeling is geen checklist. Het vraagt om inzicht in wat afgesproken is, wat daadwerkelijk gebeurt, en of dit past bij de risico’s van de organisatie. Zelfs zonder IT-tools of audits kan deze beoordeling plaatsvinden:

• Is de beschikbaarheid van diensten in lijn met wat nodig is voor de bedrijfsvoering?
• Zijn er meldingen geweest van incidenten of beveiligingsproblemen?
• Is de dienstverlening consistent met het beveiligingsniveau dat in contracten of SLA’s staat?
• Past het gedrag van de leverancier bij de verwachtingen op het gebied van informatiebeveiliging?

Ook hier geldt: geen inhoudelijke controle, maar evaluatie op hoofdlijnen binnen de kaders van de dienstverlening.

Grip zonder controle is mogelijk

Grip op leveranciers betekent niet dat alles gecontroleerd moet worden. Het betekent weten wat geleverd wordt, wanneer, onder welke voorwaarden, en wat de impact is als het misgaat. Grip ontstaat door:

• Duidelijke afspraken vooraf (zoals besproken in het vorige hoofdstuk)
• Regelmatig toetsen of deze afspraken nageleefd worden
• Vragen stellen wanneer iets afwijkt of onduidelijk is
• Het vastleggen van deze inspanningen in een eenvoudig monitoringsverslag

Veel organisaties realiseren zich niet dat alleen al het formeel vastleggen van dit proces de beheersmaatregel A.5.22 aanzienlijk versterkt.

Externe expertise slim inzetten

Voor éénmalige beoordelingen, leveranciersselectie of beoordeling van certificeringsverklaringen kan externe expertise worden ingehuurd. Niet als permanente oplossing, maar als aanvulling op het interne proces. Externe ondersteuning is vooral waardevol bij:

• Initiële beoordeling van een nieuwe leverancier
• Hulp bij het beoordelen van de reikwijdte van certificeringen
• Interpretatie van incidentrapportages of technische documentatie
• Vertaling van complexe risico’s naar praktische maatregelen

Zo blijft de regie bij de organisatie zelf, terwijl specifieke kennis tijdelijk kan worden aangehaakt.

Vertrouwen is geen maatregel

In de praktijk wordt A.5.22 vaak teruggebracht tot vertrouwen in de leverancier. “Ze zijn ISO-gecertificeerd” of “ze leveren al jaren goed werk” zijn veelgehoorde argumenten. Vertrouwen is een startpunt, maar geen beheersmaatregel. Zonder toetsing is er geen sprake van controle. En zonder controle kan er geen onderbouwing worden gegeven bij audits of incidentonderzoek.

Vertrouwen mag onderdeel zijn van de relatie, maar moet onderbouwd worden door:

• Documentatie die laat zien dat afspraken nageleefd worden
• Periodieke reflectie op prestaties
• Vragenlijsten of reviews die terugkoppeling opleveren
• Gesprekken waarin afwijkingen of zorgen worden besproken

Zonder deze elementen blijft vertrouwen een aanname in plaats van een onderbouwd oordeel.

Eenvoudige instrumenten voor kleine organisaties

Voor organisaties zonder IT-specialisten is het belangrijk om de beheersmaatregel te vertalen naar uitvoerbare middelen. Dat hoeft geen systeem of platform te zijn. De volgende middelen zijn vaak al voldoende:

• Een overzicht van alle leveranciers en hun rol in de dienstverlening
• Een vast format voor periodieke evaluatie (max. 1 pagina per leverancier)
• Een korte vragenlijst die jaarlijks wordt herhaald
• Een gespreksverslag per overlegmoment
• Aantekeningen van afwijkingen of klachten

Deze documenten zijn eenvoudig te beheren en vormen samen een aantoonbaar monitoringsproces.

De betekenis van toezicht verschilt per leverancier

Niet elke leverancier vraagt dezelfde mate van aandacht. Het type dienst, het risico, en de afhankelijkheid bepalen de zwaarte van het toezicht. Organisaties zonder IT-afdeling doen er goed aan dit te formaliseren:

• Leveranciers van generieke diensten (bijv. telefonie of schoonmaak): licht toezicht
• Leveranciers van IT-platforms: jaarlijks toetsen van afspraken
• Leveranciers die persoonsgegevens verwerken: frequent overleg en rapportages
• Leveranciers die back-ups of infrastructuur beheren: expliciete toetsmomenten

Door te prioriteren, ontstaat een realistische verdeling van aandacht en capaciteit.

Geen toezicht zonder contractbasis

De implementatierichtlijn bij A.5.22 noemt als doel “het overeengekomen niveau van informatiebeveiliging handhaven.” Zonder afspraken is er niets overeengekomen. De meeste leveranciers zullen geen extra informatie aanleveren of verantwoording afleggen zonder dat dit vooraf contractueel is vastgelegd.

Zodra het contract zwak is:

• Is er geen grond om informatie op te vragen
• Kan een leverancier weigeren mee te werken aan evaluaties
• Ontstaat er discussie over verantwoordelijkheden bij incidenten
• Wordt toezicht een gunst in plaats van een recht

Daarom begint toezicht niet bij monitoring, maar bij de inhoud van de overeenkomst.

Monitoring als vast onderdeel van operationeel beheer

Zodra monitoring een losstaand proces blijft, verdwijnt het van de radar. Het moet onderdeel zijn van bestaande routines, bijvoorbeeld:

• Onderdeel van kwartaalgesprekken met leveranciers
• Verplicht agendapunt in managementoverleggen
• Vast onderdeel van contractverlenging of leverancierskeuze
• Geborgd in interne processen voor kwaliteit, compliance of privacy

Als deze momenten structureel benut worden, is monitoring geen extra last, maar onderdeel van regulier beheer.

4. Begin bij goede afspraken

Effectief leveranciersbeheer begint niet bij monitoring, maar bij het vastleggen van duidelijke afspraken.

Zonder heldere contractuele basis is er niets om te toetsen, geen kader om op terug te vallen bij incidenten, en geen mandaat om informatie op te vragen. Organisaties die informatiebeveiliging serieus nemen, starten daarom met een fundamentele stap: het opnemen van expliciete beveiligingseisen in contracten en overeenkomsten.

Veel kleinere organisaties laten deze stap liggen, vanuit gemak of onwetendheid. Standaardoffertes worden geaccepteerd, SLA’s blijven beperkt tot uptime-percentages, en beveiliging wordt afgedaan met een verwijzing naar een certificaat. Dat is onvoldoende.

Zonder goede afspraken kunnen risico’s niet beheerst worden en is de organisatie kwetsbaar in de keten.

Contractuele eisen vormen het fundament

Beheersmaatregelen zoals A.5.22 krijgen pas betekenis wanneer er vooraf vastligt wat verwacht wordt. Een leverancier kan pas beoordeeld worden op naleving, als er iets overeengekomen is om na te leven. Dit vraagt om contractuele bepalingen die meer doen dan algemeenheden benoemen.

Concrete elementen die vastgelegd moeten worden:

• Welke informatie door de leverancier verwerkt of beheerd wordt
• Welke beveiligingsmaatregelen verplicht zijn (bijv. versleuteling, toegangsbeheer, logging)
• Hoe incidenten worden gemeld, binnen welke termijnen en aan wie
• Welke rapportages of bewijzen jaarlijks geleverd moeten worden
• Welke normen of certificeringen relevant zijn, inclusief scope en actualiteit
• Welke toetsmomenten er zijn tijdens de looptijd van het contract

Zonder deze onderdelen ontstaat een scheve verhouding waarin de leverancier volledige controle heeft en de opdrachtgever geen instrumenten heeft om te sturen.

Standaardclausules zijn zelden toereikend

Leveranciers gebruiken vaak eigen standaardcontracten of SLA’s. Deze documenten zijn meestal juridisch correct, maar zelden specifiek op informatiebeveiliging afgestemd. Algemene formuleringen als “wij voldoen aan de geldende wet- en regelgeving” zijn ontoereikend.

Een contract moet duidelijk maken:

• Welke normenkaders van toepassing zijn op de dienstverlening
• Wat het gevolg is als niet aan deze eisen voldaan wordt
• Welke rechten de opdrachtgever heeft om informatie op te vragen of te controleren
• Of subverwerkers worden ingezet, en onder welke voorwaarden

Afwijken van het standaardcontract is vaak mogelijk, mits dit vooraf besproken wordt. Veel leveranciers zijn bereid om aanvullende clausules op te nemen, zeker wanneer het gaat om wettelijke verplichtingen of sectorale eisen.

Afspraken vooraf maken voorkomt discussies achteraf

Zodra een incident plaatsvindt, wordt de kwaliteit van de afspraken getest. Als beveiligingseisen ontbreken in het contract, is er niets om op terug te vallen. Leveranciers kunnen weigeren om gegevens te delen, onderzoeken uitstellen, of claimen dat de verantwoordelijkheid bij de opdrachtgever ligt. Dat leidt tot vertraging, schade en juridische onzekerheid.

Goede afspraken helpen bij:

• Snelle opvolging van beveiligingsincidenten
• Duidelijkheid over escalatieprocedures
• Ondersteuning bij audits of toezicht vanuit externe partijen
• Voorkomen van aansprakelijkheidsdiscussies

Vooral in sectoren waar gevoelige gegevens worden verwerkt, zijn preventieve afspraken een voorwaarde om continuïteit en vertrouwen te behouden.

Informele afspraken zijn onvoldoende

Mondelinge afspraken of informele communicatie via e-mail zijn kwetsbaar. Ze zijn niet bindend, niet afdwingbaar en vaak niet te achterhalen als het erop aankomt. Alleen formele, schriftelijke afspraken bieden juridische en operationele houvast.

Informatiebeveiliging vereist:

• Documentatie van gemaakte afspraken
• Bekrachtiging via handtekening of contractuele vastlegging
• Duidelijke verwijzing naar verantwoordelijkheden aan beide zijden

Zodra afspraken formeel zijn vastgelegd, kunnen ze ook periodiek geëvalueerd en aangepast worden.

Leveranciersclassificatie helpt bij prioriteren

Niet elke leverancier vereist dezelfde mate van detail in contracten. Door leveranciers te classificeren op basis van risico, type dienst en informatieverwerking, kan de organisatie bepalen waar strengere eisen nodig zijn.

Mogelijke categorieën:

• Laag risico: algemene leveranciers zonder gegevensverwerking (bijv. hardwareleveranciers)
• Middenrisico: leveranciers met beperkte toegang tot systemen of gegevens (bijv. IT-beheerders)
• Hoog risico: leveranciers die persoonsgegevens, medische dossiers of financiële data verwerken

Hoe hoger het risico, hoe specifieker en strakker de contractuele afspraken moeten zijn.

Verantwoordelijkheden uitschrijven per partij

Afspraken zijn pas effectief als duidelijk is wie wat doet. In veel gevallen is onduidelijk wie de beveiligingsmaatregelen uitvoert, wie verantwoordelijk is voor updates, en wie incidenten afhandelt. Door verantwoordelijkheden expliciet op te nemen, ontstaat overzicht.

Voorbeeld van rolverdeling in contract:

• Leverancier zorgt voor veilige opslag en versleuteling van gegevens
• Opdrachtgever beheert gebruikersaccounts en toegang tot systemen
• Leverancier meldt incidenten binnen 24 uur na ontdekking
• Opdrachtgever bepaalt welke betrokkenen geïnformeerd worden bij een datalek

Deze duidelijkheid voorkomt misverstanden en versnelt de opvolging bij verstoringen.

Aansprakelijkheid

Informatiebeveiliging is geen puur operationele kwestie. De contractuele aansprakelijkheid bij fouten, lekken of uitval moet expliciet geregeld worden. Vaak wordt deze bij de leverancier beperkt of uitgesloten, tenzij anders overeengekomen.

Waar op gelet moet worden:

• Is er een aansprakelijkheidsbeperking opgenomen, en zo ja, tot welk bedrag?
• Wordt aansprakelijkheid uitgesloten bij indirecte schade, zoals reputatieschade of boetes?
• Is er dekking vanuit een cyberverzekering, en hoe sluit die aan bij contractuele afspraken?

Zonder goede afspraken is het lastig om schade te verhalen of kosten te delen.

Templates en standaardvoorwaarden ontwikkelen

Kleine organisaties kunnen veel winnen door te werken met standaardclausules voor informatiebeveiliging. Deze kunnen bij elke inkoopronde worden meegegeven, ongeacht de leverancier. Een set standaardbepalingen bespaart tijd, voorkomt discussie en borgt consistentie.

Elementen van een praktische standaardclausule:

• Verplichting tot melden van datalekken binnen 24 uur
• Minimumeisen voor toegangsbeheer en authenticatie
• Jaarlijkse herbevestiging van certificeringen of rapportages
• Toestemming vooraf bij gebruik van onderaannemers of subverwerkers
• Recht op inzage in beveiligingsmaatregelen of relevante documentatie

Zo’n basis kan aangevuld worden per leverancierstype of dienst, maar voorkomt dat elke inkoopronde opnieuw vanaf nul moet starten.

5. Impact beperken is wél haalbaar

In organisaties zonder eigen IT-afdeling en met uitbestede digitale processen ligt het zwaartepunt van informatiebeveiliging niet bij preventie, maar bij voorbereiding.

De kans op een incident bij een leverancier is reëel, en daar is nauwelijks directe invloed op uit te oefenen. Wat wél volledig onder controle valt, is de manier waarop de organisatie omgaat met de gevolgen.

Impactbeperking is geen technisch vraagstuk, maar een organisatorische verantwoordelijkheid die juist ook voor kleine organisaties uitvoerbaar is.

Wie zich alleen richt op kansbeheersing (en dus op het voorkomen van incidenten) mist het besef dat leveranciersrisico’s in de praktijk grotendeels buiten bereik liggen. De organisatie moet zich daarom richten op het beperken van de schade die ontstaat als het misgaat.

Kansbeheersing ligt extern, impactintern

Leveranciers bepalen zelf hun infrastructuur, processen en beveiligingsmaatregelen. De uitbestedende organisatie heeft zelden of nooit inzicht in de dagelijkse werking van systemen of interne incidenten. Daarmee is de invloed op de kans op fouten of aanvallen zeer beperkt.

Wat daarentegen volledig intern te organiseren is:

• Hoe snel processen hervat kunnen worden bij uitval
• Hoe afhankelijk bepaalde onderdelen zijn van één leverancier
• Welke alternatieven beschikbaar zijn bij onbeschikbaarheid van systemen
• Wat de impact is op dienstverlening bij verschillende storingsscenario’s
• Hoe communicatie plaatsvindt bij een verstoring of lek

Zodra de focus verschuift naar impactbeheersing, ontstaat ruimte voor realistische maatregelen die binnen de eigen organisatie genomen kunnen worden.

Business continuity als praktisch startpunt

Continuïteitsbeheer wordt vaak gezien als iets voor grote bedrijven met crisisplannen en draaiboeken. Maar ook kleine organisaties kunnen dit pragmatisch oppakken. Niet als compliance-instrument, maar als middel om voorbereid te zijn op situaties waarbij de leverancier uitvalt, data tijdelijk onbereikbaar is, of externe systemen niet functioneren.

Een werkbare aanpak bevat:

• Inventarisatie van de processen die niet stil mogen vallen
• Inzicht in de digitale afhankelijkheden per proces
• Beschrijving van alternatieven of tijdelijke werkwijzen bij uitval
• Contactpersonen van leveranciers voor noodsituaties
• Beoordeelbare hersteltijden: hoe lang mag een systeem uit liggen?

Deze basis is geen papieren document, maar een hulpmiddel om te blijven functioneren onder druk.

Herstelstrategieën zonder technische infrastructuur

Herstel gaat niet altijd over het opnieuw opstarten van een systeem. Vaak gaat het om het kunnen voortzetten van werk, communicatie, of zorgverlening terwijl digitale ondersteuning ontbreekt.

Hiervoor zijn herstelstrategieën nodig die niet afhankelijk zijn van technologie:

• Vooraf afdrukken van essentiële informatie of contactgegevens
• Gebruik van alternatieve communicatiekanalen (telefoon, sms, fysieke post)
• Toegang tot papieren dossiers of offline formats
• Procedures om handmatig te registreren en later digitaal bij te werken
• Instructies voor medewerkers bij digitale onbeschikbaarheid

Deze strategieën zijn eenvoudig op te zetten en vragen geen technische kennis.

Leveranciersrisico’s integreren in bestaande processen

Impactbeperking wordt effectiever zodra het een vast onderdeel wordt van normale bedrijfsvoering. Dat betekent niet dat er aparte beleidscycli nodig zijn, maar wel dat risico’s van leveranciers herkenbaar en benoemd moeten worden in:

• Risicoanalyses
• Contractevaluaties
• Beleidsplannen
• Teamoverleggen
• Afspraken met medewerkers

Zo ontstaat bewustzijn over afhankelijkheden én over de maatregelen die paraat moeten staan als systemen falen.

Impactgerichte maatregelen zijn altijd uitvoerbaar

Veel technische beheersmaatregelen zijn voor kleine organisaties moeilijk implementeerbaar. Maar maatregelen die gericht zijn op impactbeperking zijn doorgaans laagdrempelig:

• Uitwijkafspraken maken met een alternatieve leverancier
• Cruciale data periodiek downloaden en veilig lokaal bewaren
• Interne noodprocedures opstellen en oefenen
• Afhankelijkheden in kaart brengen in één visueel overzicht
• Zorgdragen voor gespreide kennis over leveranciers binnen het team

Deze maatregelen vergroten de weerbaarheid zonder dat er technische configuratie nodig is.

Duidelijkheid over eigen verantwoordelijkheden

Bij incidenten ontstaat vaak verwarring: wie doet wat, wanneer, en met welke informatie? Het vooraf benoemen van rollen voorkomt vertraging en improvisatie. Binnen kleine organisaties kan dit kort en bondig vastgelegd worden:

• Wie informeert de leverancier bij een storing?
• Wie beoordeelt de impact op bedrijfsvoering?
• Wie schakelt hulp in of neemt besluiten over alternatieve werkwijzen?
• Wie communiceert met betrokkenen of externe partijen?

Een eenvoudige verantwoordelijkhedenmatrix geeft direct overzicht in crisissituaties.

Toetsing zonder audits of controles

Impactbeperkende maatregelen hoeven niet geaudit te worden om effectief te zijn. Ze kunnen op eenvoudige wijze getoetst worden binnen het eigen team:

• Zijn de scenario’s nog actueel?
• Werken de tijdelijke werkwijzen nog zoals bedoeld?
• Zijn de contactpersonen nog bereikbaar?
• Is iedereen op de hoogte van de noodprocedures?
• Zijn er nieuwe afhankelijkheden ontstaan die nog niet in beeld zijn?

Door dit twee tot drie keer per jaar te bespreken en te actualiseren, blijft het geheel werkbaar en relevant.

Bewijslast zonder bureaucratie

Veel organisaties denken dat aantoonbaarheid betekent dat er complexe procedures moeten worden vastgelegd. Dat is niet nodig. Voor impactbeperking is aantoonbaarheid vooral een kwestie van documenteren wat er is afgesproken en hoe dit periodiek wordt herzien.

Voorbeelden van minimale, maar effectieve documentatie:

• Een overzicht met impactscenario’s en bijbehorende acties
• Notities van overleg waarin continuïteitsmaatregelen zijn besproken
• Een korte instructie per proces voor wat te doen bij uitval
• Een lijst met cruciale leveranciers en fallbackopties

Deze stukken vormen samen het bewijs dat de organisatie haar verantwoordelijkheid serieus neemt.

Het verschil tussen falen en veerkracht

In de praktijk is het niet het incident dat organisaties in de problemen brengt, maar de onvoorbereidheid. Het ontbreken van alternatieven, structuur en coördinatie vergroot de schade. Veerkracht ontstaat door vooraf bewust keuzes te maken. Ook al is de kans op een incident beperkt, de schade bij een slechte reactie is groot.

Daarom geldt:

• Incidenten zijn onvoorspelbaar, maar de reactie hoeft dat niet te zijn
• Veerkracht is het vermogen om snel door te gaan, niet om alles te voorkomen
• Impactbeperking is geen overheidsverplichting, maar een overlevingsstrategie

Samengevat

Kleine organisaties zonder eigen IT blijven verantwoordelijk voor informatiebeveiliging. ISO 27001 en NEN 7510 zijn schaalbaar en toepasbaar, mits praktisch ingericht. Uitbesteden is geen reden om verplichtingen te negeren. Juist dan is grip noodzakelijk.

De kernpunten op een rij:

• Grootte is geen maatstaf, risico’s zijn dat wel
• Uitbestede processen vallen binnen de scope van het ISMS
• Beheersmaatregel A.5.22 draait om aantoonbare grip, niet om techniek
• Goede afspraken vooraf maken controle achteraf mogelijk
• Impactbeperking is altijd uitvoerbaar, ook zonder eigen IT

Verantwoordelijkheid kan niet gedelegeerd worden. Wel kunnen maatregelen slim, haalbaar en effectief ingericht worden. Vertrouwen is geen strategie, wel een vertrekpunt. Regie houden is noodzakelijk.

Dus:
Begin bij de risico’s, leg afspraken vast, houd toezicht en bereid je voor op verstoringen. Niet alles hoeft perfect — het moet wel onderbouwd zijn.

Zo wordt informatiebeveiliging werkbaar, ook voor kleine organisaties.