Styring af cloudregioner for GDPR, NIS2 og DORA

Kl. 08.17 en tirsdag morgen modtager Maria, informationssikkerhedschef i en hurtigt voksende europæisk fintech-virksomhed, den besked, som enhver reguleret cloudkunde før eller siden frygter.

Indkøbsteamet videresender en kort leverandørmeddelelse:

“Vores cloudanalyseleverandør flytter telemetri for EU-kunder til en ny region af hensyn til performance. De siger, at der ikke er nogen sikkerhedsmæssig påvirkning. Kan vi godkende det?”

Inden Maria når at svare, kommer der endnu en underretning fra den primære cloudtjenesteudbyder. Med virkning om 90 dage vil udbyderen “optimere sin globale supportmodel” ved at route Tier 2-supportsager gennem en ny underdatabehandler. En hurtig gennemgang viser, at underdatabehandleren har hovedsæde i et land uden en GDPR-afgørelse om tilstrækkeligt beskyttelsesniveau.

Kl. 09.00 er jura, databeskyttelse, robusthed, indkøb, cloud engineering og finansiel compliance koblet på tråden. DPO’en spørger, om der er behov for en konsekvensvurdering af overførslen. Den ansvarlige for robusthed spørger, om den nye region påvirker genopretningsplanen for en kritisk tjeneste. Den ansvarlige for finansiel compliance spørger, om udbyderen fremgår af DORA-registeret over IKT-tredjeparter. Cloudteamet kontrollerer produktionsmiljøets dataplan og opdager, at problemet er bredere end analyse. Backups, driftslogfiler, supportsager, eksport fra data lakes, break-glass-adgang og underleverandøradgang kan alle være omfattet.

Det er det reelle cloudstyringsproblem i 2026.

De fleste organisationer har en cloudpolitik. Mange har et leverandørregister. Nogle har en GDPR-vurdering af overførsler. Færre kan med bevismateriale besvare det vanskeligere revisionsspørgsmål:

Hvor præcist befinder regulerede data og kritisk IKT-behandling sig, hvem kan tilgå dem hvorfra, hvad sker der ved failover, og hvilken kontraktlig kontrol forhindrer udbyderen i at ændre svaret uden godkendelse?

Det er styring af cloudregioner. Det er ikke ét juridisk afkrydsningsfelt. Det er et levende kontrolsystem på tværs af ISO/IEC 27001:2022, ISO/IEC 27002:2022 cloud- og leverandørkontroller, GDPR-ansvarlighed, NIS2-tjenesterobusthed og DORA-tilsyn med IKT-tredjeparter.

Dataresidens er nu en operationel kontrol

I årevis blev “EU-only hosting” behandlet som en klausul i en databehandleraftale. Det er ikke længere tilstrækkeligt. Et moderne program for dataresidens og styring af cloudregioner skal som minimum dække seks operationelle lag:

1. Primære regioner for lagring og beregningsressourcer i produktionsmiljøet.
2. Regioner for backup, arkiv og katastrofeberedskab.
3. Lokationer for logning, overvågning, SIEM og observabilitetsdata.
4. Supportadgang, herunder fjernadministration og break-glass-adgang.
5. Underdatabehandlere og underleverandører, herunder managed services og marketplace-komponenter.
6. Dataoverførselsveje mellem miljøer, API’er, analyseplatforme og kundesupportværktøjer.

GDPR gør dette uundgåeligt, fordi personoplysninger kan omfatte onlineidentifikatorer, IP-adresser, kundekonto-ID’er, brugerregistre, enhedsidentifikatorer, driftsmetadata og supportregistreringer. Behandling er også bredt defineret og omfatter lagring, adgang, brug, videregivelse, sletning og destruktion. “Vi sender kun logfiler” er ikke en sikker undtagelse, hvis disse logfiler indeholder identifikatorer.

