Transfer Impact Assessments for cloudmiljøer i 2026

Maria, CISO hos InnovatePay, stirrede på side 12 i due diligence-spørgeskemaet.

Hendes virksomhed, en hurtigt voksende europæisk fintech-SaaS-udbyder, var tæt på at indgå aftale med sin hidtil største kunde: en stor bank med strenge forventninger til operationel robusthed. Spørgeskemaet efterspurgte ikke kun et ISO 27001-certifikat, et resumé af penetrationstest eller en pakke med sikkerhedspolitikker. Det efterspurgte en fuldstændig Transfer Impact Assessment for InnovatePays primære USA-baserede cloududbyder, en fortegnelse over underdatabehandlere, de relevante Standard Contractual Clauses, en erklæring om geografiske dataoverførsler og dokumentation for, at supplerende foranstaltninger var kortlagt til ISO/IEC 27001:2022, NIS2 og DORA.

Jura havde databehandleraftalen. Indkøb havde leverandørportalen. Udviklingsafdelingen havde indstillingerne for cloudregioner. Sikkerhed havde krypteringsdiagrammer. Kundesucces havde lovet “EU-hosting” på et salgsmøde. Ingen kunne umiddelbart dokumentere, om supportadgang fra Indien var omfattet, om analysetilføjelsen brugte en amerikansk underdatabehandler, eller om fejllogfiler blev replikeret via en global overvågningsudbyder.

Det er virkeligheden i 2026 for SaaS-virksomheder, cloududbydere, fintech-leverandører og udbydere af administrerede IKT-tjenester. En Transfer Impact Assessment, eller TIA, er ikke længere et privatlivsnotat, der udarbejdes ved afslutningen af indkøbsprocessen. Den er en tværgående pakke med efterlevelsesbevismateriale, der skal forklare, hvor personoplysninger går hen, hvem der kan få adgang til dem, hvilken retlig overførselsmekanisme der gælder, hvilke supplerende foranstaltninger der reducerer risikoen, og hvordan organisationen overvåger overførslen over tid.

For mange teams er problemet ikke manglende indsats. Det er fragmentering. SCC’er ligger i et kontraktarkiv. Lister over underdatabehandlere ligger i leverandørportaler. Indstillinger for dataresidens ligger i cloudkonsollen. Risikobeslutninger er begravet i e-mails. Bevismateriale om kryptering ligger i Confluence. En stærk Transfer Impact Assessment for cloudtjenester forbinder disse fragmenter til én dokumenterbar beviskæde.

Hvorfor TIA’er for cloudtjenester er blevet et risikospørgsmål på bestyrelsesniveau

En Transfer Impact Assessment vurderer, om personoplysninger, der overføres uden for Det Europæiske Økonomiske Samarbejdsområde, fortsat er beskyttet i praksis. Vurderingen skal identificere data, parter, behandlingsformål, opbevaringslokationer, adgangslokationer, videreoverførsler, retlig overførselsmekanisme, risici i modtagerlandet og supplerende foranstaltninger.

Efter GDPR er udgangspunktet bredt. Personoplysninger, behandling, dataansvarlig, databehandler, pseudonymisering og brud på persondatasikkerheden er defineret bredt. Cloud-telemetri, supportsager, autentifikationslogfiler, faktureringsdata, brugeridentifikatorer, IP-adresser og produktanalyse kan alle være omfattet. GDPR’s ansvarlighed efter Article 5 kræver, at organisationer kan dokumentere overholdelse, mens databehandlerforpligtelser efter Article 28 og reglerne om internationale overførsler i Chapter V afhænger af præcis viden om, hvilke data der flyttes, hvor de flyttes hen, og hvem der kan tilgå dem.

Schrems II-dommen gjorde den praktiske byrde tydeligere. Det er ikke i sig selv nok at underskrive SCC’er. Organisationer skal vurdere, om lovgivning og praksis i modtagerlandet kan underminere de beskyttelsesforanstaltninger, der er aftalt kontraktligt, og derefter anvende supplerende foranstaltninger, hvor det er nødvendigt.

