⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Ændringsstyring for underdatabehandlere hos SaaS- og MSP-udbydere

Igor Petreski
14 min read
Arbejdsgang for ændringsstyring for underdatabehandlere i forhold til GDPR DORA ISO 27701 og leverandørrisiko

Sarah, CISO hos en hurtigt voksende FinTech-SaaS-udbyder, åbnede noget, der lignede en rutinemæssig serviceopdatering fra en kritisk infrastrukturleverandør. Under “serviceoptimeringer” stod der én sætning, som ændrede hendes uge:

“For at forbedre analyseydelsen migreres databehandlingsworkloads til vores nye partner, DataCrunch Analytics, med virkning om 30 dage.”

Tredive dage. En ny analysepartner. Et hurtigt tjek viste, at udbyderen var etableret uden for EU.

Engineering-teamet så en rutinemæssig leverandørforbedring. Indkøb antog, at den eksisterende aftale dækkede forholdet. Customer Success havde ikke planlagt nogen underretningskampagne. Juridisk afdeling havde ikke gennemgået konsekvenserne for dataoverførsel. Sarah så straks det reelle problem: hendes virksomhed fungerede som databehandler for hundredvis af finansielle institutioner i Europa. Disse kunder var dataansvarlige efter GDPR. Nogle havde forhandlet sig til forudgående underretning om nye underdatabehandlere. Nogle havde indsigelsesrettigheder. Flere havde DORA-drevne forpligtelser vedrørende outsourcing og IKT-tredjepartsrisiko. Enkelte havde strenge lokationserklæringer, som ikke uden videre kunne ændres.

Det er i dette øjeblik, mange SaaS-udbydere, MSP’er, MSSP’er og cloudtjenesteudbydere opdager, at styring af underdatabehandlere ikke er en administrativ databeskyttelsesopgave. Det er leverandørrisikostyring, kontraktuel efterlevelse, operationel robusthed, kundekommunikation og revisionsbevismateriale samlet i én arbejdsgang.

En offentlig side med underdatabehandlere er ikke nok. En fodnote fra en leverandør er ikke nok. Et sikkerhedsspørgeskema er ikke nok. En forsvarlig proces skal vise, hvem der vurderede underdatabehandleren, hvilke data der behandles, hvilke kunder der er berørt, hvilke aftaler der kræver underretning, om indsigelser blev håndteret før brug, hvordan dokumentation for internationale overførsler blev koblet på, og hvor det endelige bevismateriale opbevares.

Clarysec behandler dette som et styret kontrolmønster, ikke som en ad hoc-mailtråd. Arbejdsgangen forbinder databeskyttelsesstyring, leverandørassurance, juridisk gennemgang, IKT-forsyningskæderisiko, kundeunderretning og revisionsbevismateriale gennem Clarysec-politikker, Zenith Blueprint: En revisors 30-trins køreplan og Zenith Controls: Vejledning til kortlægning på tværs af efterlevelseskrav.

Hvorfor ændringer hos underdatabehandlere er leverandørhændelser med høj risiko

En ændring hos en underdatabehandler kan ændre en tjenestes risikoprofil fra den ene dag til den anden. Den kan ændre, hvor kunders personoplysninger hostes, hvorfra de tilgås, hvem der har privilegeret supportadgang, hvor længe logfiler opbevares, hvordan hændelser eskaleres, hvilke krypteringsansvar der gælder, og om der kræves et nyt internationalt overførselsgrundlag.

For SaaS-udbydere og udbydere af managed services indgår underdatabehandlere ofte i produktleverancekæden. De kan omfatte cloududbydere, sagsstyringsplatforme, e-mailleveringstjenester, AI-analyseværktøjer, platforme til baggrundsjobs, observability-leverandører, supportværktøjer, betalingsformidlere, udbydere af managed security services og databerigelsestjenester. Mange af disse udbydere berører kunders personoplysninger, selv når teams beskriver dem som værktøjer til “infrastruktur” eller “drift”.

Efter GDPR er dette væsentligt, fordi Article 28 kræver, at databehandlere styrer efterfølgende databehandlere under den dataansvarliges godkendelse. Hvis der anvendes generel skriftlig godkendelse, skal databehandleren underrette den dataansvarlige om påtænkte tilføjelser eller udskiftninger og give den dataansvarlige mulighed for at gøre indsigelse. Article 28(4) kræver også, at tilsvarende databeskyttelsesforpligtelser pålægges underdatabehandleren. Article 5(2) tilføjer ansvarlighedsprincippet, hvilket betyder, at organisationen skal kunne dokumentere overholdelse, ikke blot hævde den.