GDPR artikel 5 omfatter også ansvarlighedsprincippet. Dataansvarlige skal ikke blot overholde principperne om lovlighed, rimelighed, gennemsigtighed, formålsbegrænsning, dataminimering, opbevaringsbegrænsning, integritet og fortrolighed. De skal også kunne dokumentere efterlevelse. Styring af cloudregioner er en af de måder, hvorpå denne dokumentation bliver reel.

NIS2 udvider problemet fra databeskyttelse til robusthed. Efter artikel 21 skal væsentlige og vigtige enheder implementere passende tekniske, operationelle og organisatoriske foranstaltninger til at håndtere risici for net- og informationssystemer, der anvendes til drift eller levering af tjenester. De oplistede foranstaltninger omfatter sikkerhed i forsyningskæden, forretningskontinuitet, backupstyring, katastrofeberedskab, krisestyring, adgangsstyring, politik for aktivstyring, kryptering og vurdering af effektivitet. Hvis en beslutning om cloudregion påvirker tilgængeligheden eller genopretningen af en omfattet tjeneste, er det ikke kun et databeskyttelsesspørgsmål. Det er et robusthedsspørgsmål.

For finansielle enheder hæver DORA standarden yderligere. DORA finder anvendelse fra 17. januar 2025 og fastsætter krav til styring af IKT-risiko, rapportering af hændelser, test af digital operationel robusthed, styring af IKT-tredjepartsrisici og kontraktlige aftaler. Artikel 28 kræver, at finansielle enheder håndterer IKT-tredjepartsrisiko som en integreret del af styringsrammen for IKT-risikostyring, fører registre over kontraktlige aftaler, vurderer koncentrationsrisiko og planlægger exit for kritiske eller vigtige funktioner. Artikel 30 forudsætter kontraktmæssig klarhed om lokationer for tjeneste- og databehandling, revisions- og adgangsrettigheder, hændelsessupport, underleverandører, genopretning, tilbagelevering og exit-overgang.

DORA fungerer som den sektorspecifikke ordning for finansielle enheder, mens NIS2 fortsat er relevant på tværs af den bredere forsyningskæde, særligt for cloud computing-udbydere, datacenterudbydere og managed service providers. En enkelt ikkevurderet underdatabehandler kan derfor skabe en dominoeffekt på tværs af finansiel robusthed, sikkerhed i forsyningskæden og databeskyttelsesforpligtelser.

Kort sagt: Hvis en reguleret virksomhed ikke kan styre, hvor dens cloudbehandling finder sted, kan den ikke troværdigt styre IKT-tredjepartsrisiko.

Brug ISO 27001 som ledelsessystemets anker

ISO/IEC 27001:2022 giver strukturen til at omsætte uklarhed om dataresidens til et kontrolleret ledelsessystem.

Klausul 4.1 til 4.4 kræver, at organisationen definerer ISMS’et i sin kontekst, herunder interne og eksterne forhold, interessentkrav, retlige, regulatoriske og kontraktlige forpligtelser samt grænseflader og afhængigheder til andre organisationer. For styring af cloudregioner bør ISMS-omfanget eksplicit omfatte cloudtjenester, outsourcet IKT-behandling, kritiske tjenesteafhængigheder og regulerede dataflows.

Klausul 5.1 til 5.3 gør ledelsen ansvarlig. Øverste ledelse skal bringe informationssikkerhedspolitik og mål i overensstemmelse med den strategiske retning, stille ressourcer til rådighed, tildele ansvar og sikre, at ISMS-performance rapporteres. Det er her, cloudresidens bliver et ledelses- og bestyrelsesanliggende, særligt for NIS2-enheder, hvor ledelsesorganer skal godkende og føre tilsyn med foranstaltninger til cybersikkerhedsrisikostyring, og for finansielle DORA-enheder, hvor ledelsesorganet er ansvarligt for styring af IKT-risiko.