For cloudvirksomheder bliver dette hurtigt komplekst. Et SaaS-produkt kan bruge én infrastrukturudbyder, en særskilt supportplatform, en e-mailtjeneste, et værktøj til fejlovervågning, et CDN, et datawarehouse og en AI-analysefunktion. Hver udbyder kan have underdatabehandlere. Hver underdatabehandler kan indføre en opbevaringslokation, adgangslokation, driftsmæssig supportvej eller videreoverførsel.

Derfor er ISO/IEC 27001:2022, NIS2, DORA og NIST CSF 2.0 blevet en del af TIA-drøftelsen:

• GDPR spørger, om der findes en lovlig overførselsmekanisme, passende databehandlervilkår, styring af underdatabehandlere og effektive supplerende foranstaltninger.
• ISO/IEC 27001:2022 spørger, om overførselsrisikoen er identificeret, behandlet, kontrolleret, overvåget og medtaget i Statement of Applicability.
• NIS2 spørger, om væsentlige og vigtige enheder styrer cybersikkerhedsrisici hos leverandører og tjenesteudbydere med ledelsestilsyn.
• DORA kræver, at finansielle enheder kan dokumentere styring af IKT-tredjepartsrisici, kontraktklausuler, synlighed over underleverandører, lokationsgennemsigtighed, koncentrationsrisiko og exit-beredskab.
• NIST CSF 2.0 hjælper med at omsætte disse krav til resultater inden for styring, leverandørrisiko, beskyttelse, respons og genopretning.

Den praktiske konklusion er enkel: En TIA skal ligge inde i ISMS’et, ikke uden for det.

Brug ISMS’et som centrum for efterlevelse

Forsøg på at styre TIA’er, GDPR, DORA og NIS2 i separate regneark skaber dobbeltarbejde og revisionshuller. Den mere skalerbare tilgang er at bruge ISO/IEC 27001:2022 som det ledelsessystem, der forbinder forpligtelser, risici, kontroller og bevismateriale.

ISO/IEC 27001:2022 kræver, at organisationer forstår deres kontekst, krav fra interessenter, grænseflader og afhængigheder til andre organisationer. Standarden kræver også en gentagelig risikovurdering af informationssikkerhed, en risikobehandlingsproces, Statement of Applicability og bevismateriale for, at valgte kontroller fungerer efter hensigten.

Denne struktur passer perfekt til en TIA. Risikoen “EU-personoplysninger kan tilgås fra et tredjeland via en cloududbyder eller underdatabehandler uden effektive sikkerhedsforanstaltninger” hører hjemme i risikoregisteret. Behandlingen hører hjemme i risikobehandlingsplanen. De valgte kontroller hører hjemme i SoA’en. De understøttende artefakter hører hjemme i et indeks over bevismateriale.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap beskriver denne sammenhæng i risikostyringsfasen, trin 13:

SoA’en er reelt et brodokument: Den forbinder din risikovurdering/-behandling med de faktiske kontroller, du har. Ved at udfylde den dobbelttjekker du også, om du har overset kontroller.

Denne sætning er central for TIA-beredskab. TIA’en er ikke kontrollen. Den er vurderingen, der forklarer, hvorfor kontroller er nødvendige, og hvordan de reducerer den resterende overførselsrisiko. SoA’en er broen, der forbinder risikoen med cloudstyring, leverandørkontrakter, kryptografi, adgangsstyring, overvågning, hændelseshåndtering, kontinuitet og juridisk efterlevelse.

Start med overførselskortet, ikke SCC’en

Mange organisationer begynder en TIA med at spørge, om kontrakten indeholder SCC’er. Det er nødvendigt, men det er ikke det første spørgsmål. SCC’er giver kun mening, hvis organisationen ved, hvilke overførsler de dækker.

En praktisk TIA for cloudtjenester starter med fem spørgsmål.

Clarysecs SME Politik for brug af cloudtjenester for SMV’er gør dette operationelt ved at kræve et register:

Et Cloud Service Register skal vedligeholdes af IT-leverandøren eller GM. Det skal registrere:

Fra afsnittet “Styringskrav”, politikklausul 5.3.

Samme klausulfamilie omfatter et lokationskrav, som er afgørende for TIA’er:

Det land eller den region, hvor data opbevares

Fra afsnittet “Styringskrav”, politikklausul 5.3.4.

For større miljøer forbinder Clarysecs Politik for brug af cloudtjenester eksplicit cloudstyring med overførselsmekanismer:

Gennemgå standardkontraktbestemmelser (SCC’er) og overførselsmekanismer efter GDPR, hvor det er relevant.

Fra afsnittet “Roller og ansvar”, politikklausul 4.5.2.

Samme politik tilføjer det tværregulatoriske krav:

Grænseoverskridende dataoverførsler skal overholde GDPR Chapter V og, hvor det er relevant, DORA Article 28.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.6.3.

Det ændrer TIA-samtalen. Spørgsmålet er ikke “har vi SCC’er?” Spørgsmålet er “hvilken cloudtjeneste, hvilke personoplysninger, hvilket land, hvilken adgangsvej, hvilken underdatabehandler, hvilken overførselsmekanisme, hvilke supplerende foranstaltninger og hvilken restrisiko?”

Kortlæg TIA’er for cloudtjenester til ISO/IEC 27001:2022-bevismateriale

ISO/IEC 27001:2022 giver strukturen til at dokumentere, at en TIA er en del af et fungerende kontrolmiljø. De mest relevante områder for bevismateriale er leverandørstyring, cloudstyring, retlige forpligtelser, databeskyttelse, kryptografi, adgangsstyring, overvågning, hændelseshåndtering og kontinuitet.

Clarysecs Zenith Controls: The Cross-Compliance Guide er særligt nyttig her. I Zenith Controls behandles ISO/IEC 27002:2022-kontrol 5.23, Informationssikkerhed ved brug af cloudtjenester, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed på tværs af styrings-, økosystem- og beskyttelsesdomæner. Den knytter cloudbrug til leverandørrelationer, endpointsikkerhed, netværkssikkerhed, informationsoverførsel, datamaskering, forebyggelse af datalækage, aktivfortegnelse og sikker udviklingslivscyklus.

Denne kortlægning er vigtig, fordi en TIA sjældent løses af én juridisk klausul. Den omfatter ofte cloudadministratoradgang, API’er, der flytter data mellem regioner, supportkonsoller, logfiler, storage buckets, overvågningsplatforme og backuplokationer.

Zenith Controls kortlægger også 5.23 til relaterede standarder, herunder ISO/IEC 27017 for delt ansvar i cloud og revisionsspor, ISO/IEC 27018 for beskyttelse af personhenførbare oplysninger (PII) i public cloud, ISO/IEC 27701 for krav til databeskyttelsesudvidelse, ISO/IEC 27036-4 for overvågning af cloudtjenester og ISO/IEC 27005 for cloudrisikovurdering.

For leverandørkontrakter dækker Zenith Controls ISO/IEC 27002:2022-kontrol 5.20, Håndtering af informationssikkerhed i leverandøraftaler. Denne kontrol omsætter overførselskrav til bindende forpligtelser. Databehandlervilkår efter GDPR Article 28, kontroller for underdatabehandlere, NIS2-forventninger til forsyningskæden og DORA Article 30-kontraktbestemmelser bliver alle til kontraktligt bevismateriale.

For løbende tilsyn er ISO/IEC 27002:2022-kontrol 5.22, Overvågning, gennemgang og ændringsstyring af leverandørtjenester, nøglen. En TIA, der er gennemført under onboarding, kan blive forældet, når en udbyder tilføjer en underdatabehandler, ændrer supportlokationer, ændrer logningsarkitektur eller lancerer en ny funktion.

Ret op på det svage punkt: underdatabehandlere

Den mest almindelige TIA-fejl er ikke manglende SCC’er. Det er forældet viden om underdatabehandlere.

Cloududbydere og SaaS-platforme ændrer ofte serviceregioner, supportmodeller, telemetripipelines, CDN’er og underleverandører. Hvis en TIA afhænger af en liste over underdatabehandlere, der blev hentet én gang under indkøb, bliver den hurtigt upålidelig.

Clarysecs Politik for tredjeparts- og leverandørsikkerhed håndterer dette gennem et kontraktkrav:

