Hoe A.5.20 in ISO 27001 MSP-leverancierscontracten en -audits transformeert

Waarom MSP-contracten een ISO 27001:2022-hotspot zijn

MSP-contracten vormen een ISO 27001:2022-hotspot, omdat auditors leveranciersovereenkomsten nu beschouwen als primair bewijs van hoe uw controles zich uitstrekken tot in de toeleveringsketen. Ze verwachten schriftelijke verplichtingen, rollen en incidentprocessen die aantonen dat uw ISMS zich uitstrekt tot de diensten die u inkoopt en levert, en niet alleen tot interne diagrammen of beleidslijnen. Commentaren en implementatierichtlijnen voor ISO/IEC 27001:2022 benadrukken dat organisaties moeten aantonen hoe controles van toepassing zijn op relevante leveranciers, en certificatie-instellingen gebruiken contracten vaak als onderdeel van die bewijsset. Voor managed service providers fungeren alledaagse commerciële contracten nu ook als beveiligingsartefacten die de certificering en het klantvertrouwen kunnen versterken of verzwakken.

MSP-overeenkomsten zijn niet langer alleen commerciële tools; ze maken deel uit van uw beveiligingsbeleid. ISO 27001:2022 verwacht dat beveiligingsverplichtingen, verantwoordelijkheden en incidentafhandeling worden weerspiegeld in contracten en bijbehorende documenten. In veel organisaties omvatten deze onder meer master service agreements (MSA's), statements of work (SoW's), service level agreements (SLA's), data processing agreements (DPA's) en beveiligingsschema's, ook al schrijft de norm geen specifieke documentlabels voor. Als deze elementen ontbreken of vaag zijn, zullen auditors moeite hebben om te zien hoe uw Annex A-controles in de praktijk werken.

De informatie in dit document is van algemene aard en vormt geen juridisch advies. Voor contractuele beslissingen is de inbreng van een bevoegd juridisch adviseur vereist.

Hoe ISO 27001:2022 MSP-contracten binnen het bereik brengt

ISO 27001:2022 brengt MSP-contracten onder de aandacht door leveranciersbeveiliging te beschouwen als een contractuele verantwoordelijkheid die schriftelijk moet worden vastgelegd en overeengekomen. De norm verwacht dat u in uw overeenkomsten laat zien hoe verantwoordelijkheden op het gebied van informatiebeveiliging, regels voor gegevensverwerking en incidentprocessen zijn verdeeld over klant, MSP en upstream-providers. Deze verschuiving legt de focus van audits direct op de contracten waarop uw bedrijf vertrouwt.

In het ISMS.online State of Information Security-onderzoek van 2025 noemde ongeveer 41% van de organisaties het beheersen van risico's van derden en het bijhouden van de naleving door leveranciers als grootste uitdagingen op het gebied van informatiebeveiliging.

Managed service providers bevinden zich midden in lange supply chains. U bent afhankelijk van cloudplatforms, datacenters, beveiligingstools en gespecialiseerde SaaS, en uw klanten zijn afhankelijk van u. Wanneer incidenten zich door deze ketens heen hebben verspreid, hebben onderzoekers herhaaldelijk hetzelfde patroon gezien: commerciële voorwaarden waren gedetailleerd, maar beveiligingsrollen, gegevensverwerking, incidentrespons en toezicht waren vaag of ontbraken in contracten. Analyses van supply chain-aanvallen in cloud- en outsourcingcontexten laten vaak zien dat contractuele aandacht zich richtte op prijs en servicekenmerken, terwijl beveiligingsverantwoordelijkheden impliciet bleven, wat de invloed bij storingen aanzienlijk beperkte. Als verwachtingen impliciet in plaats van schriftelijk worden vastgelegd, hebt u weinig invloed wanneer er iets misgaat.

Uit het onderzoek 'State of Information Security 2025' bleek dat de meeste organisaties in het voorgaande jaar te maken hadden gehad met minimaal één beveiligingsincident gerelateerd aan een derde partij of leverancier.

Toezichthouders en klanten hebben hierop gereageerd door veel scherpere vragen te stellen. Het is niet langer voldoende om te zeggen "we zijn ISO-conform" of "onze leveranciers volgen de industrienormen". Afnemers willen weten hoe verantwoordelijkheden worden gedeeld, hoe snel u hen op de hoogte stelt van problemen, hoe subverwerkers worden aangestuurd en wat er met gegevens gebeurt wanneer een relatie wordt beëindigd. Toezichtrichtlijnen in veel sectoren verwijzen nu expliciet naar schriftelijke outsourcingovereenkomsten en verwachten dat bedrijven aantonen hoe zij toezicht houden op derden. Auditors nemen daarom routinematig steekproeven van die overeenkomsten bij het beoordelen van de effectiviteit van de controle. Op gebieden zoals operationele veerkracht en outsourcing in de financiële dienstverlening bijvoorbeeld, specificeren prudentiële regels de noodzaak van gedocumenteerde verantwoordelijkheden, meldingsplichten en exitbepalingen in outsourcingcontracten, en die gedachtegang wordt steeds meer weerspiegeld in de bredere praktijk van risicomanagement voor derden.

Voor MSP's betekent dit dat contracten nu deel uitmaken van het aanvalsoppervlak en van de bewijslast. Als beveiligingseisen, serviceniveaus, incidentprocessen en auditrechten niet worden vastgelegd, zullen auditors twijfelen of de controles van Bijlage A zich daadwerkelijk uitstrekken tot de toeleveringsketen. Nog belangrijker is dat u mogelijk de mogelijkheid verliest om aan te dringen op herstel of samenwerking wanneer een upstream-leverancier faalt of zich verzet tegen controle.

Een platform als ISMS.online kan hierbij helpen door leveranciersgegevens, risicobeoordelingen en contractbewijzen op één plek te koppelen. Uw uitgangspunt is echter een duidelijk overzicht van de inhoud die uw overeenkomsten volgens Bijlage A.5.20 moeten bevatten.

Duidelijke contracten zetten veronderstelde zekerheid om in afdwingbare verantwoordelijkheid.

Waarom dit belangrijk is voor MSP-audits en het vertrouwen van klanten

Duidelijke, beveiligingsbewuste contracten zorgen ervoor dat MSP-audits soepeler verlopen en geven klanten meer vertrouwen in uw diensten. Wanneer in overeenkomsten staat wie verantwoordelijk is voor belangrijke controles, hoe incidenten worden afgehandeld en hoe gegevens worden beschermd, worden uw uitleg tijdens beoordelingen en verkoopgesprekken preciezer en minder defensief.

Volgens het ISMS.online-onderzoek uit 2025 verwachten klanten steeds vaker dat hun leveranciers zich houden aan formele kaders zoals ISO 27001, ISO 27701, AVG, Cyber Essentials, SOC 2 en opkomende AI-normen.

Door contracten als beveiligingsartefacten te beschouwen, verandert de manier waarop uw audits aanvoelen en hoe klanten u beoordelen. Auditors kunnen risico's herleiden tot verplichtingen; klanten zien dat beveiliging onderdeel is van uw manier van zakendoen, en niet een bijzaak. Wanneer die elementen ontbreken, moeten beide partijen raden wat u bedoelde, en die onzekerheid ondermijnt het vertrouwen.

Voor MSP's is het praktische effect eenvoudig: elke keer dat u een overeenkomst onderhandelt of verlengt, versterkt of verzwakt u uw beveiligingspositie. Door sterke clausules te standaardiseren en consistent toe te passen, creëert u een verdedigbare basis die standhoudt bij certificeringsaudits, RFP's en controles door toezichthouders. Als u vertrouwt op ad-hoc formuleringen, creëert u variabiliteit die zichtbaar wordt op precies de momenten waarop u voorspelbaarheid en controle het meest nodig hebt.

Demo boeken

Wat ISO 27001:2022 A.5.20 feitelijk vereist

ISO 27001:2022 A.5.20 vereist dat u informatiebeveiligingseisen voor elke leveranciersrelatie identificeert en deze vastlegt in afdwingbare overeenkomsten. Wanneer een leverancier de vertrouwelijkheid, integriteit of beschikbaarheid van uw informatie of diensten kan beïnvloeden, moet u in contracten of gelijkwaardige documenten vastleggen wat u van hem verwacht, zodat beide partijen deze kunnen begrijpen en ernaar kunnen handelen. Dit komt overeen met de formulering van Bijlage A.5.20 in ISO/IEC 27001:2022, waarin wordt gesteld dat informatiebeveiligingseisen voor leveranciersrelaties moeten worden geïdentificeerd en in overeenkomsten moeten worden geïmplementeerd, zodat deze schriftelijke verwachtingen deel uitmaken van uw auditbewijs.