Klausul 6.1.1 til 6.1.3 udgør risikomotoren. Organisationen har brug for en gentagelig risikovurderingsproces, risikoejere, kriterier for konsekvens og sandsynlighed, behandlingsmuligheder, valgte kontroller, en anvendelighedserklæring (SoA) og accept af restrisiko. En ændring af cloudregion bør ikke godkendes via en uformel e-mail. Den bør udløse en risikovurdering eller ændringsgennemgang, når den påvirker regulerede data, kritiske funktioner, leverandører eller forudsætninger for kontinuitet.

Klausul 8.1 omsætter planlægning til operationel kontrol. Processer skal implementeres, kontrolleres, dokumenteres, ændres på en styret måde og udvides til eksternt leverede produkter og tjenester, der er relevante for ISMS’et. Klausul 8.2 og 8.3 kræver revurdering og behandling med planlagte intervaller eller ved væsentlige ændringer. Migrering af cloudregioner, backupreplikering, en ny logningsplatform eller en ændring af supportunderdatabehandler er alle kandidater til revurdering.

ISO/IEC 27002:2022-kontrolsættet giver derefter den praktiske kontrolfamilie. De mest relevante kontroller omfatter:

• 5.9 Fortegnelse over information og andre tilknyttede aktiver.
• 5.14 Informationsoverførsel.
• 5.15 Adgangsstyring.
• 5.19 Informationssikkerhed i leverandørrelationer.
• 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.29 Informationssikkerhed under afbrydelse.
• 5.30 IKT-beredskab for forretningskontinuitet.
• 5.31 Retlige, lovbestemte, regulatoriske og kontraktlige krav.
• 5.34 Privatliv og beskyttelse af personhenførbare oplysninger (PII).
• 5.36 Efterlevelse af politikker, regler og standarder for informationssikkerhed.
• 8.11 Datamaskering.
• 8.12 Forebyggelse af datalækage.
• 8.13 Informationsbackup.
• 8.15 Logning.
• 8.16 Overvågningsaktiviteter.
• 8.20 Netværkssikkerhed.
• 8.24 Brug af kryptografi.
• 8.25 Sikker udviklingslivscyklus.
• 8.27 Sikker systemarkitektur og tekniske principper.
• 8.32 Ændringsstyring.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls behandler ISO/IEC 27002:2022-kontrol 5.23, informationssikkerhed ved brug af cloudtjenester, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, med operationel kapacitet inden for sikkerhed i leverandørrelationer og sikkerhedsdomæner på tværs af styring, økosystem og beskyttelse. Vejledningen kobler 5.23 til 5.19 leverandørrelationer, 5.14 informationsoverførsel, 5.9 aktivfortegnelse, 8.11 og 8.12 datamaskering og forebyggelse af datalækage, 8.20 netværkssikkerhed og 8.25 sikker udviklingslivscyklus.

En central observation fra Zenith Controls er:

“Cloud service providers (CSP’er) fungerer som kritiske leverandører, og derfor gælder alle kontroller vedrørende leverandørvalg, kontraktindgåelse og risikostyring under 5.19. 5.23 går dog videre ved at adressere cloudspecifikke risici såsom multi-tenancy, gennemsigtighed om datalokation og modeller for delt ansvar.”

Den sætning indfanger styringsskiftet. En cloududbyder er ikke bare endnu en leverandør. Det er ofte det sted, hvor reguleret behandling finder sted.

De skjulte dataresidensfælder: backups, logfiler, support og underdatabehandlere

De fleste fejl i dataresidens starter ikke med produktionsdatabasen. De starter i understøttende systemer, som aldrig blev korrekt inkluderet i gennemgangen af dataflows.

Backups er det klassiske eksempel. En SaaS-platform kan køre i Frankfurt eller Dublin, mens automatiserede backups replikeres et andet sted af hensyn til robusthed eller omkostninger. Hvis backuppen indeholder personoplysninger, kunderegistre, autentifikationslogfiler eller reguleret transaktionshistorik, har backupregionen betydning. Efter NIS2 artikel 21 er backupstyring og katastrofeberedskab en del af sikkerhedsbaselinen. Efter DORA kræver kontinuitet for kritiske eller vigtige funktioner og testede exitstrategier kendskab til genopretningslokationer og genopretningsafhængigheder.