Brug af underleverandører er underlagt forudgående skriftligt samtykke

Fra afsnittet “Styringskrav”, politikklausul 5.3.5.

Clarysecs Politik for juridisk og regulatorisk efterlevelse identificerer det juridiske bevismateriale, der skal vedligeholdes:

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

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.1.2.

Kravet er kort, men det er ofte forskellen mellem en troværdig TIA og en ufuldstændig TIA. Hvis en organisation ikke kan fremlægge oplysninger om underdatabehandlere og erklæringer om geografiske overførsler, kan den ikke pålideligt forklare videreoverførsler.

Zenith Blueprint, fasen Controls in Action, trin 23, tilføjer den operationelle forventning:

For hver kritisk leverandør skal det identificeres, om leverandøren bruger underleverandører (underdatabehandlere), som kan få adgang til jeres data eller systemer. Dokumentér, hvordan jeres krav til informationssikkerhed videreføres til disse parter, enten gennem leverandørens kontraktvilkår eller jeres egne direkte klausuler.

I praksis betyder det, at højrisikoleverandører skal have en årlig gennemgang af underdatabehandlere, en proces for ændringsmeddelelser, en dokumenteret godkendelsesarbejdsgang og en udløser for fornyet risikovurdering. For DORA-relevante tjenester understøtter samme bevismateriale også analyse af underleverandører og koncentrationsrisiko.

Gør supplerende foranstaltninger konkrete og dokumenterbare

Supplerende foranstaltninger må aldrig dokumenteres som “vi bruger kryptering” uden detaljer. Revisorer og enterprise-kunder vil spørge, hvad der krypteres, hvor kryptering anvendes, hvem der kontrollerer nøglerne, om udbyderens personale kan få adgang til klartekst, om logfiler indeholder personoplysninger, og hvordan privilegeret adgang godkendes.

En stærk pakke med supplerende foranstaltninger kombinerer tekniske, kontraktlige, organisatoriske og robusthedsrelaterede sikkerhedsforanstaltninger.

Clarysecs Politik for kryptografiske kontroller for SMV’er giver forankringen:

Kryptering skal anvendes på:

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

For en TIA skal denne politikerklæring omsættes til eksplicit bevismateriale. Kryptering skal beskrives for personoplysninger under overførsel mellem EU-systemer og cloudtjenester i tredjelande, i hvile i cloudlagring og i backups. Ejerskab af nøgler skal være defineret. Hvis kundeadministrerede nøgler anvendes, skal TIA’en forklare, om udbyderen kan få adgang til klartekst, hvornår supportadgang er tilladt, og hvordan administrativ adgang logges.

Clarysecs Politik for tredjeparts- og leverandørsikkerhed for SMV’er styrker dokumentationen for lokation:

Når leverandører skal opbevare data uden for organisationens lokationer, skal virksomheden indhente dokumentation for databeskyttelse, fysisk sikring og den geografiske opbevaringslokation (f.eks. EU-only hosting, hvor det kræves efter GDPR).

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.4.

Samme SMV-politik understøtter også kontraktmæssig fuldstændighed:

Kontrakter skal indeholde obligatoriske klausuler, der dækker:

Fra afsnittet “Styringskrav”, politikklausul 5.3.

For TIA’er skal disse obligatoriske klausuler dække fortrolighed, sikkerhedsforanstaltninger, underretning ved brud, underdatabehandlere, revisionsrettigheder, tilbagelevering af data, sletning, overførselsmekanismer og lokationsforpligtelser.

Opbyg en revisionsklar TIA-bevispakke

Antag, at en europæisk B2B SaaS-udbyder bruger en USA-baseret analyseplatform. Platformen indsamler kundebrugshændelser, bruger-ID’er, IP-adresser og supportmetadata. Den tilbyder EU-hosting og SCC’er, men supportpersonale uden for EØS kan få adgang til sager, og fejllogfiler kan blive behandlet af en underdatabehandler i et tredjeland.

En praktisk bevispakke kan opbygges i seks trin.

1. Opret overførselsregistreringen