In de praktijk verplaatst Bijlage A.5.20 beveiligingseisen van interne documenten naar de overeenkomsten die bepalen hoe diensten worden geleverd. Voor MSP's betekent dit dat contracten met klanten en leveranciers in de toeleveringsketen moeten aantonen hoe beveiligingsverantwoordelijkheden worden gedeeld, hoe gegevens worden verwerkt en hoe incidenten worden afgehandeld. Auditors zullen zoeken naar die traceerbare link tussen leveranciersrisico's, interne controles en contractteksten.

Onderscheid maken tussen A.5.20 en andere leverancierscontroles

A.5.20 onderscheidt zich van aangrenzende leverancierscontroles doordat het zich richt op wat er in contracten staat in plaats van hoe leveranciers worden geselecteerd of gemonitord. Door dit onderscheid te begrijpen, kunt u het juiste bewijs voor elke controle opstellen en voorkomen dat u alles als één vage eis behandelt.

A.5.19, "Informatiebeveiliging in leveranciersrelaties", richt zich op de algehele levenscyclus: leveranciers selecteren, risico's beoordelen, prestaties monitoren en veranderingen beheren. A.5.21, "Informatiebeveiliging beheren in de ICT-toeleveringsketen", legt de nadruk op complexe ketens, onderleveranciers en privacy- of persoonsgegevensrisico's, met name wanneer meerdere leveranciers samenwerken om een dienst te leveren. Overzichten van ISO/IEC 27001:2022 en gerelateerde richtlijnen presenteren A.5.19 consequent als de beheersmaatregel voor levenscyclusbeheer en A.5.21 als de specifieke beheersmaatregel voor de ICT-toeleveringsketen, wat het gebruik ervan naast A.5.20 ondersteunt in plaats van ze als duplicaten te behandelen. Samen beschrijven ze hoe u risico's van derden in de loop van de tijd beheert.

Bijlage A.5.20, "Informatiebeveiliging in leveranciersovereenkomsten aanpakken", concentreert zich op de inhoud: wat er in contracten, schema's en voorwaarden staat. Auditors zien vaak degelijk werk in A.5.19 (leveranciersregisters, risicobeoordelingen, due diligence-vragenlijsten), maar een zwakke uitvoering in A.5.20, waar contracten nog steeds weinig meer zeggen dan "de leverancier zal voldoen aan de toepasselijke wetten en industrienormen". Dat soort taalgebruik laat zelden zien dat specifieke risico's zijn vertaald in verplichtingen die kunnen worden afgedwongen en getest.

Kernverplichtingen A.5.20 op MSP-overeenkomsten

A.5.20 legt een aantal kernverplichtingen op aan MSP-overeenkomsten, gericht op het documenteren van duidelijke verantwoordelijkheden en minimale beveiligingsverwachtingen. Voor elke leverancier die van invloed is op uw ISMS, moet u kunnen aantonen waar rollen, regels voor gegevensverwerking, incidentprocessen, wettelijke verplichtingen en toezichtmechanismen zijn gedefinieerd en door beide partijen worden geaccepteerd.

Concreet verwacht A.5.20 dat u:

Definieer in begrijpelijke taal de beveiligingsgerelateerde rollen en verantwoordelijkheden tussen u en elke leverancier.
Geef aan hoe de informatie door die leverancier mag worden geraadpleegd, verwerkt, opgeslagen, verzonden en verwijderd.
Leg de vereisten voor incidentmeldingen en samenwerking vast, inclusief timing en communicatiekanalen.
Voldoen aan relevante wettelijke verplichtingen, met name rondom persoonsgegevens en outsourcingregels.
Zorg voor toezicht, evaluatie en, waar nodig, audit of onafhankelijke assurance-mechanismen.

Voor MSP's moet "leverancier" breed worden geïnterpreteerd. Cloudplatforms, connectiviteitsproviders, ticketingtools, software voor monitoring op afstand, SOC-partners, onderaannemers en sommige strategische consultants kunnen allemaal binnen het bereik vallen als ze de klantenservice kunnen beïnvloeden of gevoelige informatie kunnen verwerken. De standaard gaat er niet van uit dat alleen grote, voor de hand liggende outsourcers van belang zijn.

Traceerbaarheid is de sleutel. Voor elk belangrijk leveranciersrisico dat u in uw ISMS vastlegt, wil een auditor weten waar het wordt aangepakt: in technische controles, in operationele processen en in contractclausules. A.5.20 is waar uw interne verwachtingen externe toezeggingen worden die zichtbaar zijn voor klanten, toezichthouders en auditors.

ISMS.online geeft u een voorsprong van 81% vanaf het moment dat u inlogt

ISO 27001 eenvoudig gemaakt

Wij hebben het harde werk voor u gedaan, waardoor u vanaf het moment dat u inlogt een voorsprong van 81% heeft. U hoeft alleen nog maar de lege plekken in te vullen.

Start

A.5.20 vertalen naar concrete MSP-contractonderwerpen

Het vertalen van A.5.20 naar concrete MSP-contractonderwerpen betekent dat brede beveiligingsverwachtingen worden omgezet in een korte, herhaalbare lijst met clausulegebieden. Als elke belangrijke leveranciersovereenkomst deze gebieden op een passend detailniveau behandelt, voldoet u grotendeels aan de bedoeling van de controle en worden audits en verlengingen eenvoudiger te beheren.

Voor MSP's is consistentie het voordeel van een themagerichte aanpak. Zodra u hebt besloten welke thema's in bijna elk contract moeten voorkomen, kunnen uw juridische, beveiligings- en commerciële teams werken met een gedeelde checklist in plaats van per geval te improviseren. Dit maakt het gemakkelijker om overeenkomsten te vergelijken, hiaten op te sporen en uw aanpak uit te leggen aan auditors en klanten.

Basisonderwerpen die elk MSP-leverancierscontract zou moeten omvatten

Basiscontractonderwerpen zijn de terugkerende thema's die u in vrijwel elke leveranciersovereenkomst met uw ISMS wilt zien. Ze bieden uw teams een pragmatische controlelijst en helpen u auditors te laten zien dat specifieke risico's in consistente, begrijpelijke taal zijn aangepakt in plaats van losse, eenmalige clausules.

Een praktische basislijn omvat doorgaans ten minste het volgende:

Omvang en gebruik van informatie: – toegestane gegevens en systemen, toegestaan gebruik, verboden gebruik.
Verwachtingen ten aanzien van toegangscontrole: – authenticatiemethoden, toegang met de minste bevoegdheden, regels voor externe toegang en regels voor de levenscyclus van accounts.
Logging en monitoring: – vereiste logs, bewaartermijnen en beschikbaarheid van gegevens tijdens onderzoeken.
Kwetsbaarheidsbeheer en patching: – verantwoordelijkheid voor ontdekking, beoordeling en herstel, met tijdschema's voor kwesties met een hoog risico.
Detectie en melding van incidenten: – wat als een beveiligingsincident wordt beschouwd, hoe snel u wordt geïnformeerd en hoe u samenwerkt.
Bedrijfscontinuïteit en noodherstel: – minimale beschikbaarheid, hersteldoelstellingen en deelname aan testen indien relevant.
Ondercontractanten en subverwerkers: – wanneer ze gebruikt mogen worden, hoe u geïnformeerd of goedgekeurd wordt en hoe de verplichtingen verlopen.
Gegevensbescherming en privacy: – voorwaarden voor de verwerking van persoonsgegevens, locaties, overdrachtsmechanismen, vertrouwelijkheid en ondersteuning van de rechten van de betrokkenen.
Bewaring, retournering en verwijdering van gegevens: – bewaartermijnen, retourformaten bij afsluiting en hoe veilig verwijderen wordt aangetoond.
Zekerheid en toezicht: – rapporten, certificeringen, vragenlijsten of overeengekomen audits waarop u kunt vertrouwen en wanneer deze worden verstrekt.