Logfiler er et andet svagt punkt. Sikkerhedsteams centraliserer telemetri i SIEM-, observabilitets- og data lake-tjenester. Disse logfiler kan indeholde IP-adresser, brugeridentifikatorer, administratorhandlinger, betalingsmetadata, mislykkede autentifikationsforsøg, kundekonto-ID’er eller supportsporingsdata. Hvis logfiler flyttes til en global overvågningstjeneste, kan organisationen have etableret en grænseoverskridende overførsel uden at opdage det.

Clarysecs Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV adresserer direkte leverandørbevismateriale:

“Kontrakter skal kræve, at udbydere opbevarer logfiler i mindst 12 måneder og giver adgang efter anmodning”

Dette citat kommer fra afsnittet “Styringskrav”, politikklausul 5.5.1.3. For styring af dataresidens skal den samme kontraktgennemgang bekræfte, hvor disse logfiler opbevares, hvem der kan tilgå dem, og om logbevismateriale er tilgængeligt under en hændelsesundersøgelse eller regulatorisk forespørgsel.

Supportadgang er mere subtil. En udbyder kan hoste data i EU, mens supportteknikere uden for EU kan tilgå kundemiljøer, databasesnapshots, diagnostikpakker eller vedhæftede filer i supportsager. Om dette er acceptabelt, afhænger af de involverede data, overførselsmekanismen, rollen, de kontraktlige sikkerhedsforanstaltninger, adgangskontrollerne og logningen. Arkitekturen kan være regional, mens den menneskelige adgangsmodel er global.

Underdatabehandlere skaber den sidste blinde vinkel. Din direkte leverandør kan være afhængig af cloudinfrastruktur, content delivery networks, administrerede databaser, ticketingplatforme, analysetjenester, offshore-supportteams eller sikkerhedsleverandører. DORA artikel 29 kræver vurdering af underleverandørrisici, tredjelandsudbydere, begrænsninger for datagendannelse, efterlevelse af databeskyttelse og komplekse underleverandørkæder. NIS2 artikel 21 kræver, at enheder tager hensyn til cybersikkerhedspraksis hos direkte leverandører og tjenesteudbydere. GDPR kræver, at databehandlere styrer underdatabehandlere på en måde, der bevarer den dataansvarliges mulighed for at efterleve kravene.

Clarysecs Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV gør dette praktisk:

“Hvor leverandører skal lagre data uden for organisationens lokationer, skal virksomheden indhente sikkerhed for databeskyttelse, fysisk sikring og geografisk lagringslokation (f.eks. EU-only hosting, hvor GDPR kræver det).”

Dette er fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.4. Den samme politik kræver også:

“Begrænsninger for yderligere underleverandører uden godkendelse”

Dette citat kommer fra afsnittet “Styringskrav”, politikklausul 5.3.5. Tilsammen gør disse klausuler dataresidens til en arbejdsgang for leverandørstyring, ikke en indkøbspræference.

Omsæt politik til bindende styring af cloudregioner

Styring af cloudregioner skal kunne håndhæves, gennemgås og revideres.

For SMV’er fastlægger Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV baselinen:

“Praksis for dataresidens og databeskyttelse overholder gældende retlige krav (f.eks. GDPR)”

Dette er fra afsnittet “Styringskrav”, politikklausul 5.2.3. Den samme politik kræver, at registreringer for cloudstyring omfatter:

“Det land eller den region, hvor data lagres”

Dette citat kommer fra afsnittet “Styringskrav”, politikklausul 5.3.4.

For større organisationer er Politik for brug af cloudtjenester Politik for brug af cloudtjenester mere eksplicit om kontraktlig håndhævelse:

“Krav til dataresidens skal håndhæves kontraktligt (f.eks. EU-only-lagring for GDPR-regulerede data).”

Dette er fra afsnittet “Krav til implementering af politikken”, politikklausul 6.6.2. Den angiver også:

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

Dette er fra afsnittet “Krav til implementering af politikken”, politikklausul 6.6.3.

Enterprise-versionen retter også opmærksomheden mod:

“Garantier for dataresidens og dataejerskab”

Dette citat kommer fra afsnittet “Roller og ansvar”, politikklausul 4.5.1.2.

Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed tilføjer kontraktlaget ved at kræve:

“Krav til datahåndtering, herunder lagringslokation, adgangskontroller og klausuler om tilbagelevering eller destruktion”

Dette citat kommer fra afsnittet “Styringskrav”, politikklausul 5.3.2.

Endelig identificerer Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse ændringer, der skal udløse efterlevelsesgennemgang, herunder:

“Ændringer i dataoverførselsmekanismer, underdatabehandlere eller grænseoverskridende dataflows”

Dette er fra afsnittet “Styringskrav”, politikklausul 5.3.1.1.

Disse dokumenter bør ikke fungere som separate filer. I et modent ISMS bliver de til én driftsmodel: cloudfortegnelse, dataflowregister, leverandørregister, kontraktmatrix, risikovurdering, overførselsgennemgang, ændringsgodkendelse og pakke med revisionsbevismateriale.

Opbyg et register for styring af cloudregioner

Et praktisk register omsætter cloudresidens fra antagelse til bevismateriale. Start med én kritisk kundevendt tjeneste, især en tjeneste, der sandsynligvis er omfattet af NIS2, DORA-kundedue diligence eller GDPR-kontrol.

Kobl derefter registeret til implementeringen.

I Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint fokuserer fasen Controls in Action, trin 23, på organisatoriske kontroller 5.19 til 5.37, herunder leverandøraftaler og styring af cloudtjenester. Blueprint advarer om, at leverandøraftaler skal dække mere end generel fortrolighed:

“I mange brancher definerer leverandøraftaler også dataejerskab og jurisdiktion. Hvor behandles data? Hvem bevarer kontrollen? Er der overførselsbegrænsninger? Er der cloudspecifikke kontroller (såsom datasegmentering, nøgleejerskab eller geografiske begrænsninger)? Disse elementer er ikke kun juridiske; de er operationelle sikkerhedsspørgsmål, især i regulerede sektorer.”

Den samme fase og det samme trin adresserer ændringsstyring af leverandører:

“De fleste leverandørrelationer begynder med gode intentioner. En grundig gennemgang, klare forventninger, underskrevne aftaler (se 5.20), måske endda en sikkerhedstjekliste. Men hvad sker der et år senere, når leverandøren foreslår at flytte dine data til en ny cloudregion?”

Det er Marias tirsdag morgen-problem. Registeret giver informationssikkerhedschefen en måde at svare på, før flytningen godkendes.

Zenith Blueprint præciserer også styringsbetydningen af cloudkontrol 5.23:

“En fejlkonfigureret storage bucket, et offentligt eksponeret dashboard eller for brede rettigheder i en cloud-IAM-opsætning er ikke cloudfejl. Det er styringssvigt.”

I fasen Controls in Action, trin 22, adresserer Blueprint informationsoverførsel og anfører:

“Hvis personoplysninger overføres på tværs af grænser, skal metoden overholde databeskyttelses- og retlige forpligtelser, ikke blot interne præferencer.”

Den pointe er vigtig for cloudteams. Kryptering, sikre API’er og privat forbindelsesetablering er nødvendige, men de erstatter ikke juridisk og regulatorisk styring af overførsler.

Gennemfør den første 90-minutters workshop om bevismateriale

Begynd ikke med at kortlægge hele organisationen. Start med én kritisk tjeneste, og gennemfør en fokuseret workshop med cloud engineering, indkøb, jura, databeskyttelse, robusthed og sikkerhedsdrift.