DORA øger betydningen for finansielle tjenester. Finansielle enheder skal styre IKT-tredjepartsrisiko som en integreret del af styring af IKT-risiko. De skal vedligeholde registre over kontraktlige ordninger, vurdere koncentrationsrisiko, forstå underleverandørkæder, definere kontraktlige sikkerhedsforanstaltninger, sikre revisions- og adgangsrettigheder, understøtte samarbejde om hændelser og planlægge exit. Selv hvis en SaaS-udbyder ikke selv er en finansiel enhed, vil dens finansielle kunder forvente bevismateriale, fordi de selv skal efterleve DORA.

NIS2 udvider perspektivet til forsyningskædesikkerhed og ledelsesansvar. Article 21 kræver passende tekniske, operationelle og organisatoriske foranstaltninger, herunder forsyningskædesikkerhed, hændelseshåndtering, forretningskontinuitet, adgangsstyring, politik for aktivstyring, sikker anskaffelse og vedligeholdelse samt vurdering af effektivitet. Article 20 placerer tilsynsansvaret hos ledelsesorganer. For cloududbydere, udbydere af managed services, udbydere af managed security services, datacentertjenesteudbydere, tillidstjenesteudbydere, onlinemarkedspladser, søgemaskiner og visse kommunikationstjenester bliver synlighed over underdatabehandlere en del af cybersikkerhedsstyringen.

ISO/IEC 27001:2022 og ISO/IEC 27701:2025 gør dette operationelt. ISO/IEC 27001:2022 kræver, at ISMS’et forstår kontekst, krav fra interessenter, risici, behandlingsplaner, operationelle kontroller og dokumenterede oplysninger. ISO/IEC 27701:2025 udvider denne ledelsessystemdisciplin til et ledelsessystem for databeskyttelse. Et databehandlerorienteret PIMS skal vise, at efterfølgende behandling af kunders personhenførbare oplysninger (PII) er forstået, kontrolleret, kontraktligt styret, overvåget og dokumenteret.

Clarysec-mønstret: registrér, vurder, underret, håndtér indsigelser, kontraktstyr, overfør, dokumentér

Den stærkeste styringsmodel for underdatabehandlere er enkel nok til, at driftsteams kan følge den, og robust nok til, at revisorer kan teste den. Clarysec bruger syv handlinger:

  1. Registrér alle nuværende og foreslåede underdatabehandlere.
  2. Vurdér databeskyttelse, sikkerhed, robusthed og afhængighedsrisiko før brug.
  3. Underret kunder i henhold til den relevante aftale.
  4. Håndtér indsigelser inden for den aftalte frist.
  5. Opdater databehandleraftaler, sikkerhedsbilag og krav om videreførelse af forpligtelser.
  6. Kobl hosting, behandlingslokation og dokumentation for internationale overførsler.
  7. Opbevar bevismateriale i databeskyttelses- og leverandørregistre.

Det første operationelle anker er Politik for håndtering af databehandlere, underdatabehandlere og tredjeparter i forhold til databeskyttelse. Den fastsætter:

[Databehandler] Leverandør-/indkøbsansvarlig SKAL vedligeholde listen over underdatabehandlere og underleverandører, der anvendes til behandling af kunders PII i REG08 før brug, og opdatere REG08 senest 10 arbejdsdage efter en godkendt ændring.

Denne klausul gør en liste over underdatabehandlere til et kontrolleret register. Den gør også tidskravet eksplicit: REG08 opdateres før brug og ajourføres derefter senest 10 arbejdsdage efter en godkendt ændring.

Samme politik gør kundeunderretning revisionsbar:

[Databehandler] Leverandør-/indkøbsansvarlig SKAL underrette kunden om påtænkte nye eller erstattende underdatabehandlere i henhold til den relevante kundeaftale før brug og registrere underretningen, indsigelsesperioden og resultatet i REG08.

Dette er den detalje, der mangler i mange programmer. Spørgsmålet er ikke kun, om en offentlig side blev opdateret. Spørgsmålet er, om de rette kunder blev underrettet på den krævede måde, før underdatabehandleren behandlede deres PII, med indsigelsesperioden og resultatet bevaret som bevismateriale.

Politikken forbinder også ændringsstyring med due diligence:

[Alle] Leverandør-/indkøbsansvarlig SKAL færdiggøre bevismateriale for due diligence vedrørende databeskyttelse i REG08, før der vælges, fornyes eller foretages en væsentlig ændring i et databehandler-, underdatabehandler- eller tredjepartsforhold, der behandler eller tilgår PII.

En væsentlig ændring kan omfatte udskiftning af infrastruktur, tilføjelse af en efterfølgende analyseudbyder, flytning af hostingregioner, aktivering af supportadgang fra et nyt land, udvidelse af datakategorier eller ændring af en tjenestes opbevaringsadfærd.

Endelig lukker politikken hullet vedrørende kontraktlige krav om videreførelse af forpligtelser:

[Databehandler] Leverandør-/indkøbsansvarlig SKAL sikre, at hver kontrakt med en underdatabehandler indeholder krav om videreførelse af forpligtelser vedrørende databeskyttelse, sikkerhed, assistance, tilbagelevering, sletning, hændelsesgrænseflade og kobling til overførselsgrundlag, før underdatabehandleren behandler PII.

Dette er vigtigt, fordi et generisk sikkerhedstillæg ikke altid er tilstrækkeligt. Databehandlerspecifikke forpligtelser skal videreføres nedstrøms, før behandlingen påbegyndes.

Hvor Clarysec-politikker forbinder databeskyttelse, leverandører og overførsler

Styring af underdatabehandlere fungerer kun, når databeskyttelse, juridisk funktion, leverandørsikkerhed og operationel ændringsstyring bruger samme beviskæde.

Politik for juridisk og regulatorisk efterlevelse - SMV fastlægger reglen før deling:

Databehandleraftaleklausuler (DPA) eller tilsvarende kontraktlige vilkår skal være aftalt, før personoplysninger eller følsomme data deles.

For enterprise-miljøer gør Politik for juridisk og regulatorisk efterlevelse forventningen til bevismateriale mere detaljeret ved at kræve:

Oplysninger om underdatabehandlere og erklæringer om geografiske dataoverførsler

Den identificerer også styringsudløsere, der omfatter:

Ændringer i dataoverførselsgrundlag, underdatabehandlere eller grænseoverskridende dataflows

Politik for tredjeparts- og leverandørsikkerhed fastsætter:

Brug af underleverandører underlagt forudgående skriftligt samtykke

For mindre organisationer giver Politik for tredjeparts- og leverandørsikkerhed - SMV en skalerbar version:

Begrænsninger for yderligere underleverandører uden godkendelse

Den gør også revurdering af leverandørændringer eksplicit:

Alle leverandørændringer — herunder ejerskab, tjenestetype, hostinglokation eller underleverandørforhold — skal revurderes med henblik på risikopåvirkning og kontraktlig relevans.

Databeskyttelses- og privatlivspolitik omfatter:

Krav til godkendelse af underdatabehandlere

Politik for risikostyring af leverandørafhængigheder tilføjer robusthedsperspektivet:

Oplysning om underleverandører: leverandøren skal informere os om centrale underleverandører og eventuelle ændringer hertil, især hvor disse skaber yderligere afhængighedslag.

Tilsammen skaber disse politikker en fuldstændig driftsregel: ingen deling af personoplysninger uden kontraktlige vilkår, ingen skjulte underdatabehandlere, ingen ustyrede underleverandørforhold, ingen uvurderede ændringer af hosting eller lokation og ingen godkendelse uden overførselsdokumentation, hvor det er relevant.

Hvordan Zenith Controls afgrænser leverandørkontrollerne

I Zenith Controls kortlægger Clarysec primært ændringsstyring for underdatabehandlere til ISO/IEC 27002:2022-kontroller for leverandører og juridiske krav. Det er vigtigt, fordi det viser, at styring af underdatabehandlere ikke kun er en databeskyttelsesproces. Det er også en kontrol for informationssikkerhed, leverandørstyring, juridisk efterlevelse og robusthed.

