Tredjepartsrisiko på tværs af GDPR, NIS2 og DORA

Den samme leverandør kan skabe forpligtelser inden for databeskyttelse, cybersikkerhed og operationel modstandsdygtighed. En lønudbyder behandler personoplysninger; en udbyder af administrerede tjenester har privilegeret adgang; en cloudplatform understøtter forretningskritiske applikationer. Nogle gange gør én leverandør alle tre ting.

En fælles leverandørregistrering hjælper teamene med at koordinere vurderingen, forudsat at hver forpligtelse forbliver identificerbar. For en CTO er den praktiske udfordring at forbinde kontraktlige forpligtelser med den tekniske virkelighed: hvad leverandøren kan få adgang til, hvordan fejl forplanter sig, hvilke kontroller der er dokumenteret, og om organisationen kan genoprette driften eller forlade leverandøren.

Fastlæg anvendelsesområdet, før vurderingerne kombineres

Disse retsakter overlapper, men de gælder ikke på samme måde for alle organisationer eller leverandører.

Artikel 28 i GDPR kræver, at dataansvarlige anvender databehandlere, der kan stille tilstrækkelige garantier. En aftale efter artikel 28 er ikke relevant, blot fordi en leverandør modtager data: Fastlæg først den faktiske rolle i behandlingen.

Artikel 20–23 i NIS 2-direktivet omhandler ledelsens tilsyn, foranstaltninger til risikostyring og indberetning af væsentlige hændelser. NIS2 er et direktiv, der gennemføres i national lovgivning, så anvendelsesområde og procedurer kræver kontrol for den enkelte jurisdiktion.

DORA har fundet anvendelse siden den 17. januar 2025. Forordningen omfatter primært bestemte finansielle enheder; almindelige IKT-leverandører kan blive mødt med kontraktlige krav fra kunder, mens udpegede kritiske IKT-udbydere har en særskilt tilsynsordning. For omfattede finansielle enheder fungerer DORA som sektorspecifik EU-ret på de relevante NIS2-områder. Duplikér ikke automatisk begge kontrolsæt.

Opbyg registreringen omkring afhængigheden

Begynd med tjenesten, ikke med leverandørspørgeskemaet. Én leverandør kan levere flere tjenester med forskellige data, forskellig adgang og forskellig operationel betydning.

Som et praktisk grundlag kan I registrere:

• Tjenesten, leverandørens juridiske enhed, forretningsejeren, den tekniske ejer og reviewerne.
• Understøttede funktioner, systemer, integrationer og privilegeret adgang.
• Kategorier af personoplysninger, behandlingsformål, placeringer og underdatabehandlere.
• Krav til tilgængelighed, genopretningsmål og acceptabel afbrydelse.
• Underliggende udbydere, kontraktlige afhængigheder og realistiske alternativer.
• Gældende forpligtelser, datoer for dokumentation, uafklarede mangler og beslutninger.

Identificér, hvilke funktioner der vil svigte eller blive forringet efter en kompromittering eller et nedbrud. En leverandør, der kun opbevarer få følsomme data, kan stadig kontrollere autentificering eller deploymentpipelines. Omvendt kan en tjeneste med lav risiko for tilgængeligheden eksponere meget følsomme personoplysninger.

Hold disse dimensioner adskilt i stedet for at samle dem i én uforklaret score for »høj risiko«. For finansielle enheder, der er omfattet af DORA, skal denne operationelle fortegnelse forbindes med det påkrævede informationsregister over aftaler om IKT-ydelser; en generisk leverandørliste er ikke nødvendigvis tilstrækkelig.

Genbrug dokumentation uden blindt at genbruge konklusioner

En sikkerhedsrapport, et dataflowkort eller en genopretningstest kan understøtte flere gennemgange. Kontrollér tjenesteomfang, rapporteringsperiode, udeladelser, undtagelser og kundens ansvar, før I støtter jer på den.