Først skal alle cloud- eller leverandørkomponenter, der lagrer, behandler, transmitterer, sikkerhedskopierer, overvåger eller understøtter tjenesten, oplistes. Medtag mindre systemer såsom overvågning af oppetid, vedhæftede filer i supportsager, fejlsporing, skærmdelingsværktøjer til support og diagnostiske eksporter.

Dernæst markeres hver datakategori. Hvis teamet siger “kun metadata”, skal antagelsen udfordres. Metadata kan stadig være personoplysninger eller fortrolige kundedata.

For det tredje skal regionen verificeres med bevismateriale. Brug konfiguration i cloudkonsollen, backuppolitikker, SIEM-tenancy-indstillinger, DPA-bilag, lister over underdatabehandlere, kontraktvilkår, dokumentation for supportadgang og CSP-revisionsrapporter. Stol ikke kun på salgsmæssige forsikringer.

For det fjerde skal huller registreres i ISMS-risikoregisteret. Eksempler omfatter “backupreplikeringsregion er ikke kontraktligt begrænset”, “supportadgang fra tredjeland mangler dokumenteret godkendelsesarbejdsgang”, “SIEM-logfiler opbevares globalt”, “listen over underdatabehandlere identificerer ikke hostingregion” eller “DORA-registeret skelner ikke afhængigheder for kritiske eller vigtige funktioner”.

For det femte besluttes risikobehandling. Behandlinger kan omfatte kontraktændring, regionslås, kundeunderretning, kryptering med kundeadministrerede nøgler, tokenisering, logminimering, godkendelse af ny leverandør, opdatering af exitstrategi eller accept af restrisiko af risikoejeren.

For det sjette skal bevismateriale bevares. Revisorer vil ikke kun spørge, hvad I besluttede. De vil spørge, hvordan I ved, at det blev implementeret.

Kortlæg ét bevismaterialesæt til ISO, GDPR, NIS2, DORA og NIST CSF 2.0

Et stærkt program for styring af cloudregioner undgår dobbeltarbejde med efterlevelse. Det samme bevismateriale kan understøtte flere forpligtelser, hvis det struktureres korrekt.

NIST CSF 2.0 er nyttig som et integrerende lag. Funktionen GOVERN stemmer overens med retlige, regulatoriske, kontraktlige og databeskyttelsesrelaterede forpligtelser, risikovillighed, ansvarlighed, politikker og tilsyn. Kategorien GV.SC for forsyningskæden passer godt til DORA-forventninger til IKT-tredjeparter, NIS2-krav til forsyningskæden og ISO-leverandørkontroller.

COBIT 2019 og et ISACA-revisionsperspektiv tester ofte de samme forhold gennem styringsmål: ejerskab, beslutningsrettigheder, risikooptimering, leverandørperformance, realisering af gevinster og assurance. En COBIT-orienteret reviewer begynder måske ikke med “hvilken cloudregion er konfigureret?” De kan begynde med “hvem har beføjelse til at godkende en regionsændring, hvordan eskaleres risiko, og hvordan ved ledelsen, at cloudleverandører fortsat ligger inden for tolerancen?”

Derfor indfanger Clarysec-modellen ejere, godkendelsespunkter, kontraktligt bevismateriale og ledelsesrapportering, ikke kun tekniske indstillinger.

Forbered jer på revisors spørgsmål

Styring af cloudregioner er et godt eksempel på, hvordan forskellige revisorer ser på den samme kontrol fra forskellige vinkler.

En ISO/IEC 27001:2022-revisor vil begynde med omfang, interessentkrav, risikovurdering og anvendelighedserklæring. Revisoren vil spørge, om retlige, regulatoriske og kontraktlige krav er identificeret, om cloud- og leverandørkontroller er inkluderet, om risici er vurderet, om kontroller er implementeret, og om bevismateriale opbevares. Revisoren kan udtage én cloudtjeneste som stikprøve og bede om onboarding-gennemgang, kontraktklausuler, regionskonfiguration, overvågningsgennemgang og ændringsgodkendelse.