ISO/IEC 27002:2022-kontrolKontrolnavnRolle i styring af underdatabehandlere
5.19Informationssikkerhed i leverandørrelationerFastlægger grundlaget for leverandørrisikostyring ved identifikation og styring af udbydere, der tilgår oplysninger eller systemer
5.20Håndtering af informationssikkerhed i leverandøraftalerSikrer, at aftaler omfatter forpligtelser vedrørende sikkerhed, databeskyttelse, underleverandører, hændelser, revision, sletning og overførsel
5.21Styring af informationssikkerhed i IKT-forsyningskædenUnderstøtter synlighed over efterfølgende IKT-afhængigheder og forsyningskæderisici
5.22Overvågning, gennemgang og ændringsstyring af leverandørtjenesterTilvejebringer den operationelle kontrol til revurdering af leverandørændringer, herunder nye underdatabehandlere og hostingændringer
5.23Informationssikkerhed ved brug af cloudtjenesterAnvendes, når underdatabehandlere leverer cloudhosting, cloudplatforme, SaaS eller cloudbaseret behandling
5.31Retlige, lovgivningsmæssige, regulatoriske og kontraktlige kravForbinder arbejdsgangen med GDPR, DORA, NIS2, kunders databehandleraftaler, overførselsforpligtelser og kontraktlige underretningspligter

Zenith Controls beskriver kontrol 5.22, “Overvågning, gennemgang og ændringsstyring af leverandørtjenester”, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset cybersikkerhedskonceptet Identify og operationelle kapaciteter for sikkerhed i leverandørrelationer og informationssikkerhedsassurance. Det er præcis, hvad en ændring hos en underdatabehandler kræver: identificér ændringen, revurdér risikoen, bekræft kontraktlig dækning og opbevar assurance-dokumentation.

For kontrol 5.20 beskriver Zenith Controls leverandøraftaler som forebyggende kontroller, der dækker fortrolighed, integritet og tilgængelighed. Det er her, vilkår i databehandleraftaler, sikkerhedsbilag, underleverandørklausuler, revisionsrettigheder, hændelsesassistance, tilbagelevering og sletning samt forpligtelser om kobling til overførselsgrundlag hører hjemme.

For kontrol 5.21 er forsyningskædeperspektivet væsentligt, fordi en underdatabehandler kan skabe en fjerdepartsafhængighed. En SaaS-leverandør kan være afhængig af en infrastrukturudbyder, som er afhængig af en dataanalyseudbyder, som igen er afhængig af en anden cloudregion eller supportpartner. Organisationen skal forstå kæden tilstrækkeligt til at kunne styre risiko, kundeforpligtelser og exitmuligheder.

30-trins køreplanen: fra politik til operationel procedure

Zenith Blueprint placerer leverandørrisiko og nedstrøms risiko i trin 23, organisatoriske kontroller. Den forklarer, at leverandøraftaler typisk omhandler fortrolighed, adgangsstyring, tekniske og organisatoriske foranstaltninger, frister for hændelsesrapportering, revisionsret, kontroller for underleverandører og bestemmelser ved kontraktophør. Blueprint fremhæver et centralt punkt:

Aftalens struktur er vigtig. Disse klausuler kan stå i en Master Services Agreement, en særskilt Databehandleraftale (DPA) eller et selvstændigt sikkerhedsbilag. Det afgørende er, at de findes, og at de er forstået og accepteret af begge parter.

Blueprint angiver også, hvad teams skal gøre med underleverandører:

For hver kritisk leverandør skal det identificeres, om leverandøren anvender underleverandører (underdatabehandlere), som kan tilgå jeres data eller systemer. Dokumentér, hvordan jeres informationssikkerhedskrav videreføres til disse parter, enten gennem jeres leverandørs kontraktvilkår eller gennem jeres egne direkte klausuler.

For styring af leverandørændringer er den korrekte operationelle tilpasning ISO/IEC 27002:2022-kontrol 5.22:

Etablér en enkel, skalerbar procedure for vurdering af ændringer i leverandørtjenester (5.22), såsom migrering til cloud, nye underdatabehandlere eller redesign af infrastruktur. Definér udløsere, der kræver fornyet sikkerhedsvurdering.

Det giver CISO’er og DPO’er en praktisk vej. Trin 23 definerer kontrolformålet. REG08 registrerer bevismateriale vedrørende databehandlere, underdatabehandlere og tredjeparters databeskyttelse. REG09 registrerer overførselsdokumentation. Leverandørkontrakter, databehandleraftaler og ændringssager forbinder arbejdsgangen med den operationelle virkelighed.

En praktisk arbejdsgang for ændringsunderretning om underdatabehandlere

En arbejdsgang for ændringer hos underdatabehandlere bør være forudsigelig på den rigtige måde. Hvert trin bør have en ejer, bevismateriale og et kontrolpunkt, der forhindrer for tidlig brug i produktionsmiljøet.