Deze onderwerpen behoeven niet allemaal lange clausules, maar ze moeten wel herkenbaar zijn in uw standaardcontracten en risicovolle contracten. Na het bekijken van een voorbeeld van overeenkomsten zou u met zekerheid moeten kunnen antwoorden: "Waar dekken we elk van deze punten, en hoe verandert dat per leveranciersniveau?"

Voor MSP's die namens klanten persoonsgegevens verwerken, moeten de privacyvoorwaarden aansluiten op deze beveiligingsclausules. Verwerkingsinstructies, vertrouwelijkheidsverklaringen, regels voor subverwerkers en auditrechten moeten uw bredere beveiligingsvereisten ondersteunen en er niet mee in conflict komen. Zo voorkomt u een situatie waarin de gegevensverwerkingsovereenkomst het ene zegt, het beveiligingsschema het andere, en geen van beide overeenkomt met de controles die in uw ISMS worden beschreven.

Contractonderwerpen koppelen aan interne ISMS-vragen

Door contractonderwerpen te koppelen aan interne ISMS-vragen, zorg je ervoor dat elke clausulefamilie een duidelijke risicovraag beantwoordt die je al bijhoudt. Wanneer je risicoregisters, controles en contracten hetzelfde mentale model gebruiken, wordt het veel gemakkelijker om aan auditors uit te leggen hoe je leveranciers van begin tot eind beheert.

Met behulp van een korte tabel kunt u deze onderwerpen afstemmen op de vragen die u intern stelt:

Contractonderwerp	Belangrijke vraag om te beantwoorden	Typische documentlocatie
Toegangscontrole	Wie heeft toegang tot wat en hoe wordt de toegang verleend of ingetrokken?	Beveiligingsschema / werkomschrijving
Incidentmelding	Wanneer en hoe hoort u over incidenten?	Beveiligingsschema / service level agreement
Subverwerkers	Wie zijn er nog meer bij betrokken en wie keurt ze goed?	Verwerkersovereenkomst / onderaannemingsclausule
Gegevens retourneren en verwijderen	Wat gebeurt er met de gegevens wanneer de relatie eindigt?	Bepalingen inzake beëindiging of uittreding
Audit en assurance	Hoe kunt u controleren of de beveiliging werkt zoals afgesproken?	Controlerechten of assurance-sectie

Zodra die verbanden duidelijk zijn, kunt u voor elke belangrijke leverancier documenteren waar specifieke risico's worden aangepakt. Dat geeft auditors de zekerheid dat u niet op algemene bewoordingen vertrouwt en geeft klanten een consistent verhaal wanneer ze vragen hoe u outsourcingrisico's beheert.

Het ontwerpen van een herbruikbare MSP-contractbasislijn

Het ontwerpen van een herbruikbare MSP-contractbasislijn betekent het creëren van een standaardstructuur en clausuleset die werkt voor meerdere deals met risicogebaseerde variaties. In plaats van telkens de formulering opnieuw uit te vinden, behoudt u één gecontroleerde basislijn en past u de diepgang en sterkte aan, afhankelijk van de impact van de leverancier op uw diensten en klanten.

Een herbruikbare baseline vertaalt een lange lijst met onderwerpen naar een praktische contractstructuur die u in uw hele portfolio kunt implementeren. Het doel is om te stoppen met het opstellen van een nieuwe contractstructuur voor elke deal en één set posities te behouden die u risicogebaseerd kunt aanscherpen of versoepelen, terwijl de algehele consistentie behouden blijft.

Het bouwen van een modulaire contractstructuur voor MSP's

Met een modulaire contractstructuur behoudt u één samenhangende basislijn en geeft u juridische, commerciële en technische teams duidelijk eigenaarschap over hun onderdelen. Door servicebeschrijvingen, juridische standaardteksten en beveiligingsinhoud te scheiden, maakt u updates eenvoudiger en verkleint u het risico dat een wijziging op het ene gebied onbedoeld een ander verzwakt.

De meeste MSP's vinden een modulaire structuur het beste werken, omdat je hiermee afzonderlijke onderdelen kunt bijwerken zonder alles te hoeven herschrijven. Een duidelijke scheiding tussen juridische standaardtekst, servicebeschrijvingen en beveiligingsverwachtingen helpt verschillende teams ook om hun secties te beheren.

Typische componenten zijn onder meer:

A Master Service Agreement (MSA) met daarin de belangrijkste juridische termen en de belangrijkste verantwoordelijkheden.
Een of meer Werkomschrijvingen (SoW's) beschrijving van specifieke diensten, activa en locaties.
A serviceniveau bijlage het definiëren van beschikbaarheids-, respons- en oplossingsdoelen, rapportage en servicecredits.
A beveiligingsschema het concentreren van de verplichtingen inzake informatiebeveiliging en privacy die vereist zijn door A.5.19–A.5.21.
Wanneer persoonsgegevens worden verwerkt, gegevensverwerkingsovereenkomst (DPA) afgestemd op het beveiligingsschema.

Binnen die structuur vormt het beveiligingsschema het primaire instrument voor A.5.20. Het hoeft niet lang te zijn, maar het moet wel systematisch de kernonderwerpen uit de vorige sectie behandelen. Door korte, genummerde paragrafen of tabellen te gebruiken in plaats van verspreide verwijzingen, wordt het voor beide partijen gemakkelijker om de inhoud te begrijpen en te onderhouden.

Van uw basislijn een bibliotheek met levensclausules maken

Om van uw basislijn een levende clausulebibliotheek te maken, verzamelt u herbruikbare formuleringen, koppelt u deze aan controles en maakt u het voor teams gemakkelijk om de juiste variant toe te passen. Uw doel is om eenmalige zinnen die in oude contracten verborgen zitten te vermijden en in plaats daarvan een zorgvuldig samengestelde set clausules te onderhouden die meegroeit met uw risicobereidheid en wettelijke context.

Om van theorie naar dagelijkse praktijk te komen, hebt u formuleringen nodig die technologie-agnostisch, herleidbaar tot controles en eenvoudig aanpasbaar zijn aan verschillende risiconiveaus. Zo kunt u dezelfde kernwaarden toepassen op hosting, SOC, SaaS en professionele services, terwijl u toch rekening houdt met de verschillende risicoprofielen.

Om een basislijn te creëren, kunt u:

Stap 1 – Begin vanuit uw ISMS

Begin met het identificeren van de controles en beleidsregels waaraan leveranciers zich moeten houden, zoals wachtwoordnormen, encryptieverwachtingen, registratie en reactietermijnen bij incidenten. Zo weet u welke vereisten in contracten moeten worden opgenomen.

Stap 2 – Groepeer de vereisten in contractonderwerpen

Groepeer elke verwachting in een clausulegebied, zoals toegangscontrole, incidentbeheer, continuïteit of gegevensverwerking. Zo beperkt u duplicatie en kunt u snel zien waar er hiaten zitten in conceptovereenkomsten.

Stap 3 – Ontwerp neutrale, resultaatgerichte formuleringen

Schrijf clausules die verantwoordelijkheden en resultaten beschrijven, en niet specifieke tools of configuraties. Zo blijft uw formulering bestand tegen technologische veranderingen en relevant voor verschillende soorten leveranciers.

Stap 4 – Tag clausules intern aan ISO-controles

Leg in uw interne documentatie vast welke ISO 27001 en gerelateerde beheersmaatregelen elke clausule ondersteunt. Zo vereenvoudigt u de uitleg van audits, ondersteunt u het testen van beheersmaatregelen en benadrukt u eventuele overlappingen of conflicten.

Stap 5 – Standaard- en verbeterde varianten definiëren

Maak een standaardclausule en stel strengere versies op voor situaties met een hoger risico. Denk bijvoorbeeld aan kortere doorlooptijden voor incidenten of sterkere auditrechten voor cruciale services. Zo weten onderhandelaars vanaf welk standpunt ze moeten beginnen en wanneer ze moeten escaleren.

Het uitrollen van de baseline is een veranderingsprogramma op zich. Een gebruikelijke aanpak is om de baseline toe te passen op alle nieuwe klant- en leverancierscontracten, verlengingen en significante wijzigingen te gebruiken om bestaande risicovolle contracten te upgraden en een register bij te houden van uitzonderingen waarin u zwakkere voorwaarden accepteert met gedocumenteerde redenen en compenserende maatregelen.

ISMS.online kan dit ondersteunen door uw clausulebibliotheek op te slaan, elke clausule te koppelen aan controles en leveranciers, en vast te leggen welke versie van de basislijn elk contract gebruikt. Dit vermindert de administratieve overhead en maakt het gemakkelijker om vragen te beantwoorden zoals "Welke hostingproviders gebruiken nog de oudere standaard voor het melden van inbreuken?"

Integreer, breid uit en schaal uw compliance, zonder rommel. IO geeft u de veerkracht en het vertrouwen om veilig te groeien.

Boek uw demo

Het verenigen van A.5.19, A.5.20 en A.5.21 in “altijd-aan”-clausules

Het verenigen van A.5.19, A.5.20 en A.5.21 in "always-on"-clausules betekent het ontwerpen van een kleine set clausulefamilies die gezamenlijk de governance van de leverancierslevenscyclus, de contractinhoud en de risico's in de ICT-toeleveringsketen dekken. In plaats van drie controles als afzonderlijke projecten te behandelen, gebruikt u herhaalbare formuleringen die ze samen afdekken waar het risicoprofiel dat vereist.

Als u A.5.19, A.5.20 en A.5.21 als drie losse checklists behandelt, wordt leveranciersmanagement al snel complex en moeilijk uit te leggen. Prudentiële en operationele risiconormen in sectoren zoals financiële dienstverlening zijn geëvolueerd naar geïntegreerde outsourcing en externe kaders in plaats van gefragmenteerde lijsten met vereisten, en dezelfde logica is van toepassing wanneer u beheersmaatregelen ontwerpt voor ISO 27001-leveranciersclausules. Het ontwerpen van clausulefamilies die leveranciers volgen van onboarding tot exit geeft u één verhaal: hoe u leveranciers kiest, hoe u met hen contracteert en hoe u hun beveiliging gedurende de relatie bewaakt.

De meeste organisaties die deelnamen aan het State of Information Security-onderzoek van 2025 gaven aan dat ze het risicomanagement van derden al hadden versterkt en van plan waren om hier verder in te investeren.

Clausulefamilies die samen voldoen aan A.5.19, A.5.20 en A.5.21

Clausulefamilies zijn groepen gerelateerde verplichtingen die betrekking hebben op leveranciersselectie, contractering en doorlopend toezicht. Door deze één keer te definiëren en gedurende de hele levenscyclus toe te passen, wordt uw aanpak gemakkelijker uit te leggen, gemakkelijker te onderhandelen en veerkrachtiger bij personeels- of leverancierswisselingen.

Nuttige families zijn onder andere:

Onboarding en due diligence: – openbaarmaking van belangrijke beveiligingsinformatie tijdens de selectie, acceptatie van uw basislijn en bevestiging van relevante certificeringen of rapporten.
Prestatie- en beveiligingsbeoordeling: – regelmatige vergaderingen, metingen, rapportage van incidenten en kwetsbaarheden en het recht om herstelplannen op te vragen.
Verandermanagement: – melding van materiële wijzigingen in de infrastructuur, subverwerkers, locaties of beveiligingsmaatregelen voordat deze plaatsvinden, plus het recht om bezwaar te maken of het risico opnieuw te beoordelen.
Bestuur van onderleveranciers: – transparantie over de eigen keten van de leverancier, voorafgaande goedkeuring voor nieuwe subverwerkers en doorstroming van minimale verplichtingen.
Uitgang en overgang: – beveiligingsbewuste beëindigingsclausules die zorgen voor een gecontroleerde overdracht, teruggave of vernietiging van gegevens en intrekking van de toegang.

Met deze families kunt u de levenscyclusgovernance (selectie, monitoring, wijziging, beëindiging) van A.5.19, de contractinhoud van A.5.20 en de focus van A.5.21 op complexe ICT-toeleveringsketens implementeren zonder drie verschillende sets clausules te hoeven schrijven. U beschrijft de levenscyclus één keer en stemt vervolgens de intensiteit af op het leveranciersniveau, in plaats van telkens de structuur opnieuw uit te vinden.

Risicogebaseerde gelaagdheid voor leverancierscontracten

Risicogebaseerde gelaagdheid in leverancierscontracten betekent dat u uw clausulefamilies op verschillende sterktes toepast, afhankelijk van de mate van schade die een tekortkoming bij die leverancier zou kunnen veroorzaken. Door vooraf gelaagdheid en bijbehorende verwachtingen te definiëren, voorkomt u improvisatie per geval en kunt u auditors uitleggen waarom sommige contracten strenger zijn dan andere.

Risicogebaseerde tiering verfijnt clausulefamilies, zodat kritieke leveranciers sterkere verplichtingen hebben, terwijl routinematige leveranciers nog steeds aan een minimumbasis voldoen. Dit helpt u auditors en klanten uit te leggen waarom beveiligingsverwachtingen variëren en laat zien dat de variatie opzettelijk is en niet willekeurig.

U kunt bijvoorbeeld het volgende definiëren:

Niveau 1 – Kritische leveranciers: zoals primaire hosting- of SOC-partners, met on-site auditrechten, kortere tijden voor het melden van incidenten, sterkere continuïteitsverplichtingen en gedetailleerdere rapportage.
Niveau 2 – Belangrijke leveranciers: zoals SaaS-providers die actief zijn in de zakelijke markt, die vertrouwen op onafhankelijke assurance-rapporten, gerichte vragenlijsten en standaard meldingstijden.
Niveau 3 – Standaardleveranciers: zoals kleine hulpmiddelen, waarbij gebruik wordt gemaakt van een vereenvoudigde basislijn met niet-onderhandelbare clausules over vertrouwelijkheid, melding van incidenten en onderaannemers.

Op alle niveaus moeten bepaalde verwachtingen altijd 'aan' zijn: vertrouwelijkheid, een gedefinieerde reikwijdte van de verwerking, minimale samenwerking bij incidenten en de verplichting om uw classificatie- en verwerkingsregels voor gevoelige informatie te respecteren. Tiering wordt dan een kwestie van het versterken, niet van het afbreken, van die fundamenten.

Door clausules op deze manier te ontwerpen, kunt u auditors en klanten laten zien dat leverancierstoezicht gestructureerd is in plaats van ad hoc, en dat contractuele verwachtingen toenemen met het risico. Het maakt het ook gemakkelijker om te bepalen waar u zich op moet richten bij het ontdekken van zwakke punten in bestaande overeenkomsten.

Veelvoorkomende auditlacunes in MSP-contracten en de gevolgen daarvan

Veelvoorkomende auditlacunes in MSP-contracten ontstaan wanneer belangrijke beveiligingsonderwerpen ontbreken, vaag zijn of inconsistent zijn in de overeenkomsten. Auditors en klanten merken snel patronen op, zoals zwakke incidentplanningen, ontbrekende bepalingen voor onderaannemers en ontoereikende auditrechten. Deze lacunes leiden vaak tot bevindingen, herstelplannen of gemiste kansen.

Wanneer certificeringsinstanties en klanten MSP-contracten toetsen aan A.5.20, komen ze herhaaldelijk vergelijkbare zwakke punten tegen. Regelgevende richtlijnen voor cloud- en outsourcingovereenkomsten documenteren ook terugkerende problemen zoals vage beveiligingsvoorwaarden, ondoorzichtigheid van onderaannemers en zwakke auditrechten, wat overeenkomt met wat veel auditors melden wanneer ze MSP-contracten controleren. Door deze patronen vroegtijdig te herkennen, is het gemakkelijker om ze aan te pakken voordat ze uitmonden in non-conformiteiten, wettelijke vragen of contractuele geschillen.

Patronen die auditors en klanten signaleren in MSP-overeenkomsten

Patronen die auditors en klanten in MSP-overeenkomsten signaleren, concentreren zich vaak rond vage formuleringen op een paar terugkerende punten. Wanneer steekproefsgewijs dezelfde zachte taal wordt gebruikt voor incidenten, onderaannemers, auditrechten en wettelijke verplichtingen, vragen reviewers zich al snel af of uw leveranciersbasis wel sterk genoeg is voor de risico's waarmee u wordt geconfronteerd.

Auditors beginnen meestal met het doornemen van een klein aantal contracten om te zien hoe uw baseline in de praktijk wordt toegepast. Als deze steekproeven vage verplichtingen en ontbrekende onderwerpen laten zien, kunnen ze snel zorgen over uw leverancierstoezicht in het algemeen vergroten. Conformiteitsbeoordelings- en interne auditnormen maken doorgaans onderscheid tussen kleine en grote bevindingen op basis van de ernst en de mate van dekking. Zwakke clausules kunnen dus verschillend worden beoordeeld, afhankelijk van hoe wijdverbreid ze zijn en hoeveel schade ze kunnen veroorzaken.

Typische hiaten zijn onder meer:

Vage veiligheidsbeloften: waarbij uitdrukkingen als ‘beveiliging volgens de industriestandaard’ onvoldoende details bevatten over toegangscontrole, logging of respons op incidenten.
Ongedefinieerde incidenttijdlijnen: waarbij leveranciers beloven om ‘zonder onnodige vertraging’ verslag uit te brengen, maar er geen tijdsbestek is vastgelegd voor de eerste melding of updates.
Er wordt niet gesproken over onderaannemers: Je kunt dus niet zien of de leverancier subverwerkers mag inschakelen of hoe verplichtingen worden doorgeschoven.
Ontbrekende of zwakke auditrechten: waardoor u niet op een betrouwbare manier kunt controleren of de controles werken zoals verwacht.
Niet op elkaar afgestemde regelgevende taken: wanneer contracten sectorspecifieke outsourcing- of gegevensbeschermingsvereisten missen die op u van toepassing zijn.

Wanneer auditors deze patronen ontdekken, kunnen ze deze classificeren als kleine of grote non-conformiteiten, afhankelijk van de ernst en dekking. Klanten, met name in gereguleerde sectoren, kunnen soortgelijke tekortkomingen beschouwen als reden om saneringsplannen, strengere voorwaarden of, in sommige gevallen, een wisseling van leverancier te eisen.

Hoe zwakke clausules leiden tot bevindingen, geschillen en verloren vertrouwen

Zwakke clausules leiden tot bevindingen, geschillen en verloren vertrouwen wanneer incidenten of meningsverschillen de hiaten in uw contractuele verwachtingen blootleggen. Zonder duidelijke verantwoordelijkheden, tijdlijnen en escalatiemogelijkheden riskeert u trage reacties, betwiste verplichtingen en een verhaal dat het vertrouwen bij klanten en toezichthouders ondermijnt.

Een eenvoudige vergelijking illustreert waarom details belangrijk zijn:

De Omgeving	Voorbeeld van een zwakke clausule	Voorbeeld van een sterke bijzin
Incidentmelding	“Meld dit zonder onnodige vertraging.”	“Binnen vier uur na detectie een melding, daarna dagelijkse updates.”
Subverwerkers	Geen vermelding.	“Identificeer, vraag goedkeuring aan en bind alle subverwerkers.”
Audit en assurance	“Verstrek indien mogelijk de gevraagde rapporten.”	“Zorg voor jaarlijkse assurance-rapporten en werk mee aan beoordelingen.”

Vertraagde of onvolledige meldingen kunnen ertoe leiden dat u een incident via de pers of uw klanten ontdekt in plaats van via uw leverancier, waardoor u minder goed kunt reageren en communiceren. Richtlijnen voor risico's van derden in gereguleerde sectoren hebben gevallen gedocumenteerd waarin zwakke meldingsplichten ertoe leidden dat organisaties problemen van externe bronnen vernamen in plaats van via hun leveranciers. Dit is precies het scenario dat u wilt vermijden. Onduidelijke verantwoordelijkheden leiden tot vingerwijzen op het slechtst mogelijke moment. Gebrek aan auditrechten maakt het moeilijker om aan te dringen op herstel of om oplossingen te valideren, vooral als toezichthouders of klanten meekijken.

Het positieve is dat bevindingen op dit gebied meestal oplosbaar zijn. Door ze om te zetten in een gestructureerd verbeterprogramma - door basissjablonen bij te werken, onderhandelaars bij te scholen en de herstelmaatregelen eerst te richten op de contracten met het hoogste risico - krijgt u bij de volgende audit of klantbeoordeling een duidelijk beeld van de voortgang. ISMS.online kan u helpen bij het prioriteren van dat programma door te laten zien waar oudere clausules of zwakkere posities nog steeds bestaan en hoe deze zich verhouden tot de risiconiveaus van leveranciers.

ISMS.online ondersteunt meer dan 100 normen en voorschriften, waardoor u één platform krijgt voor al uw compliancebehoeften.

Boek uw demo

Governance: uw basislijn op één lijn houden en controleerbaar houden

Governance zorgt ervoor dat uw A.5.20-basislijn consistent en controleerbaar blijft door eigenaarschap, reviewcycli en bewijs voor leveranciersbeveiligingsclausules te definiëren. Zonder duidelijke governance kan zelfs een goed ontworpen clausulebibliotheek in de loop der tijd verschuiven, waardoor er stille gaten ontstaan tussen uw vastgestelde risicobereidheid, uw contracten en uw operationele realiteit.

In het rapport 'State of Information Security 2025' gaf ongeveer tweederde van de organisaties aan dat de snelheid en omvang van de veranderingen in de regelgeving het moeilijker maken om aan de regelgeving te voldoen.

Een contractbasislijn levert alleen waarde op als deze consistent wordt onderhouden en toegepast. Governance is de laag die uw clausulebibliotheek verbindt met dagelijkse beslissingen, leveranciersrelaties en auditbewijs, en is vaak het verschil tussen een eenmalige opschoning en een duurzame A.5.20-implementatie.

Toekenning van eigendom voor leveranciersbeveiligingscontracten

Het toewijzen van verantwoordelijkheid voor leveranciersbeveiligingscontracten betekent dat u expliciet moet aangeven wie de verwachtingen definieert, wie de formuleringen onderhandelt, wie de prestaties monitort en wie de afstemming toetst. Wanneer die verantwoordelijkheden duidelijk zijn, is de kans veel kleiner dat belangrijke clausules worden afgezwakt of omzeild in nevenafspraken.

Een eenvoudig model begint vaak met:

Informatiebeveiliging: het definiëren van controleverwachtingen, risicobereidheid en niet-onderhandelbare posities.
Juridische en contractteams: het vertalen hiervan naar afdwingbare bewoordingen en het begeleiden van onderhandelingen.
Service- en leveranciersmanagers: het monitoren van prestaties, het toezicht houden op verplichtingen en het verzamelen van bewijsmateriaal.
Interne audit of een gelijkwaardige functie: periodiek testen of contracten en werkwijzen op elkaar aansluiten.

Door beoordelingen van de baseline te koppelen aan uw ISMS-processen, blijft deze actueel. Wanneer risicobeoordelingen nieuwe bedreigingen aan het licht brengen, zich grote incidenten voordoen of regelgeving verandert, moeten deze triggers worden meegenomen in de geplande templatebeoordelingen. Managementbeoordelingen kunnen vervolgens beoordelen of de contractbepalingen nog steeds aansluiten bij de risicohouding van de organisatie en of verdere wijzigingen nodig zijn.

Hulpmiddelen en beoordelingen die het bewijsmateriaal van A.5.20 actueel houden

Tools en reviews houden A.5.20-bewijsmateriaal actueel door u inzicht te geven in welke contracten welke clausules gebruiken en waar afwijkingen bestaan. Met dat inzicht kunt u updates prioriteren, onderhandelingen ondersteunen en auditors een duidelijke uitleg geven over hoe de verwachtingen van leveranciers in de loop der tijd worden gehandhaafd.

Governance is eenvoudiger wanneer u in één oogopslag kunt zien welke contracten welke clausules gebruiken en waar uitzonderingen zich bevinden. Die zichtbaarheid ondersteunt zowel operationele besluitvorming als auditvoorbereiding, met name in MSP-omgevingen met veel klanten en leveranciers. Praktijken uit de disciplines versiebeheer en wijzigingsbeheer laten zien dat het bijhouden van welke documentversies in welke contexten van toepassing zijn, een belangrijk onderdeel is van het aantonen van controle. Hetzelfde principe geldt voor contractbasislijnen en -afwijkingen.

Een praktische toolkit voor governance bevat vaak:

A contract- en leveranciersregister waarin wordt aangegeven welke basisversie elke relatie gebruikt, het risiconiveau, belangrijke data en eventuele goedgekeurde afwijkingen.
A afwijkingsproces vastleggen wie uitzonderingen op de basislijn kan goedkeuren, op welke gronden en met welke compenserende maatregelen.
Opleiding en begeleiding: voor verkoop-, inkoop- en juridische teams, zodat zij begrijpen welke beveiligingsfuncties niet onderhandelbaar zijn en hoe ze deze kunnen uitleggen.
Monster testen: door middel van interne audit, waarbij een selectie van contracten wordt vergeleken met de basislijn en de A.5.20-vereisten, en wordt gecontroleerd of de operationele realiteit overeenkomt met de afspraken.

Het gebruik van een systeem in plaats van spreadsheets maakt dit veel soepeler. Een ISMS-platform kan leveranciersvoorraden bijhouden, deze koppelen aan contracten en controles, en beoordelingen en goedkeuringen bijhouden. ISMS.online kan bijvoorbeeld vastleggen welke leveranciers onder welke risicoklasse vallen, welke clausulesets van toepassing zijn en waar uitzonderingen zijn toegestaan. Dit zorgt voor een duidelijk audittraject en verkleint de kans dat een stille contractwijziging uw beveiligingspositie ondermijnt.

Wanneer governance op orde is, is uw A.5.20-implementatie niet langer een eenmalige herstelmaatregel, maar een duurzaam onderdeel van de manier waarop u risico's van derden beheert en zekerheid biedt aan klanten en auditors.

Boek vandaag nog een demo met ISMS.online

ISMS.online helpt u ISO 27001 A.5.20 om te zetten in een herhaalbare MSP-contractbasis die uw leveranciersovereenkomsten veilig, consistent en controleerbaar houdt. Door leveranciersrecords, clausulebibliotheken, controlemappings en bewijsmateriaal te centraliseren, maakt het platform het eenvoudiger om aan te tonen dat informatiebeveiligingseisen in overeenkomsten worden behandeld en door de dagelijkse praktijk worden ondersteund.

Uw A.5.20-basislijn werkend zien in een echt ISMS

Als u uw A.5.20-basislijn in een echt ISMS ziet werken, kunt u leveranciers, risico's, contracten en controles in één omgeving traceren. Wanneer u dat kunt, verschuiven de gesprekken met auditors en klanten van het zoeken naar documenten naar het uitleggen hoe uw leveranciersbeheer werkt en hoe uitzonderingen worden beheerd.

Wanneer u leveranciers, risico's, contracten en Annex A-controles op één plek kunt koppelen, worden gesprekken met auditors en klanten eenvoudiger en betrouwbaarder. In plaats van te zoeken in gedeelde bestanden en inboxen, kunt u in één overzicht zien welke basisversie van toepassing is op elke relatie, welke uitzonderingen er zijn en hoe die beslissingen zijn gerechtvaardigd.

Binnen één omgeving helpt ISMS.online u leveranciers te koppelen aan risicobeoordelingen, contracten en controlesets, zodat u gemakkelijker kunt zien welke overeenkomsten welke onderdelen van uw ISMS ondersteunen. Workflows ondersteunen beoordelingen, goedkeuringen en verlengingen, zodat u ervoor kunt zorgen dat nieuwe deals de basislijn overnemen en dat risicovolle contracten prioriteit krijgen voor upgrades. Dashboards geven het management een beknopt overzicht van de leveranciersdekking, openstaande acties en aankomende verlengingsperiodes.

Wat u kunt verwachten wanneer u ISMS.online verkent

Wanneer u ISMS.online verkent, ziet u hoe gestructureerd leveranciersmanagement en A.5.20-contractbasislijnen werken in een live ISMS in plaats van in theorie. De focus ligt op hoe uw bestaande contracten, risico's en controles kunnen worden georganiseerd in één controleerbaar beeld dat handmatige inspanning vermindert en het vertrouwen vergroot.

Door ISMS.online te verkennen, ontdekt u hoe u uw huidige leveranciersbeheer kunt ontwikkelen tot een gestructureerd, controleerbaar systeem in plaats van dat u er nog een beheertool aan toevoegt. U kunt voorbeelden van A.5.20-clausulesets, toewijzingen en rapporten bekijken die zijn afgestemd op managed service providers en testen hoe deze passen bij uw bestaande contracten en processen.

Voor informatiebeveiligingsmanagers, juridische teams en MSP-eigenaren verkort die combinatie van structuur en zichtbaarheid de auditvoorbereiding, vermindert ze de onderhandelingsweerstand en versterkt ze de zekerheid. Kiezen voor ISMS.online is een logische keuze wanneer u wilt dat uw leveranciersovereenkomsten uw ISO 27001-certificering ondersteunen, controle tonen aan klanten en risico's voor derden verminderen zonder onnodige complexiteit toe te voegen. Als die resultaten voor u van belang zijn, is het zien van het platform in actie een logische volgende stap.

Demo boeken

Veelgestelde Vragen / FAQ

Hoe moet een MSP ISO 27001:2022 A.5.20 interpreteren in dagelijkse contracten met leveranciers en klanten?

U dient A.5.20 als een vereiste te beschouwen voor specifieke, testbare beveiligingsverplichtingen in uw contracten, niet geruststellende maar vage uitspraken over ‘robuuste’ of ‘industriestandaard’ beveiliging.

Wanneer een accountant, grote klant of toezichthouder uw overeenkomsten leest, moeten ze kunnen zien wie verantwoordelijk is voor welke controles, hoe 'goed' eruitziet en hoe u controleert of dat ook daadwerkelijk gebeurt.

Hoe zien ‘duidelijke en controleerbare beveiligingsclausules’ er in de praktijk uit?

Voor een MSP wordt aan A.5.20 voldaan wanneer leveranciers- en klantencontracten consistent:

Wijs beveiligingsverantwoordelijkheden toe:

Geef duidelijk aan wie verantwoordelijk is voor patching, endpoint protection, back-ups, identiteits- en toegangsbeheer, monitoring en het sorteren van incidenten, inclusief eventuele gedeelde verantwoordelijkheden.

Beschrijf hoe informatie wordt verwerkt:

Beschrijf hoe gegevens die binnen het toepassingsgebied vallen, worden benaderd, verwerkt, opgeslagen, verzonden, geback-upt, bewaard en verwijderd. Doe dit in een taal die ook voor niet-technische beoordelaars begrijpelijk is.

Definieer regels voor incidentmelding en samenwerking:

Gebruik concrete triggers (‘bevestigde inbreuk op klantgegevens’, ‘service-uitval > X minuten’), tijdlijnen (‘eerste melding binnen X uur’), vastgelegde contactroutes en verwachtingen voor gezamenlijke onderzoeken en communicatie.

Weerspiegelt de toepasselijke regelgeving en sectorregels:

Neem privacy, outsourcing, veerkracht of sectorspecifieke verplichtingen op in de overeenkomst, in plaats van alleen te vertrouwen op beleid of informele garanties.

Zorg voor bruikbare zekerheids- en toezichtmechanismen:

U krijgt het recht om bewijsmateriaal (ISO 27001-certificaten, SOC 2-rapporten, samenvattingen van pentesten, gerichte vragenlijsten) in te zien volgens een afgesproken ritme en waar nodig vervolgacties te ondernemen.

Een snelle zelfcontrole die bij auditors in de smaak valt:

Als we alleen dit contract op tafel hadden, konden we dan aantonen dat onze vereisten voor informatiebeveiliging gedefinieerd, risicogebaseerd en afdwingbaar zijn? Of zouden we de gaten opvullen met 'wat iedereen weet dat we bedoelden'?

Als het antwoord dichter bij het laatste ligt, moet uw ISMS dat als een zwakte registreren en een wijziging in de formulering, sjablonen of goedkeuringsregels doorvoeren.

Een platform zoals ISMS.online maakt dat veel gemakkelijker te demonstreren. U kunt elke contractclausule koppelen aan de risico's en controles die het ondersteunt, en laten zien hoe A.5.20 wordt geïmplementeerd via echte overeenkomsten in plaats van te vertrouwen op geheugen of informele aantekeningen.

Hoe past A.5.20 bij A.5.19 en A.5.21 voor een MSP?

De drie bedieningselementen vormen een enkele beveiligingslevenscyclus van derden: met wie u samenwerkt, wat u op papier nodig hebt en hoe u de gelaagde toeleveringsketen beheert die uw diensten levert.

Hoe moet een MSP de A.5.19–A.5.21-keten bekijken?

Voor de meeste MSP's ziet het patroon er als volgt uit:

A.5.19 – leverancierslevenscyclus:

Hoe u leveranciers selecteert, beoordeelt, goedkeurt, aan boord haalt, controleert en indien nodig weer verlaat, inclusief criteria, due diligence en periodieke beoordelingen.

A.5.20 – contractuele informatiebeveiliging:

Waar deze verwachtingen worden omgezet in bindende verplichtingen in hoofdovereenkomsten voor dienstverlening (MSA's), werkomschrijvingen (SoW's), SLA's, DPA's en beveiligingsschema's.

A.5.21 – ICT-toeleveringsketen en privacyrisico:

Hoe u gelaagde providers (cloudplatforms, gespecialiseerde tools, onderaannemers) controleert en bewaakt en hoe zij omgaan met persoonsgegevens en gevoelige gegevens.

In de dagelijkse praktijk is A.5.20 de brug tussen uw risicovisie en uw juridische positie:

Uw leveranciersregister en risicobeoordelingen (A.5.19) Beschrijf het risico en de controles waarop u wilt vertrouwen.
Uw contracten (A.5.20) formeel vastleggen wie welke controles moet uitvoeren en wat er gebeurt als dat niet gebeurt.
Uw toezicht op de toeleveringsketen (A.5.21) controleert of de werkelijkheid overeenkomt met zowel het ISMS als het contract, inclusief gegevensstromen en onderaannemers.

Auditors en grote klanten zullen deze vanzelfsprekend op een rij zetten. Als uw risicoregister zegt dat een cloudprovider "kritiek, hoog risico" is, maar het contract alleen algemene taal bevat over "redelijke beveiliging", dan zullen ze dat ook benoemen.

Met ISMS.online kunt u al deze punten op één plek samenbrengen: leveranciersrecords gekoppeld aan risico's, controlemaatregelen en specifieke contractclausules. Dat betekent dat wanneer iemand vraagt: "Hoe beheert u uw subverwerkers onder A.5.21?", u de leveranciers, contracten, controlemaatregelen en beoordelingscyclus samen kunt weergeven in plaats van dat u uit uw hoofd hoeft te antwoorden.

Hoe kunt u ISO 27001 A.5.20 omzetten in een praktische set MSP-contractclausuleonderwerpen?

Je maakt A.5.20 praktisch door een korte, niet-onderhandelbare checklist van beveiligingsonderwerpen Dat moet altijd in overweging worden genomen, waarna u beslist waar elk onderwerp doorgaans in uw contractpakket wordt opgenomen.

Daarmee wordt elke nieuwe deal of verlenging een oefening in het toepassen van een patroon, in plaats van het bedenken van formuleringen onder druk van een deadline.

Wat hoort er op de standaard A.5.20-checklist van een MSP?

De meeste MSP's komen tot een kernlijst die in de volgende trant is opgesteld:

Toepassingsgebied en toegestaan gebruik: – welke diensten, systemen en gegevens binnen het toepassingsgebied vallen; wat de andere partij wel en niet mag doen; eventuele geografische of wettelijke grenzen.
Toegangscontrole: – hoe identiteiten en accounts worden aangemaakt, goedgekeurd, gecontroleerd en verwijderd; omgang met bevoorrechte toegang; MFA-verwachtingen.
Logging en monitoring: – minimale verwachtingen voor logboekregistratie, bewaartermijnen en hoe u logboeken kunt verkrijgen voor onderzoeken of audits.
Kwetsbaarheid en veranderingsmanagement: – verwachtingen ten aanzien van patches en openbaarmaking van kwetsbaarheden; voorafgaande kennisgeving van materiële wijzigingen die van invloed kunnen zijn op de beveiliging of beschikbaarheid.
Probleembehandeling: – wat als incident wordt beschouwd, triggers voor meldingen en tijdschema’s, vereiste inhoud voor meldingen, escalatiepaden en verwachtingen ten aanzien van gezamenlijk onderzoek.
Bedrijfscontinuïteit en noodherstel: – toepasselijke RTO/RPO's, back-upfrequentie en -testen, failoververwachtingen waarbij beschikbaarheid er echt toe doet.
Onderleveranciers: – wanneer er gebruik mag worden gemaakt van andere aanbieders, wat er moet worden bekendgemaakt of goedgekeurd en hoe zij aan uw beveiligings- en privacyvereisten moeten voldoen.
Gegevensbescherming en privacy: – verwerkingsinstructies, categorieën van gegevens, locaties en overdrachten, ondersteuning voor rechten van betrokkenen en meldingen van inbreuken.
Bewaring, retournering en verwijdering van gegevens: – hoe lang gegevens worden bewaard, wat er gebeurt bij het verlaten van de database, hoe het veilig verwijderen wordt uitgevoerd en aangetoond.
Zekerheid en toezicht: – welke bewijsstukken u daadwerkelijk kunt opvragen en waarop u kunt vertrouwen (certificeringen, rapporten, attestatiebrieven, antwoorden op gerichte vragenlijsten) en hoe vaak.

Het is handig om een eenvoudig beeld te schetsen van waar deze zich meestal bevinden:

Onderwerpgebied	Typische contractuele woning voor een MSP
Toepassingsgebied, toegestaan gebruik	MSA / SoW
Toegang, logging, monitoring	Beveiligingsschema / technische bijlage
Kwetsbaarheid, verandering, incidenten	Beveiligingsschema / SLA
Continuïteit, DR	Beveiligingsschema / SLA
Onderleveranciers, gegevensbescherming	Beveiligingsschema + DPA
Bewaring, retournering, verwijdering	Beveiligingsschema + uitgangsbepalingen in MSA
Zekerheid en toezicht	Beveiligingsschema / governance-secties

Zodra dat patroon is vastgelegd, kunt u interne checklists opstellen en de stappen daaromheen evalueren. ISMS.online kan vervolgens elk onderwerp koppelen aan de relevante leveranciers, risico's en controles, zodat bijvoorbeeld een incidentmeldingsrisico u automatisch terugleidt naar de relevante clausules en betrokken contracten.

Hoe kan een MSP een herbruikbare A.5.20-contractbasis ontwerpen die ook in echte onderhandelingen standhoudt?

Een werkbare aanpak is om een modulaire contractstructuur en onderhoud een getagde clausulebibliotheek die naast uw ISMS staat, met duidelijke regels over wanneer en hoe u de formulering kunt variëren.

Het doel is om op een consistente manier uit te kunnen leggen waarom uw contracten eruitzien zoals ze eruitzien en hoe ze uw risicohouding ondersteunen, zelfs na zware onderhandelingen.

Hoe ziet een modulaire A.5.20-basislijn eruit voor MSP's?

Veel MSP's komen tot een structuur als deze:

A master serviceovereenkomst (MSA) voor overkoepelende juridische termen, aansprakelijkheid, eigendom en verantwoordelijkheden op hoog niveau.
Werkbeschrijvingen (SoW's): die services, relevante systemen en gegevens, locaties en eventuele klant specifieke vereisten of variaties definiëren.
A serviceniveau bijlage het vaststellen van doelstellingen voor beschikbaarheid, respons en oplossing, met inbegrip van de gevallen waarin deze de beveiliging ondersteunen (bijvoorbeeld responstijden bij incidenten).
Een toegewijde beveiligingsschema die de thema's A.5.19 t/m A.5.21 op één plek samenbrengt met op resultaten gebaseerde taal, zodat u de verwachtingen kunt bijwerken zonder de hele MSA te herschrijven.
Wanneer persoonsgegevens worden verwerkt, gegevensverwerkingsovereenkomst (DPA) die verwijst naar en aansluit bij het beveiligingsschema, in plaats van het te dupliceren of tegen te spreken.

Achter die structuur onderhoudt u een interne clausulebibliotheek waarbij elke clausule is gemarkeerd met:

De beveiligingsonderwerp het gaat over (bijvoorbeeld toegangsbeoordelingen, tijdlijnen voor incidenten, openbaarmaking van informatie aan onderaannemers).
De ISO 27001 en gerelateerde controles Het ondersteunt vooral A.5.19, A.5.20 en A.5.21.
Een of meer risiconiveaus – bijvoorbeeld standaard, belangrijke en kritieke diensten of klanten.

Dit geeft u drie belangrijke hefbomen:

Een set van minimale basislijnposities waar u zelden onder komt (bijvoorbeeld maximale vertragingen bij het melden van incidenten).
Een set van verbeterde varianten klaar voor situaties met een hoger risico, zodat u contracten voor cruciale services kunt versterken zonder te improviseren.
Een set van uitzonderingsregels, met inbegrip van wie afwijkingen van de basislijn kan goedkeuren, welke compenserende maatregelen u verwacht en wanneer die beslissingen worden geëvalueerd.

Als de clausulebibliotheek en het goedkeuringstraject zich in een platform als ISMS.online bevinden, gekoppeld aan uw risicoregister en leveranciersgegevens, kunt u aantonen dat updates van uw A.5.20-basislijn het gevolg zijn van echte wijzigingen (nieuwe bedreigingen, incidenten, wettelijke richtlijnen) in plaats van ad-hocrichtlijnen.

Tijdens onderhandelingen maakt deze structuur de gesprekken ook minder persoonlijk. In plaats van te ruziën over de schrijfstijl, kunnen jij en je gesprekspartner kiezen uit duidelijk gedefinieerde varianten die gekoppeld zijn aan een overeengekomen risicoprofiel, en kun je precies documenteren waarom voor een sterkere of zwakkere optie is gekozen.

Welke informatiebeveiligingsvereisten moeten bijna altijd in MSP-leveranciersovereenkomsten onder A.5.20 worden opgenomen?

Sommige eisen zijn zo fundamenteel dat ze in de wet thuishoren. bijna iedere Leveranciersovereenkomst binnen de scope, ongeacht de contractwaarde of servicecategorie. Deze "always-on" elementen vormen de basis van uw A.5.20-implementatie.

Wat hoort doorgaans thuis in de 'always-on' A.5.20-laag van een MSP?

De meeste MSP's kiezen voor een beknopte lijst die alleen bij uitzondering en met een duidelijke rechtvaardiging wordt gewijzigd:

Vertrouwelijkheid en acceptabel gebruik:

Plichten om uw informatie en klantgegevens te beschermen, plus illustratieve voorbeelden van verboden gedrag zoals ongeoorloofd kopiëren, openbaarmaking of datamining.

Afstemming op uw belangrijkste beleid:

Een vereiste om specifieke beleidsregels voor informatiebeveiliging, acceptabel gebruik en, waar relevant, veilige ontwikkeling te volgen die u publiceert en onderhoudt via uw ISMS.

Toegangs- en identiteitscontrole:

Verwachtingen voor het gebruik van sterke authenticatie, het afdwingen van de laagste mate van privileges, het beoordelen van toegang op een vast ritme en het onmiddellijk intrekken van toegang wanneer deze niet langer nodig is.

Melding van incidenten en medewerking:

Duidelijke criteria voor wat er gemeld moet worden, tijdschema's voor eerste en vervolgmeldingen, minimale inhoud (tijdlijn, impact, getroffen gegevens, inperkingsmaatregelen) en hoe gezamenlijke onderzoeken en externe communicatie worden afgehandeld.

Transparantie van onderleveranciers:

Verplichtingen om materiële onderleveranciers bekend te maken, belangrijke wijzigingen vooraf te melden en materieel vergelijkbare beveiligings- en privacyvoorwaarden aan die partijen op te leggen.

Voorwaarden voor gegevensbescherming:

Wanneer het om persoonsgegevens gaat, gelden voorwaarden die aansluiten bij uw wettelijke verantwoordelijkheden (bijvoorbeeld onder de AVG of CCPA) en bij uw eigen privacy- en bewaarbeleid.

Gegevensretourneren en veilig verwijderen:

Instructies over hoe gegevens worden geretourneerd, overgedragen of veilig worden verwijderd aan het einde van de relatie of dienst, en een redelijke verwachting van bewijs dat de verwijdering heeft plaatsgevonden.

Verzekeringsmechanismen:

Afgesproken manieren waarop u de beveiligingshouding kunt controleren, zoals ISO 27001-certificaten, SOC 2-rapporten, korte vragenlijsten of formele verklaringen, en hoe vaak u deze zult ontvangen.

Een nuttige vraag om in gedachten te houden is:

Stel dat er vanavond een ernstig incident plaatsvindt bij deze leverancier, hebben we dan voldoende contractuele verplichtingen om snel te handelen, aan te dringen op passende maatregelen en ons toezicht uit te leggen aan klanten of toezichthouders?

Als u twijfelt, ontbreekt mogelijk een van deze altijd actieve aspecten of is deze te zwak. Door ze vast te leggen als onderdeel van uw basislijn en ze in te bedden in standaardsjablonen, vermindert u de afhankelijkheid van de instincten van individuele onderhandelaars en geeft u auditors en klanten een duidelijk verhaal.

ISMS.online kan dit verder versterken door deze basisclausules te koppelen aan leveranciersinvoer, risico's en managementbeoordelingen. Zo kunt u aantonen dat de basislaag bestaat, wordt toegepast en wordt geëvalueerd wanneer de omstandigheden veranderen.

Hoe kan een MSP ervoor zorgen dat de basislijn van zijn A.5.20-contract overeenkomt met het ISMS en dat deze in de loop van de tijd eenvoudig te bewijzen is?

U houdt A.5.20 op één lijn door de contractformulering als volgt te behandelen: onderdeel van uw beveiligingsbeheer, met benoemde eigenaren, geplande beoordelingen en duidelijke koppelingen naar leveranciersbeheer en risicobehandeling, in plaats van een afzonderlijke juridische oefening die in de loop van de tijd verschuift.

Hoe ziet duurzaam A.5.20-bestuur eruit voor een MSP?

Zelfs bij kleinere MSP's maakt een eenvoudig bestuursmodel een groot verschil:

Informatiebeveiliging:

Definieert beveiligingsverwachtingen, always-on elementen en niet-onderhandelbare posities in duidelijke taal, gekoppeld aan ISO 27001-controles en andere raamwerken waarop u vertrouwt.

Juridisch of contractenteam:

Is verantwoordelijk voor de feitelijke formulering, adviseert tijdens onderhandelingen en registreert overschrijdingen of versoepelingen, inclusief de onderbouwing en eventuele compenserende maatregelen.

Leveranciersmanagers of service-eigenaren:

Controleer of leveranciers in de praktijk aan hun verplichtingen voldoen, verzamel bewijs (certificaten, rapporten, reacties) en geef aan wanneer niet aan de verwachtingen wordt voldaan.

Interne audit of gelijkwaardig:

Neem regelmatig een aantal contracten op, vergelijk ze met uw basislijn, leveranciersregister en risicoregistraties en beveel verbeteringen aan.

Deze rollen volgen vervolgens een voorspelbaar ritme:

Contractsjablonen en clausulebibliotheken worden beoordeeld als onderdeel van uw risicobeoordelings- en managementbeoordelingscycli, dus incidenten, bijna-ongelukken en wetswijzigingen leiden tot gedoseerde aanpassingen in de formulering.

Een centraal register toont welke contracten welke basisversie gebruikenwelke leveranciers zich in welke risicoklasse bevinden en waar u afwijkingen hebt geaccepteerd, inclusief een registratie van wie deze heeft goedgekeurd en waarom.

Kort draaiboeken en checklists Helpt verkoop-, inkoop- en accountteams te begrijpen welke voorwaarden verplicht zijn, waar ze flexibiliteit hebben en wanneer ze beveiligings- of juridische specialisten moeten inschakelen.

Op zeer kleine schaal kunt u een groot deel hiervan samen met documenten en gedeelde mappen bewaren. Naarmate uw klantenbestand, leverancierslijst en frameworkdekking groeien, wordt dat al snel kwetsbaar.

Met ISMSonline kunt u leveranciersinventarissen, contractbasislijnen, controles, risico's, audits en managementbeoordelingen in één overzicht samenbrengen. Wanneer iemand bijvoorbeeld vraagt:

“Hoe zorgt u ervoor dat A.5.20 consequent wordt toegepast op kritische leveranciers?”
“Waar registreert u uitzonderingen op uw standaardposities?”
“Hoe worden contractwijzigingen verwerkt in uw risicoregister?”

U kunt antwoorden met actueel, gekoppeld bewijsmateriaal in plaats van een lappendeken aan bestanden.

Die mate van structuur geeft klanten, auditors en toezichthouders het signaal dat u de beveiliging van leveranciers en klanten beheert als een gemanagede discipline. Het laat zien dat uw contracten, uw ISMS en uw dagelijkse gedrag allemaal op elkaar zijn afgestemd, wat het op zijn beurt makkelijker maakt om het soort klanten te winnen en te behouden dat zich het meest bekommert om risico's van derden.