Leveranciers- en derdenrisicomanagement voor startups
Leveranciersrisicomanagement betekent weten welke derden bij je data kunnen, bepalen hoeveel zekerheid je van elk van hen nodig hebt, en dat oordeel actueel houden. ISO 27001 dekt dit af in A.5.19 tot A.5.23 — leveranciersrelaties, beveiliging in leveranciersovereenkomsten, de ICT-toeleveringsketen, monitoring en wijzigingsbeheer, en clouddiensten — terwijl SOC 2 het onder CC9 behandelt. Voor een startup is de werkbare versie: één leveranciersregister, drie niveaus op basis van wat een leverancier daadwerkelijk kan benaderen, bewijsverzoeken die passen bij het niveau, en een jaarlijkse hercontrole die verlopen rapporten en stilletjes gewijzigde subverwerkers opspoort.
Leveranciersrisicomanagement is de praktijk van weten welke derden bij je data kunnen, bepalen hoeveel zekerheid je van elk van hen nodig hebt, en dat oordeel actueel houden. Je erft het beveiligingsniveau van je leveranciers, of je het nu beoordeelt of niet — de enige variabele is of je erachter komt op jouw moment of midden in een incident.
Voor een startup die draait op dertig SaaS-tools en één cloudprovider klinkt dit als een programma waar je de mensen niet voor hebt. Dat is het niet. De werkbare versie is één register, drie niveaus en een jaarlijkse ronde.
Waar de frameworks dit onderbrengen
ISO 27001 verdeelt de leverancierseisen over vijf beheersmaatregelen in Bijlage A, en daarom voelt het onderwerp groter dan het is:
- A.5.19 — Informatiebeveiliging in leveranciersrelaties. Definieer en pas processen toe om de risico's van het gebruik van leveranciers te beheersen.
- A.5.20 — Informatiebeveiliging opnemen in leveranciersovereenkomsten. De beveiligingseisen horen in het contract, niet alleen in de beoordeling.
- A.5.21 — Beheer van informatiebeveiliging in de ICT-toeleveringsketen. Jouw leveranciers hebben leveranciers.
- A.5.22 — Monitoren, beoordelen en wijzigingsbeheer van leveranciersdiensten. Zekerheid is geen eenmalige gebeurtenis.
- A.5.23 — Informatiebeveiliging bij het gebruik van clouddiensten. Nieuw in de revisie van 2022 en het meest relevant voor een cloud-native startup — zie de mapping van beheersmaatregelen van 2013 naar 2022 voor hoe de structuur van Bijlage A veranderde.
SOC 2 behandelt hetzelfde terrein onder Common Criteria CC9, dat gaat over risicobeperking inclusief leveranciers- en zakenpartnerrisico. In de praktijk voldoet één proces aan beide. Operationeel hoort leveranciersbeheer bij hoofdstuk 8 uitvoering — het is een proces dat je draait, geen document dat je opbergt.
Stap 1: bouw het register uit de facturatie, niet uit je geheugen
Het leveranciersregister is de basis, en de snelste eerlijke manier om het te bouwen is twaalf maanden aan kaart- en factuurtransacties exporteren uit de financiële administratie. Je geheugen levert de lijst met tools die je leuk vindt; de facturatie levert de lijst met tools die je hebt — inclusief die ene die één team aanschafte zonder het te melden.
Leg dat naast je SSO-applicatielijst en de marketplace-abonnementen van je cloudprovider. Alles wat in de facturatie opduikt maar niet in het register staat, is óf shadow IT die je onder beheer moet brengen óf een abonnement dat je kunt opzeggen, en beide uitkomsten zijn nuttig.
Minimale velden per leverancier: naam, geleverde dienst, interne eigenaar, welke data het raakt, of er persoonsgegevens in zitten, niveau, aanwezig zekerheidsbewijs met datum, verlengingsdatum van het contract en datum van de laatste beoordeling.
Stap 2: deel in op wat ze echt kunnen bereiken
Indelen op uitgaven is de gebruikelijke fout. Een tool van $30 per maand met toegang tot de productiedatabase is een groter risico dan een recruitmentplatform van $50,000. Deel in op toegang:
| Niveau | Definitie | Verwachte zekerheid |
|---|---|---|
| Niveau 1 — Kritiek | Slaat klantdata of productiesystemen op, verwerkt ze of kan ze benaderen. Cloudhosting, databaseplatforms, supporttools, alles met een API-sleutel naar productie. | Actueel SOC 2 Type II-rapport of ISO 27001-certificaat; verwerkersovereenkomst waar persoonsgegevens in het spel zijn; lijst met subverwerkers; gedocumenteerde beoordeling van het rapport zelf. |
| Niveau 2 — Belangrijk | Bevat bedrijfs- of medewerkersgegevens maar geen klantdata — HR, finance, interne communicatie. | Attestatierapport of certificaat indien beschikbaar; doorlezen van de securitypagina; verwerkersovereenkomst waar van toepassing; lichtere gedocumenteerde check. |
| Niveau 3 — Laag | Geen toegang tot gevoelige data. Designtools, hulpmiddelen voor één gebruiker, marketingsites. | Vermelding in het register en een eigenaar. Geen formele beoordeling. |
Drie niveaus is genoeg. Modellen met vijf niveaus zien er grondig uit en leveren in een bedrijf van tien mensen vooral discussies op over de vraag of iets een 3 of een 4 is.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Stap 3: vraag om bewijs dat iets betekent
Voor leveranciers van Niveau 1 is het verzoek eenvoudig: hun meest recente SOC 2 Type II-rapport of ISO 27001-certificaat met de Verklaring van Toepasselijkheid, plus een verwerkersovereenkomst en lijst met subverwerkers als er persoonsgegevens bij betrokken zijn.
Wat telt, is wat je daarna doet. Een rapport verzamelen en ongelezen wegzetten is een beheersmaatregel die alleen op papier bestaat — en dat is precies waar auditors op doorvragen als ze willen weten hoe je een leverancier hebt beoordeeld. Controleer bij binnenkomst minstens of de rapportageperiode de tijd dekt waarin je daadwerkelijk op de leverancier vertrouwde, of de scope de dienst dekt die jij gebruikt en niet een andere productlijn, of het oordeel zonder voorbehoud is, en of de genoteerde uitzonderingen er zijn waarmee je kunt leven. Lees daarna de complementary user entity controls: de dingen die jij moet doen om de beheersmaatregelen van de leverancier te laten werken — dit is het onderdeel dat klanten het vaakst overslaan. Onze gids over het lezen van het SOC 2-rapport van een leverancier loopt het hele document door.
Leg voor elke Niveau 1-leverancier een korte schriftelijke conclusie vast: wat je hebt bekeken, wat je hebt gevonden, wat je hebt geaccepteerd. Twee zinnen is genoeg. Zonder dat heb je een archiefkast en geen beoordeling.
Stap 4: zet de eisen in de overeenkomst
A.5.20 bestaat omdat een beoordeling zonder contractuele basis je niets geeft om af te dwingen. Voor Niveau 1-leveranciers zijn de bepalingen die je zwart op wit wilt hebben: meldplicht bij datalekken met een vastgelegde termijn, het recht op geactualiseerde zekerheidsrapporten, melding van wijzigingen in subverwerkers, teruggave en verwijdering van data bij beëindiging, en geheimhoudingsverplichtingen.
Realistisch gezien onderhandelt een startup van vijf mensen geen maatwerkvoorwaarden met een hyperscaler — je accepteert de standaard verwerkersovereenkomst en noteert die acceptatie in het register. Dat is een legitieme uitkomst, en het vastleggen van de beslissing onderscheidt een geaccepteerd risico van een over het hoofd gezien risico.
Stap 5: houd de keten van subverwerkers in de gaten
Jouw leveranciers hebben leveranciers, en hun wijzigingen worden jouw wijzigingen. Daar gaat A.5.21 precies over. Praktische versie voor een klein team: abonneer je op de meldingen over gewijzigde subverwerkers die je Niveau 1-leveranciers aanbieden, en noteer in het register waar de kritieke afhankelijkheden van een leverancier overlappen met die van jou.
Die overlap verdient een expliciete blik. Als je hosting, je monitoring en je e-mailbezorging uiteindelijk allemaal op dezelfde cloudprovider in dezelfde regio rusten, heb je een concentratierisico dat geen van de afzonderlijke beoordelingen naar boven haalt — en dat hoort thuis als vermelding in je risicoregister, niet alleen in je leverancierslijst.
Stap 6: controleer jaarlijks, en bij wijzigingen
A.5.22 vraagt om monitoring en beoordeling in de tijd, want zekerheid slijt. SOC 2-rapporten dekken een vaste periode en verouderen; certificaten verlopen; leveranciers worden overgenomen; producten veranderen van architectuur.
Een jaarlijkse ronde langs de leveranciers van Niveau 1 en Niveau 2 is een redelijke basis, aangevuld met beoordelingen naar aanleiding van gebeurtenissen: als een leverancier wordt overgenomen, een openbaar gemaakt datalek heeft, zijn subverwerkers wezenlijk wijzigt, of als jouw eigen gebruik uitbreidt naar gevoeliger data. Zet die ronde in dezelfde kalender als je andere periodieke controles — zie de checklist voor monitoring het hele jaar door.
Offboarding verdient dezelfde discipline als onboarding: als je stopt met een leverancier, bevestig dan de verwijdering van data, trek API-sleutels en integraties in, en sluit de registervermelding af met een datum. Slapende integraties met werkende inloggegevens zijn een terugkerende auditbevinding en een reëel risico.
De kern
Bouw het register uit de facturatie zodat het eerlijk is, deel in op toegang in plaats van op uitgaven, vraag Niveau 1-leveranciers om echte zekerheid en lees die ook daadwerkelijk, zet de beveiligingsbepalingen in de overeenkomst, en controleer één keer per jaar opnieuw. Dat is een leveranciersrisicoprogramma dat een klein team echt kan draaien — en het voldoet aan zowel A.5.19–A.5.23 als CC9 zonder dat je er iemand voor hoeft aan te nemen.
Verder lezen: hoe je het SOC 2-rapport van een leverancier leest, wanneer je eigen SOC 2 de moeite waard wordt nu je aan de andere kant van deze vragenlijsten staat, of bekijk hoe leveranciersbeoordeling in AuditBadger het register, het bewijs en de beoordelingsdata op één plek houdt.