Trin i arbejdsgangenEjerBevismaterialeGodkendelseskontrolpunkt
Modtagelse af foreslået underdatabehandlerLeverandør- eller indkøbsansvarligÆndringsanmodning, tjenestebeskrivelse, datakategorier, behandlingsformålTriage vedrørende databeskyttelse og sikkerhed
Due diligence vedrørende databeskyttelse og sikkerhedDPO, sikkerhed, indkøbREG08-due diligence, certificeringer, spørgeskema, hændelseshistorik, TOMsGodkendelse fra risikoejer
Gennemgang af kontrakt og databehandleraftaleJuridisk, indkøbKortlægning af DPA-klausuler, underleverandørvilkår, revisionsrettigheder, hændelsesassistance, slettevilkårJuridisk godkendelse
Gennemgang af lokation og overførselDatabeskyttelse, juridisk, sikkerhedBehandlingslokationer, hostinglokationer, overførselsgrundlag, REG09-koblingGodkendelse af overførsel
KundeunderretningCustomer Success, juridisk, databeskyttelseKopi af underretning, berørte kunder, aftalegrundlag, underretningsdato, indsigelsesfristUnderretning sendt før brug
Håndtering af indsigelserJuridisk, kundeansvarlig, risikoejerIndsigelseslog, risikorespons, kundebeslutning, teknisk blokering om nødvendigtIndsigelse løst eller undtagelse godkendt
Aktivering i produktionsmiljøetEngineering, ændringsstyringsansvarligÆndringssag, godkendelsesreferencer, idriftsættelsesdatoIngen behandling før godkendelse
Opdatering efter ændringLeverandøransvarligOpdateret REG08, offentlig liste hvis anvendt, kontraktrepository, overvågningskadenceGennemgang af bevismateriale inden for defineret SLA

Hovedprincippet er enkelt: Kundeunderretning skal ske før brug, hvor aftalen kræver det. Opdatering af en offentlig webside efter implementering kan understøtte gennemsigtighed, men den dokumenterer ikke kundespecifik underretning, kontraktlig godkendelse eller håndtering af indsigelser.

Anvendelse af arbejdsgangen på Sarahs krise

Sarahs leverandørmeddelelse om DataCrunch Analytics udløser den fulde proces.

Først opretter leverandøransvarlig en REG08-ændringsregistrering. Registreringen identificerer CoreStack, DataCrunch Analytics, tjenestens formål, påvirkning af kundetenant, behandlingsrolle, datakategorier, behandlingslokationer, supportadgangsmodel, opbevaringsperiode, og om der kan være særlige kategorier af personoplysninger eller regulerede finansielle kundedata til stede.

Derefter gennemfører databeskyttelses- og sikkerhedsfunktionen due diligence. De gennemgår DataCrunch Analytics’ tekniske og organisatoriske foranstaltninger, kryptering, adgangsstyring, logning, hændelsesunderretning, slettekapaciteter, revisionsassurance, liste over underdatabehandlere og sikkerhedscertificeringer. Fordi udbyderen er uden for EU, er gennemgang af lokation og overførsel obligatorisk.

For det tredje kontrollerer juridisk afdeling, om kundernes databehandleraftaler anvender specifik godkendelse eller generel godkendelse med underretning. Kunder segmenteres i underretningsgrupper: kunder med standardvarsel på 30 dage, enterprise-kunder med indsigelsesfrister på 45 dage, kunder der kræver specifik godkendelse, begrænsede kunder med lokationsbegrænsninger og uberørte kunder, hvis data ikke berører analyseworkloaden.

For det fjerde kobles overførselsdokumentation. Politik for håndtering af databehandlere, underdatabehandlere og tredjeparter i forhold til databeskyttelse kræver:

[Begge] Leverandør-/indkøbsansvarlig SKAL registrere behandlingslokationer, hostinglokationer og indikatorer for internationale overførsler i REG08 og koble relevant overførselsdokumentation til REG09, før en databehandler, underdatabehandler, lokationsændring eller overførselsrelevant tjenesteændring godkendes.

For det femte sender Customer Success formelle underretninger via godkendte kanaler. Hver underretning angiver den påtænkte underdatabehandler, formål, datakategorier, lokationsresumé, ikrafttrædelsesdato, indsigelsesfrist og kontaktvej.