En databeskyttelsesmyndighed eller GDPR-reviewer vil fokusere på personoplysninger. De vil spørge, hvilke personoplysninger der behandles, hvor de lagres, hvorfra de tilgås, hvilke databehandlere og underdatabehandlere der er involveret, om overførselsmekanismer er dokumenteret, om en konsekvensvurdering af overførslen er nødvendig, og om passende tekniske og organisatoriske foranstaltninger er på plads. Logfiler, supportdata og backups får ofte opmærksomhed, fordi organisationer undervurderer dem.

En NIS2-revisor eller kompetent myndighed vil fokusere på tjenester, der er omfattet. De vil se på ledelsens ansvarlighed efter artikel 20, risikostyringsforanstaltninger efter artikel 21, kontinuitet, backupstyring, katastrofeberedskab, hændelseshåndtering, sikkerhed i forsyningskæden, adgangsstyring, politik for aktivstyring og vurdering af effektivitet.

En DORA-tilsynsmyndighed eller et internt revisionsteam vil se efter styring af IKT-risiko, tilsyn fra ledelsesorganet, informationsregisteret for IKT-tredjepartsaftaler, kortlægning af kritiske eller vigtige funktioner, koncentrationsrisiko, underleverandørrisiko, lokationer for databehandling, revisionsrettigheder, støtte til hændelsesrapportering, kontinuitetstest og exitplaner. DORA er tydelig på, at outsourcing ikke overfører ansvarlighed.

Zenith Controls hjælper sikkerhedsledere med at forberede sig på disse revisionsstile, fordi den krydshenviser kontrolrelationer. For ISO/IEC 27002:2022-kontrol 5.20, håndtering af informationssikkerhed i leverandøraftaler, knytter Zenith Controls den til 5.19 leverandørrelationer, 5.14 informationsoverførsel, 5.22 leverandørovervågning, 5.11 tilbagelevering af aktiver og 5.36 efterlevelse af politikker, regler og standarder. For kontrol 5.22, overvågning, gennemgang og ændringsstyring af leverandørtjenester, knytter den løbende leverandørtilsyn til 5.29 sikkerhed under afbrydelse, 8.8 styring af tekniske sårbarheder, 5.15 adgangsstyring, 8.27 sikker systemarkitektur og tekniske principper samt 5.36 efterlevelse.

Dette tværkontrolperspektiv er vigtigt, fordi en regionsændring aldrig kun er en regionsændring. Den kan ændre leverandørrisiko, overførselsrisiko, adgangsrisiko, kontinuitetsrisiko, bevismateriale til hændelseshåndtering og kontraktlig efterlevelse.

Brug denne CISO-tjekliste fra 2026 før godkendelse af en cloudændring

Brug denne tjekliste, før I godkender en ny cloudregion, grænseoverskridende behandlingsvej, backuplokation, logningsplatform, supportmodel eller kritisk ændring hos en IKT-leverandør.

Hvis svaret på et spørgsmål er “det antager vi”, er kontrollen ikke moden nok til regulerede driftsaktiviteter.

Afhjælpningskøreplanen

Afhjælpningsvejen er praktisk, når den er forankret i ISMS’et.