En rapport, der dækker leverandørens infrastruktur, dækker f.eks. ikke nødvendigvis supportpersonalets adgang til kunderegistreringer. En dokumenteret backuppolitik viser ikke, at gendannelsen opfylder jeres applikations krav til genopretning.

Vedligehold en matrix, der forbinder dokumentation med spørgsmål:

Et ISO-certifikat eller en SOC 2-rapport understøtter sikkerheden inden for sit omfang; ingen af dem dokumenterer overholdelse af GDPR eller NIS2. Bevar reviewerens begrundelse, ikke kun det uploadede dokument. Vurdering af sikkerhedsdokumentation bør være en gentagelig teknisk gennemgang, ikke et tjek af et mærke.

Omsæt krav til kontrakter og kontroller

Efter artikel 28 i GDPR skal databehandlervilkårene omfatte behandlingens genstand, varighed, karakter og formål, typer af oplysninger og kategorier af registrerede. De omfatter også dokumenterede instrukser, fortrolighed, sikkerhed, betingelser for underdatabehandlere, bistand, sletning eller tilbagelevering samt oplysnings- og auditforpligtelser. Internationale overførsler kræver en særskilt vurdering efter kapitel V; hosting i EU alene afgør ikke spørgsmål om adgang eller videreoverførsel.

Artikel 21 i NIS2 omfatter sikkerhed i forsyningskæden og hensyntagen til direkte leverandørers sårbarheder og cybersikkerhedspraksis. Praktiske kontraktlige forventninger kan omfatte adgangsbegrænsninger, håndtering af sårbarheder, samarbejde ved hændelser og levering af dokumentation. Tilpas dem til tjenesten og de nationale krav i stedet for at behandle én universel klausulpakke som juridisk tilstrækkelig.

Artikel 30 i DORA fastsætter kontraktbestemmelser for IKT-ydelser med yderligere krav til tjenester, der understøtter kritiske eller vigtige funktioner. Gennemgå beskrivelser af tjenester, placeringer, databeskyttelse og gendannelse, bistand, opsigelse og relevante tilsynsrettigheder. Kritiske eller vigtige funktioner kræver særlig opmærksomhed på serviceniveauer, rapportering, beredskabsforanstaltninger, samarbejde om test, auditrettigheder og overgangsordninger.

Kontrollér derefter implementeringen. Hvis en kontrakt lover begrænset administrativ adgang, skal I indhente dokumentation for rolleadskillelse, autentificering, godkendelse og logning. Hvis den lover sletning, skal I fastlægge, hvad der sker med sikkerhedskopier og opbevarede registreringer. Tildel juridiske mangler og tekniske mangler til de relevante reviewere.

Design overdragelser ved hændelser, før en hændelse indtræffer

En leverandørs politik for hændelseshåndtering kan understøtte en sikkerhedsvurdering og samtidig lade underretningspligterne stå uafklarede. Angiv kontaktkanaler, dækning af eskalering, indledende oplysninger, forventninger til opdateringer og ansvaret for at bevare dokumentation.

Efter artikel 33–34 i GDPR underretter en databehandler den dataansvarlige uden unødig forsinkelse. Den dataansvarlige vurderer anmeldelse til tilsynsmyndigheden uden unødig forsinkelse og om muligt senest 72 timer efter at være blevet bekendt med bruddet, medmindre det er usandsynligt, at bruddet indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder. Høj risiko kan kræve underretning af de registrerede, med forbehold af undtagelser. Registrér begrundelsen, når anmeldelse ikke er påkrævet.

NIS2's indberetningsfaser i EU for væsentlige hændelser omfatter en tidlig varsling inden for 24 timer, en underretning inden for 72 timer og som hovedregel en endelig rapport senest en måned efter underretningen; kontrollér nationale og sektorspecifikke regler. DORA har sin egen indberetningsramme for større IKT-relaterede hændelser. Erstat ikke disse vurderinger med ét generelt »brud«-flag for leverandøren.