Start med det Cloud Service Register, der kræves af Politik for brug af cloudtjenester for SMV’er. Tilføj serviceejer, forretningsformål, datakategorier, registrerede, rolle, hostingregion, adgangslande, supportlokationer, underdatabehandlere, overførselsmekanisme, supplerende foranstaltninger, risikovurdering og næste gennemgangsdato.

For analyseplatformen skal det registreres, at hændelser hostes i EU, at supportadgang kan finde sted uden for EØS, og at fejlovervågning skaber en videreoverførsel.

2. Vedhæft kontraktligt bevismateriale

Vedhæft DPA, SCC’er eller andet bevismateriale for overførselsmekanismen, sikkerhedsaddendum, vilkår for underretning om hændelser og liste over underdatabehandlere. Brug Politik for brug af cloudtjenester klausul 4.5.2 til at dokumentere gennemgang af SCC’er og overførselsmekanismer. Brug Politik for tredjeparts- og leverandørsikkerhed klausul 5.3.5 til at dokumentere godkendelse af eller samtykke til underdatabehandlere.

Hvis organisationen baserer sig på EU-US Data Privacy Framework for en udbyder, skal omfang, certificeringsstatus, tjenestedækning og fallback-mekanisme registreres. Antag ikke, at det dækker enhver videreoverførsel.

3. Opret risikoscenariet

Tilføj risikoen til ISMS-risikoregisteret:

“EU-personoplysninger, der behandles via analyseplatformen, kan blive tilgået fra et tredjeland af udbyderens support eller underdatabehandlere, hvilket skaber risiko for fortrolighed samt juridisk og regulatorisk efterlevelse.”

Tildel ejer, sandsynlighed, konsekvens, iboende vurdering, behandlingsplan og restvurdering. Knyt den til GDPR Chapter V, kundetilsagn, ISO/IEC 27001:2022-kontroller for cloud og leverandører, NIS2 Article 21 hvor relevant, og DORA Articles 28, 29 og 30 i kontekster i den finansielle sektor.

Clarysecs Politik for risikostyring fastsætter disciplinen for risikobehandling:

Den risikoansvarlige skal sikre, at behandlinger er realistiske, tidsbegrænsede og kortlagt til ISO/IEC 27001 Annex A-kontroller.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.2.

4. Vælg supplerende foranstaltninger

For analyseplatformen kan foranstaltninger omfatte EU-hosting, minimerede hændelsespayloads, pseudonyme identifikatorer, kryptering under overførsel, kryptering i hvile, begrænset supportadgang, MFA for administratorer, logning af privilegeret adgang, DLP-regler, der forhindrer følsomme felter i analysehændelser, forpligtelser til meddelelse om underdatabehandlere og årlig gennemgang af bevismateriale.

Kortlæg disse foranstaltninger til ISO/IEC 27002:2022-kontroller såsom 5.14 Informationsoverførsel, 5.15 Adgangsstyring, 5.20 Håndtering af informationssikkerhed i leverandøraftaler, 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester, 5.23 Informationssikkerhed ved brug af cloudtjenester, 5.31 Retlige, lovbestemte, regulatoriske og kontraktlige krav, 5.34 Privatliv og beskyttelse af PII, 8.11 Datamaskering, 8.12 Forebyggelse af datalækage, 8.16 Overvågningsaktiviteter og 8.24 Brug af kryptografi.

5. Definér udløsere for gennemgang

En TIA er ikke færdig, før udløsere for gennemgang er defineret. Udløsere skal omfatte en ny underdatabehandler, et nyt adgangsland, en ny datakategori, ændring i supportmodel, sikkerhedshændelse, kontraktfornyelse, nyt kritisk kundekrav, ny DORA-klassificering eller væsentlig ændring i cloudarkitekturen.

Det er her, ISO/IEC 27002:2022-kontrol 5.22 bliver operationel. Gennemgå SOC-rapporter, ISO-certifikater, resuméer af penetrationstest, meddelelser om tjenesteændringer, hændelseshistorik og opdateringer om underdatabehandlere. Spor undtagelser frem til lukning.

6. Opdatér SoA’en og indekset over bevismateriale

