Third-party risk management: grip op leveranciersrisico

Wat is third-party risk management?

Third-party risk management, vaak afgekort tot TPRM, is de manier waarop je risico's van externe partijen structureel beoordeelt en beheerst.

Dat gaat breder dan cybersecurity.

Denk ook aan:

• continuïteit;
• privacy;
• compliance;
• financiën;
• concentratierisico;
• reputatie.

Voor Kynexis ligt de nadruk vooral op digitale afhankelijkheden.

Begin niet met iedere leverancier even zwaar behandelen

Een cateraar en je centrale SaaS-platform vragen niet dezelfde beoordeling.

Classificeer leveranciers bijvoorbeeld op:

• toegang tot gevoelige gegevens;
• toegang tot systemen;
• belang voor kritieke processen;
• vervangbaarheid;
• herstelimpact;
• onderaannemers;
• geografische/juridische afhankelijkheden.

Dan ontstaat een eenvoudige indeling zoals:

• kritiek;
• hoog;
• regulier;
• laag.

De diepgang van beoordeling volgt daarna uit de classificatie.

Wat wil je van een kritieke leverancier weten?

Voor een kritieke IT-leverancier kijk ik minimaal naar vijf dingen.

1. Wat levert de partij precies?

Welke processen, systemen en gegevens zijn afhankelijk?

2. Welke toegang heeft de partij?

Heeft de leverancier beheerrechten, API-toegang of toegang tot persoonsgegevens?

3. Welke beveiliging is afgesproken?

Welke eisen staan in contract, SLA, DPA of security annex?

4. Welk bewijs is beschikbaar?

Bijvoorbeeld certificeringen, assurance, auditrapporten, testresultaten of KPI's.

5. Wat gebeurt bij uitval?

Hoe snel wordt hersteld, wie beslist en wat zijn alternatieven?

Contracten zijn belangrijk, maar niet voldoende

Een contract kan uitstekende beveiligingsclausules bevatten.

De interessante vraag is daarna:

hoe weet je dat de leverancier zich eraan houdt?

Daarvoor kun je bijvoorbeeld gebruiken:

• ISO 27001-certificaat met juiste scope;
• SOC-rapportage;
• ISAE-rapportage;
• penetratietest-samenvatting;
• auditrapport;
• SLA-rapportage;
• incidentstatistiek;
• restore-test;
• leveranciersreview.

Lees vooral de scope en uitzonderingen.

Een certificaat op concernniveau zegt weinig wanneer jouw specifieke dienst buiten scope valt.

Wie beoordeelt leveranciersrisico?

Dat is zelden alleen inkoop.

Afhankelijk van de leverancier kunnen betrokken zijn:

• business owner;
• IT;
• security;
• privacy;
• inkoop;
• finance;
• juridische functie;
• risk/control.

Ik vind één eigenaar per kritieke leverancier belangrijk.

Anders blijft de leverancier “van iedereen” en daarmee vaak van niemand.

Maak risico-eigenaarschap expliciet

Een leverancier kan een maatregel uitvoeren.

De organisatie zelf moet bepalen welk risico zij accepteert.

Bijvoorbeeld:

Een leverancier biedt alleen dagelijkse back-up terwijl de organisatie maximaal vier uur gegevensverlies acceptabel vindt.

Dan zit er een verschil tussen behoefte en dienst.

Dat vraagt een besluit.

Niet alleen een technisch ticket.

Wat doe je met assurance?

Assurance is waardevol wanneer je het gebruikt.

Ik zie nog geregeld dat een organisatie een ISO-certificaat of SOC-rapport ontvangt en dit daarna archiveert.

Lees minimaal:

• scope;
• periode;
• uitzonderingen;
• bevindingen;
• complementary controls;
• onderaannemers;
• relevante beperkingen.

Vraag daarna:

wat betekent dit voor ons eigen risico?

Denk ook aan de keten achter de leverancier

Je directe leverancier gebruikt vaak weer andere leveranciers.

Cloudhosting.

Authenticatie.

Datacenters.

Supportpartijen.

Softwarecomponenten.

Bij kritieke diensten wil je daarom weten:

• welke essentiële onderaannemers bestaan;
• waar concentratierisico zit;
• welke wijzigingen gemeld worden;
• welke exitmogelijkheden je hebt.

Incidenten bij leveranciers

Leg vooraf vast:

• hoe snel incidenten gemeld worden;
• welke informatie je krijgt;
• wie contactpersoon is;
• hoe updates verlopen;
• wanneer forensische informatie beschikbaar komt;
• hoe privacy- of wettelijke meldingen worden ondersteund.

Tijdens een groot incident is “we zoeken het contract erbij” te laat.

Continuïteit en exit

Een kritieke leverancier beoordeel ik ook op de vraag:

hoe komen we hier weg als het moet?

Denk aan:

• exporteerbaarheid van data;
• eigendom van data;
• documentatie;
• overdracht;
• escrow waar relevant;
• alternatieve leveranciers;
• herstel bij faillissement;
• opzegtermijnen;
• ondersteuning bij exit.

Een goede exitstrategie maakt afhankelijkheid zichtbaar.

Hoe vaak beoordeel je leveranciers?

Niet iedere leverancier ieder kwartaal.

Werk risicogestuurd.

Bijvoorbeeld:

• kritieke leveranciers jaarlijks plus bij grote wijzigingen;
• hoge risico's periodiek;
• overige leveranciers bij contractverlenging of relevante verandering.

Triggers kunnen zijn:

• groot incident;
• overname;
• gewijzigde dienstverlening;
• nieuwe onderaannemer;
• verslechterde SLA;
• veranderde regelgeving.

Wat wil bestuur/directie zien?

Geen spreadsheet met honderd leveranciers.

Ik zou een compact beeld willen:

• welke leveranciers kritiek zijn;
• welke risico's het grootst zijn;
• waar assurance ontbreekt;
• welke incidenten spelen;
• welke contractuele gaten bestaan;
• welke verbeteracties achterlopen;
• waar concentratierisico zit.

Voor toezicht is vooral de vraag relevant of het bestuur deze afhankelijkheden aantoonbaar kent en beheerst.

Een praktisch leveranciersdashboard

Dat is voor mij zinvoller dan een generieke leveranciersscore.

Mijn uitgangspunt

Third-party risk management hoeft geen enorm complianceprogramma te worden.

Begin met de leveranciers die je organisatie echt kunnen raken.

Weet:

• waarvan je afhankelijk bent;
• welk risico daarbij hoort;
• welk bewijs je hebt;
• welke afspraken ontbreken;
• wie eigenaar is.

Dan ontstaat grip.

Wil je die analyse voor je belangrijkste leveranciers verdiepen? Lees dan ook:

Hoe beoordeel je een kritieke IT-leverancier?

[Interne link: /kritieke-it-leveranciers-beoordelen/ zodra aanwezig]