For det sjette håndteres indsigelser. Hvis en finansiel institution gør indsigelse, fordi ændringen påvirker en kritisk funktion eller en overførsel til et tredjeland, vurderer Sarahs team alternativer: udelukke tenanten, bevare den gamle behandlingsvej, kræve EU-only support, ændre kontraktlige sikkerhedsforanstaltninger eller udskyde ændringen, indtil indsigelsen er løst.

For det syvende får Engineering kun godkendelse for tenants og workloads, der har passeret kontrolpunktet. Ændringssagen for produktionsmiljøet linker til REG08, REG09, juridisk godkendelse, underretningsdokumentation og eventuelle kundespecifikke undtagelser. Efter idriftsættelse opdateres det interne register, den offentlige side med underdatabehandlere og kontraktrepositoryet.

Det er forskellen mellem reaktiv brandslukning og forsvarlig styring.

Kortlægning på tværs af efterlevelseskrav for én beviskæde

Clarysec-fordelen er, at én arbejdsgang kan opfylde flere frameworks, når bevismateriale designes korrekt fra starten.

KravområdeHvordan arbejdsgangen adresserer det
GDPR Article 28 og ansvarlighedVedligeholder dokumentation for godkendelse af underdatabehandlere, kundeunderretninger, resultater af indsigelser, videreførelse af DPA-forpligtelser og kobling til overførselsgrundlag
ISO/IEC 27701:2025 PIMSDokumenterer rollebevidst styring af databeskyttelse for databehandlere, kontrol med efterfølgende behandling, opbevaring af bevismateriale og overvågning
ISO/IEC 27001:2022 ISMSUnderstøtter krav fra interessenter, risikovurdering, operationel kontrol, leverandørkontroller, retlige krav og dokumenterede oplysninger
ISO/IEC 27002:2022-kontrollerImplementerer kontroller for leverandørrelationer, leverandøraftaler, IKT-forsyningskæde, leverandørændringer, cloudtjenester og retlige krav
DORA IKT-tredjepartsrisikoUnderstøtter registre, due diligence, synlighed over underleverandørkæder, lokationsbevidsthed, koncentrationsrisiko, revisionsrettigheder, hændelsesassistance og exitplanlægning
NIS2-forsyningskædesikkerhedUnderstøtter Article 21-forsyningskædesikkerhed, leverandørrisikoanalyse, hændelseshåndtering, forretningskontinuitet og ledelsestilsyn
NIST CSF 2.0 GOVERN og GV.SCEr tilpasset leverandørrisikostrategi, leverandørkritikalitet, kontraktlige cybersikkerhedskrav, due diligence, livscyklusovervågning, involvering ved hændelser og planlægning af ophør
COBIT 2019-styringsperspektivUnderstøtter interessentbehov, risikooptimering, leverandøransvarlighed, ledelsesrapportering og assurance-dokumentation

NIST CSF 2.0 er nyttig som et neutralt struktureringslag. Funktionen GOVERN omfatter forståelse af juridiske, regulatoriske, kontraktlige, databeskyttelses- og borgerrettighedsforpligtelser, tildeling af roller, etablering af politikker, gennemgang af performance og styring af cybersikkerhedsrisiko i forsyningskæden. Kategorien GV.SC forventer processer for leverandørrisiko, leverandørkritikalitet, kontraktlige cybersikkerhedskrav, due diligence, livscyklusovervågning, hændelsesplanlægning og aktiviteter efter leverandørforholdets ophør.

DORA er mere præskriptiv for finansielle enheder. Articles 28 til 30 kræver styring af IKT-tredjepartsrisiko, kontraktregistre, klassificering af kritiske eller vigtige funktioner, synlighed over underleverandørkæder, lokationsbevidsthed, kontraktlige sikkerhedsforanstaltninger, revisionsrettigheder, hændelsessamarbejde og exitplanlægning. Hvis din SaaS-platform understøtter finansielle kunder, bliver dit bevismateriale for underdatabehandlere en del af deres DORA-bevispakke.

NIS2 tilføjer ledelsesansvar. Article 20 kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici og fører tilsyn med implementeringen. Article 21 kræver forsyningskædesikkerhed og vurdering af leverandørers cybersikkerhedspraksis. En væsentlig ændring hos en underdatabehandler bør derfor være synlig i risikorapporteringen, ikke gemt i en indkøbsmappe.

Hvad revisorer vil teste

En moden proces for underdatabehandlere skaber en lige linje fra politik til bevismateriale.