I Statement of Applicability markeres kontroller for cloud, leverandører, jura, databeskyttelse, kryptografi, adgang, overvågning, hændelser og kontinuitet som anvendelige. Tilføj SoA-noter såsom “understøtter GDPR Chapter V-TIA for analyseplatform”, “understøtter DORA-bevismateriale for IKT-tredjepartskontrakter” eller “understøtter NIS2-bevismateriale for sikkerhed i forsyningskæden”.

Det sidste indekseringstrin omsætter en databeskyttelsesvurdering til revisionsklart efterlevelsesbevismateriale.

Kortlæg det samme bevismateriale til GDPR, DORA, NIS2 og ISO 27001

En velopbygget TIA-bevispakke skal opfylde flere revisionsperspektiver uden at skabe dobbelt dokumentation.

DORA er særligt vigtig, hvor kunden er en finansiel enhed, eller tjenesten understøtter en IKT-kæde i den finansielle sektor. DORA finder anvendelse fra 17. januar 2025 og fastsætter krav til styring af IKT-risiko, hændelsesrapportering, robusthedstest, informationsdeling og IKT-tredjepartsrisiko. Article 8 kræver identifikation og klassificering af IKT-aktiver, informationsaktiver og afhængigheder. Article 28 kræver styring af IKT-tredjepartsrisiko, informationsregistre, due diligence og exitstrategier. Article 29 omhandler IKT-koncentration og risiko ved underleverandører. Article 30 kræver skriftlige kontrakter med tjenestebeskrivelser, behandlingslokationer, databeskyttelse, adgang, genopretning, tilbagelevering af data, hændelsesbistand, samarbejde med myndigheder, opsigelsesrettigheder, revisionsrettigheder og overgangsordninger.

NIS2 tilføjer ledelsesansvar. Article 20 kræver, at ledelsesorganer godkender og fører tilsyn med foranstaltninger til styring af cybersikkerhedsrisici. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder risikopolitikker, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, vurdering af kontroleffektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring og MFA, hvor det er relevant.

Overlapningen er tydelig. En TIA, der identificerer underdatabehandlere, overførselslokationer, supplerende foranstaltninger, hændelsesforpligtelser og leverandørovervågning, er også bevismateriale for leverandørrobusthed.

Hvordan revisorer vil teste din TIA

Forskellige revisorer stiller forskellige spørgsmål, men bevismaterialet skal kunne genbruges.

Zenith Controls giver en praktisk revisionsmetodik for disse områder. For cloudtjenester ser revisorer efter et register over godkendte cloudtjenester og bevismateriale for, at uautoriseret brug af cloudtjenester overvåges. For leverandøraftaler udfører revisorer kontraktstikprøver på højrisikoleverandører og validerer fortrolighed, databeskyttelse, frister for underretning ved brud, revisionsrettigheder, godkendelse af underdatabehandlere og tilbagelevering eller destruktion af data. For leverandørovervågning undersøger revisorer gennemgangsregistreringer, KPI-rapporter, leverandørcertificeringer, SOC-rapporter, resuméer af penetrationstest, undtagelser og afhjælpende foranstaltninger.

Revisionslæren er klar: Bevismateriale skal vise drift over tid. En TIA, der er underskrevet én gang og aldrig genbesøgt, vil ikke opfylde kravene i en seriøs cloud-, leverandør- eller robusthedsgennemgang.

Brug NIST CSF 2.0 til at forklare TIA-risiko for ledelsen

Bestyrelser ønsker sjældent at diskutere SCC-moduler eller cloudsupportlokationer i detaljer. De vil vide, om risikoen er styret, prioriteret og under forbedring. NIST CSF 2.0 hjælper med at omsætte TIA’en til ledelsessprog gennem GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER.

For en TIA er GOVERN-funktionen særligt nyttig. Den omfatter juridiske, regulatoriske og kontraktlige krav, risikovillighed, roller, politikker, tilsyn og styring af leverandørers cybersikkerhedsrisiko. Opbyg en Current Profile, der viser den aktuelle tilstand, f.eks. et delvist cloudregister, SCC-arkiv, begrænset gennemgang af underdatabehandlere og ingen defineret kadence for TIA-gennemgang. Definér derefter en Target Profile, f.eks. en komplet overførselsfortegnelse, risikovurderede underdatabehandlere, verificerede overførselsmekanismer, kundeadministrerede nøgler for højrisikodata, kvartalsvise gennemgange af kritiske leverandører, DORA-klar kontraktkortlægning og testede cloud-exitplaner.