1. Bekræft, at ISMS-omfanget omfatter cloudtjenester, kritiske IKT-afhængigheder og reguleret databehandling.
2. Opbyg registeret for styring af cloudregioner for prioriterede tjenester.
3. Kortlæg hver tjeneste til datakategorier, regioner, backuplokationer, supportadgang og underdatabehandlere.
4. Gennemgå leverandøraftaler for klausuler om lagringslokation, overførsel, revision, hændelser, underleverandører, tilbagelevering og destruktion.
5. Opdater risikoregisteret med huller, koncentrationsrisici og udokumenterede overførsler.
6. Afstem DORA-registeret over IKT-tredjeparter og NIS2-kortlægning af tjenesteafhængigheder, hvor det er relevant.
7. Valider teknisk håndhævelse, herunder regionslåse, backuppolitikker, logningsindstillinger, kryptering, adgangskontroller og nøglestyring.
8. Udarbejd en pakke med revisionsbevismateriale med skærmbilleder, kontrakter, risikoregistreringer, godkendelser, referater fra gennemgange og testresultater.
9. Etabler en ændringsudløser for nye regioner, underdatabehandlere, overførselsmekanismer eller ændringer i kritiske leverandørtjenester.
10. Rapportér risiko ved cloudresidens, undtagelser og beslutninger om restrisiko til ledelsen.

Dette er ikke teoretisk efterlevelse. Det er forskellen på et cloudmiljø, der kan modstå revisionskontrol, og et miljø, der afhænger af mundtlige forsikringer.

Business casen: suverænitet, robusthed og tillid

Topledere ser undertiden styring af dataresidens som en begrænsning for cloudagilitet. I praksis forbedrer moden regionsstyring agiliteten, fordi teams kender reglerne, før de køber, bygger eller migrerer.

Et produktteam kan lancere hurtigere, når godkendte regioner er tydelige. Indkøb kan forhandle hurtigere, når obligatoriske klausuler allerede er defineret. Jura kan vurdere overførsler hurtigere, når dataflows er dokumenteret. Sikkerhedsdrift kan undersøge hurtigere, når loglokationer og adgangsrettigheder er kendte. Bestyrelsen kan træffe risikobeslutninger hurtigere, når koncentrationsrisiko, påvirkning af kontinuitet og accept af restrisiko er synlige.

For kunder, særligt regulerede kunder, bliver dette et tillidssignal. En SaaS-udbyder, der kan forklare, hvor data befinder sig, hvordan backups styres, hvordan supportadgang kontrolleres, hvordan underdatabehandlere godkendes, og hvordan regionsændringer gennemgås, vil klare sig bedre end en udbyder, der blot siger “vi bruger en førende cloududbyder”.

I 2026 har denne forskel betydning. NIS2 har bragt cybersikkerhedsstyring ind i væsentlige og vigtige enheder i hele EU. DORA har gjort tilsyn med IKT-tredjeparter til en formel disciplin i finanssektoren. GDPR-ansvarlighed er fortsat central. ISO/IEC 27001:2022 giver ledelsessystemet, der binder det hele sammen.

Næste skridt med Clarysec

Hvis din organisation ikke kan svare på, hvor regulerede data og kritisk IKT-behandling befinder sig på tværs af produktion, backups, logfiler, supportadgang og underleverandører, er det nu, hullet skal lukkes.

Clarysec kan hjælpe jer med at opbygge en pakke med bevismateriale for styring af cloudregioner ved hjælp af:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint til faseopdelt ISO-implementering og revisionsberedskab.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls til kortlægning af ISO/IEC 27002:2022 cloud- og leverandørkontroller til operationelt bevismateriale og forventninger på tværs af frameworks.
• Politik for brug af cloudtjenester Politik for brug af cloudtjenester og Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV til krav om clouddataresidens.
• Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed og Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV til leverandørkontrakter, underleverandører og sikkerhed for geografisk lagring.
• Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV til opbevaring af logfiler og bevismateriale fra udbydere.
• Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse til udløsere for efterlevelsesgennemgang vedrørende overførselsmekanismer, underdatabehandlere og grænseoverskridende dataflows.

Start med én kritisk tjeneste, én cloududbyder og ét register. På få workshops kan I bevæge jer fra antagelser til bevismateriale og fra fragmenteret efterlevelse til styret cloudrobusthed.

Download Clarysec-værktøjssættet, anmod om en demo, eller book en vurdering af styring af cloudregioner for at omsætte jeres forpligtelser om cloudresidens til revisionsklart bevismateriale.