En ISO/IEC 27001:2022-revisor vil begynde med ISMS-omfang, krav fra interessenter, risici, anvendelighedserklæring (SoA) og operationelle kontroller. Revisoren vil sandsynligvis teste leverandørrelationer, leverandøraftaler, IKT-forsyningskæde, leverandørovervågning og ændringsstyring, retlige krav, cloudtjenester, privatlivsbeskyttelse, logning og operationel ændringsstyring.

En ISO/IEC 27701:2025 PIMS-revisor vil fokusere på rolleklarhed. Er I databehandler, dataansvarlig, fælles dataansvarlig eller begge dele i forskellige tjenester? For databehandleraktiviteter vil revisoren anmode om listen over underdatabehandlere, godkendelsesgrundlag, underretningsdokumentation, håndtering af indsigelser, downstream-kontrakter, overførselsdokumentation, sletningssupport, hændelsesgrænseflade og overvågningsregistreringer.

En GDPR-gennemgang af databeskyttelse vil teste ansvarlighed. Den vil spørge, hvem der behandler personoplysninger, til hvilket formål, efter hvilken aftale, på hvilken lokation, med hvilke sikkerhedsforanstaltninger og med hvilken gennemsigtighed over for kunden. Hvis en kunde har gjort indsigelse, vil den spørge, hvad der skete, før behandlingen begyndte.

En DORA-kunderevisor vil spørge, om underdatabehandleren understøtter en kritisk eller vigtig funktion, om underleverandørkæder er synlige, om datalokationer er dokumenteret, om hændelsesassistance er kontraktligt garanteret, om revisionsrettigheder videreføres, om koncentrationsrisiko er vurderet, og om exit er mulig.

En NIS2-vurderingspart vil fokusere på forsyningskædesikkerhed, ledelsestilsyn, hændelsesberedskab og proportionale kontroller. De kan spørge, hvordan leverandørændringer opdages, hvordan direkte leverandører vurderes, hvordan leverandørsårbarheder indgår, og hvordan hændelser, der involverer tjenestemodtagere, eskaleres.

Bevismaterialet bør være let at rekonstruere:

  • Godkendt ændringsanmodning for underdatabehandler.
  • REG08-registrering af due diligence.
  • Vurdering af datakategori og behandlingsformål.
  • Dokumentation for behandlings- og hostinglokation.
  • REG09-overførselsdokumentation, hvor relevant.
  • Gennemgang af videreførelse af DPA- og kontraktforpligtelser.
  • Liste over kundeunderretninger, datoer, ordlyd og leveringsdokumentation.
  • Indsigelseslog og dokumentation for løsning.
  • Ændringssag for produktionsmiljøet koblet til godkendelse.
  • Opdateret liste over underdatabehandlere og overvågningsplan.
  • Risikoaccept eller godkendelse af undtagelse, hvor nødvendigt.

Almindelige fejlmønstre

Det første fejlmønster er at behandle en side med underdatabehandlere som hele processen. En offentlig side understøtter gennemsigtighed, men den dokumenterer ikke kundespecifik underretning, håndtering af indsigelser eller godkendelse.

Det andet fejlmønster er at adskille bevismateriale for databeskyttelse, sikkerhed og indkøb. Databeskyttelsesfunktionen kan godkende databehandleraftalen, sikkerhed kan gennemgå en SOC 2-rapport, og indkøb kan arkivere kontrakten, men ingen samlet registrering forbinder beslutningen.

Det tredje fejlmønster er manglende kobling til overførsel. Teams registrerer leverandørnavnet, men ikke behandlingslokationer, hostinglokationer, supportlokationer, indikatorer for internationale overførsler eller REG09-bevismateriale.

Det fjerde fejlmønster er at aktivere produktionsmiljøet, før indsigelsesfrister er udløbet. Når kunders PII først behandles af den nye underdatabehandler, kan organisationen allerede have brudt aftalen.

Det femte fejlmønster er svag videreførelse af forpligtelser. Den direkte leverandør accepterer stærke vilkår, men dens efterfølgende udbydere er ikke bundet af tilsvarende forpligtelser vedrørende databeskyttelse, sikkerhed, assistance, tilbagelevering, sletning, hændelser, revision og overførsel.

Det sjette fejlmønster er svag detektion af ændringer. En leverandør ændrer ejerskab, hostinglokation, tjenestetype, supportmodel eller underleverandørkæde, og ingen revurderer risikoen.

Det syvende fejlmønster er manglende revisionsspor. Teams husker beslutningen, men kan ikke dokumentere, hvornår den blev truffet, hvem der godkendte den, hvilke kunder der blev underrettet, og hvordan indsigelser blev løst.