Som en praktisk anbefaling kan I øve en leverandørhændelse med ufuldstændige oplysninger. Test, om teamene kan fastlægge berørte tjenester, eksponering, operationel konsekvens og beslutninger om indberetning uden at vente på en endelig rapport om grundårsagen.

Gennemgået eksempel: én tjeneste, tre gennemgangsspor

Antag som illustration, at en omfattet finansiel enhed bruger en hostet kundesupportplatform, der behandler personoplysninger og understøtter en funktion, som enheden har klassificeret som kritisk eller vigtig efter DORA.

Leverandøren leverer en erklæringsrapport, en hændelsespolitik og et resumé af en genopretningstest. Sikkerhedsfunktionen konstaterer, at kontrollerne for administrativ adgang er dokumenteret, men at genopretningstesten ikke omfatter kundens integration.

Databeskyttelsesfunktionen identificerer særskilt en uklar proces for ændring af underdatabehandlere og uafklarede overførselsordninger for fjernadgang. DORA-gennemgangen konstaterer, at overgangsbistand og relevante auditbestemmelser kræver opmærksomhed.

Den resulterende handlingsplan er konkret:

• Den tekniske ejer tester genopretning af integrationen og dokumenterer resultatet.
• Databeskyttelsesrevieweren afklarer spørgsmålene om underdatabehandlere og overførsler.
• Jura og indkøb håndterer de kontraktlige mangler.
• Den ansvarlige ejer beslutter, om midlertidig anvendelse er acceptabel, med betingelser og en dato for ny gennemgang.

Dokumentationen genbruges, men ingen af de tre konklusioner udledes af en anden. En bestået sikkerhedsgennemgang lukker ikke manglerne vedrørende databeskyttelse eller modstandsdygtighed.

Overvåg ændringer, koncentration og en gennemførlig exit

Fastlæg gennemgangshyppigheden efter afhængighed og risiko. Udløs yderligere gennemgang efter hændelser, større ændringer af tjenesten, nye underdatabehandlere, ændrede dataplaceringer, ejerskifte eller kontraktfornyelse.

Se under leverandørnavnene: Flere tjenester kan afhænge af den samme cloudregion, identitetsudbyder eller underleverandør. Vurder samtidige afbrydelser, og om det foreslåede alternativ deler den samme afhængighed. Artikel 29 i DORA omhandler udtrykkeligt vurdering af IKT-koncentrationsrisiko.

Vedligehold en proportional exitplan, der dækker dataeksport, migrering, kontinuitet, tilbagekaldelse af adgang og dokumentation for sletning. Test, om eksporten kan bruges, og identificér, hvem der kan drive erstatningsløsningen. En opsigelsesret er mere nyttig, når organisationen faktisk kan udøve den.

Konsekvenserne er også forskellige. GDPR har bødeniveauer, der afhænger af overtrædelsen; NIS2 kræver nationale sanktionsordninger med forskellige lofter for væsentlige og vigtige enheder. DORA-sanktioner over for finansielle enheder afhænger af de gældende ordninger, mens sanktioner i tilsynet med kritiske udbydere er særskilte. Modellér ikke eksponeringen ud fra én formodet universel bøde.

Begynd med én væsentlig afhængighed

Vælg én leverandør, der understøtter en vigtig funktion. Afstem dens tjenestefortegnelse, kontrakter, dokumentation, åbne risici og antagelser om exit. Afslut med navngivne ejere og særskilte, daterede konklusioner for hver gældende forpligtelse.

I Secani kan teams modellere tjenesten og den eksterne udbyder, knytte krav og kontroller til dokumentation og følge op på mangler som opgaver med ejere. Beslutninger gennemgået af mennesker, kildelinks, kommentarer og tidsstempler bevarer begrundelsen. Det understøtter en fælles leverandørkontekst uden at skjule de særskilte vurderinger af databeskyttelse, sikkerhed og modstandsdygtighed.