Gap-planen bliver en praktisk køreplan, som ledelsen kan finansiere og følge op på.

Clarysecs cloud-TIA-tjekliste for 2026

Brug denne tjekliste til at teste, om din Transfer Impact Assessment er revisionsklar:

• Vedligehold et cloudtjenesteregister med ejer, formål, datakategorier, lokationer, adgangslande og underdatabehandlere.
• Identificér, om hver tjeneste er en dataansvarlig, databehandler, underdatabehandler eller en uafhængig leverandørrelation.
• Vedhæft DPA, SCC’er eller andet bevismateriale for overførselsmekanismen til leverandørregistreringen.
• Registrér afhængighed af EU-US Data Privacy Framework kun, hvor omfang og videreoverførsler er verificeret.
• Vedligehold oplysninger om underdatabehandlere og erklæringer om geografiske overførsler.
• Kræv forudgående skriftligt samtykke eller kontraktlig meddelelse ved nye underdatabehandlere baseret på risiko.
• Kortlæg supplerende foranstaltninger til specifikke tekniske kontroller, ikke generiske udsagn.
• Dokumentér kryptering under overførsel, kryptering i hvile, ejerskab af nøglestyring og logning af privilegeret adgang.
• Minimér, pseudonymisér eller maskér personoplysninger før overførsel, hvor det er muligt.
• Definér udløsere for gennemgang ved nye lande, nye underdatabehandlere, nye datakategorier, hændelser og kontraktændringer.
• Knyt hver TIA-risiko til risikoregisteret, behandlingsplanen og SoA’en.
• Gennemgå leverandørens bevismateriale periodisk, og spor undtagelser frem til lukning.
• Medtag hændelsesunderretning, revisionsrettigheder, tilbagelevering af data, sletning og exitforpligtelser i kontrakter.
• For DORA-relevante tjenester skal kontrakter kortlægges til IKT-tredjepartskrav, underleverandører, lokationer, koncentrationsrisiko og exitstrategi.
• Rapportér højrisikobeslutninger om overførsler til ledelsen som en del af ISMS-styringen.

Omsæt usikkerhed om overførsler til revisionsklart bevismateriale

InnovatePay vandt bankaftalen, fordi Maria holdt op med at behandle TIA’en som et juridisk dokument i sidste øjeblik. Hendes team opbyggede et Cloud Service Register, vedhæftede SCC’er og DPA’er, dokumenterede underdatabehandlere, kortlagde supplerende foranstaltninger til ISO/IEC 27001:2022-kontroller, opdaterede risikoregisteret, tilføjede SoA-noter og oprettede overvågningsudløsere. Resultatet var ikke kun et bedre svar på spørgeskemaet. Det var en gentagelig proces for leverandørrisiko.

Din organisation kan gøre det samme.

Start med Zenith Blueprint: An Auditor’s 30-Step Roadmap for at forbinde overførselsrisici med risikoregister, behandlingsplan og Statement of Applicability. Brug Zenith Controls: The Cross-Compliance Guide til at kortlægge ISO/IEC 27002:2022-kontroller for cloud, leverandøraftaler og leverandørovervågning til GDPR, NIS2, DORA, NIST og revisionsforventninger. Operationalisér derefter bevismaterialet gennem Clarysec-politikker såsom Politik for brug af cloudtjenester, Politik for tredjeparts- og leverandørsikkerhed, Politik for juridisk og regulatorisk efterlevelse, Politik for risikostyring og SMV-versionerne, hvor det er relevant.

En Transfer Impact Assessment for cloudtjenester bør ikke være en salgsnødsituation. I 2026 er den en del af cloudstyring, leverandørassurance, ansvarlighed for databeskyttelse og operationel robusthed. De organisationer, der opnår tillid, er dem, der hurtigt kan dokumentere, hvor data går hen, hvem der berører dem, hvad der beskytter dem, og hvordan risikoen styres over tid.