Ledelsesrapportering for CISO’er og DPO’er

Styring af underdatabehandlere bør producere ledelsesinformation, ikke kun compliance-artefakter.

MetrikHvorfor den er vigtig
Aktive underdatabehandlere efter tjeneste og datakategoriViser behandlingsaftryk og databeskyttelseseksponering
Underdatabehandlere, der understøtter kritiske tjenesterUnderstøtter robusthedsplanlægning, DORA-assurance og leverandørprioritering
Underdatabehandlere med adgang eller hosting i tredjelandeUnderstøtter overførselsgennemgange og kundeerklæringer
Kommende indsigelsesfristerForhindrer for tidlig aktivering i produktionsmiljøet
Underdatabehandlere uden aktuel due diligenceIdentificerer assurance-mangler
Kontrakter uden klausuler om videreførelse af forpligtelserFremhæver juridisk og operationel risiko
Leverandørændringer, der afventer revurderingViser styringsarbejdets omfang og backlog
Kundeindsigelser åbne ud over SLAIndikerer uløste kommercielle, juridiske eller tekniske blokeringer

Denne rapportering passer til ledelsessystemmodellen. ISO/IEC 27001:2022 forventer lederskab, operationel kontrol, evaluering af performance og løbende forbedring. DORA og NIS2 løfter ledelsesansvar. Styring af underdatabehandlere bør indgå i styremøder om databeskyttelse, leverandørrisikogennemgange, ISMS-ledelsens gennemgang og IKT-risikorapportering, hvor det er relevant.

Opbyg din bevispakke for ændringer hos underdatabehandlere

Start med én nylig leverandørændring, og test, om din organisation kan besvare disse spørgsmål:

  • Blev udbyderen identificeret som databehandler, underdatabehandler, leverandør, IKT-udbyder eller alle disse?
  • Blev REG08 eller et tilsvarende register opdateret før brug?
  • Blev behandlingslokationer og hostinglokationer registreret?
  • Blev indikatorer for internationale overførsler vurderet?
  • Blev overførselsdokumentation koblet til REG09 eller en tilsvarende fil?
  • Omfattede kontrakten krav om videreførelse af forpligtelser vedrørende databeskyttelse, sikkerhed, assistance, tilbagelevering, sletning, hændelser, revision og overførsel?
  • Blev kunder underrettet i henhold til deres aftaler, før behandlingen begyndte?
  • Blev indsigelsesfrister sporet og afsluttet?
  • Blev aktivering i produktionsmiljøet blokeret indtil godkendelse?
  • Kan en revisor rekonstruere beslutningssporet på under 30 minutter?

Hvis svaret er nej, er hullet ikke kun juridisk. Det vedrører drift, kontrakter, leverandørrisiko, databeskyttelse og revisionsberedskab.

Clarysec hjælper teams med hurtigt at lukke det hul. Brug Zenith Blueprint til at placere styring af underdatabehandlere i jeres ISMS- og PIMS-implementeringskøreplan. Brug Zenith Controls til at kortlægge kontroller for leverandørrelationer, leverandøraftaler, IKT-forsyningskæde, leverandørændringer, cloudtjenester og retlige krav på tværs af ISO/IEC 27001:2022, ISO/IEC 27701:2025, GDPR, DORA, NIS2, NIST CSF 2.0 og COBIT 2019. Brug Politik for håndtering af databehandlere, underdatabehandlere og tredjeparter i forhold til databeskyttelse, Politik for tredjeparts- og leverandørsikkerhed, Politik for juridisk og regulatorisk efterlevelse, Databeskyttelses- og privatlivspolitik og Politik for risikostyring af leverandørafhængigheder til at omsætte kortlægningen til daglig udførelse.

Vent ikke på den overraskende fodnote i en leverandørmail. Opbyg arbejdsgangen, bevispakken og kontrolkortlægningen nu, så hver ændring hos en underdatabehandler bliver dokumentation for moden styring i stedet for en compliance-krise.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

API-sikkerhedsstyring: ISO 27001-revisionsbeviser for 2026

API-sikkerhedsstyring: ISO 27001-revisionsbeviser for 2026

Shadow APIs, svage tokens, manglende hastighedsbegrænsning og inkonsistente logfiler er nu styringssvigt. Denne hovedguide viser CISO’er, hvordan de opbygger API-sikkerhedsbeviser til revisioner baseret på ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT.