Revisionsbevis for cloud til ISO 27001, NIS2 og DORA

Maria, CISO i en hurtigt voksende virksomhed inden for finansiel analyse, havde seks uger, før tre frister faldt sammen. Hendes ISO 27001:2022-overvågningsaudit var allerede planlagt. NIS2 havde bragt virksomheden ind i et nyt niveau af ledelsesmæssig ansvarlighed som en vigtig enhed. DORA skulle til at teste, om hendes fintech-drift kunne dokumentere digital operationel robusthed. Samtidig tilbageholdt en stor enterprise-kunde en kontrakt, indtil hendes team kunne bestå en detaljeret gennemgang af sikkerhedsdokumentation.

Virksomheden var ikke usikker. Den kørte produktionsworkloads i AWS og Azure, brugte Microsoft 365 og flere kritiske SaaS-platforme, håndhævede MFA, tog backup af data, scannede for sårbarheder og indsamlede cloudlogfiler. Problemet var dokumentationen.

Revisionsbeviset var spredt på Slack-skærmbilleder, udviklerwiki-sider, eksportfiler fra cloudkonsoller, indkøbsmapper, juridiske kontrakter og mundtlige forsikringer fra platformsejere. Når en auditor spurgte: “Vis mig, hvordan I kontrollerer jeres cloudmiljø,” ville et link til en cloududbyders side om compliance ikke være nok. Udbyderens certifikater dokumenterede udbyderens kontroller. De dokumenterede ikke Marias del af modellen for delt ansvar.

Det er her, mange programmer for revisionsbevis for cloudsikkerhed fejler. Ikke fordi kontrollerne mangler, men fordi organisationen ikke kan dokumentere på en struktureret og sporbar måde, hvilke ansvarsområder der ligger hos udbyderen, hvilke der ligger hos kunden, hvordan SaaS- og IaaS-kontroller er konfigureret, hvordan leverandørforpligtelser håndhæves, og hvordan revisionsbevis opbevares til auditorer, tilsynsmyndigheder og kunder.

Cloud-compliance er ikke længere et teknisk bilag. For en SaaS-udbyder under NIS2, en finansiel enhed under DORA eller enhver ISO 27001:2022-organisation, der bruger IaaS, PaaS og SaaS, er cloudstyring en del af ISMS-omfanget, risikobehandlingsplanen, leverandørlivscyklussen, hændelsesprocessen, ansvarligheden for databeskyttelse og ledelsens gennemgang.

Det praktiske mål er enkelt: opbyg én cloud-bevisarkitektur, der er klar til myndighedstilsyn, og som besvarer spørgsmål fra ISO 27001:2022, NIS2, DORA, GDPR, kundedokumentation og intern audit uden at genopbygge revisionsbevis for hvert rammeværk.

Cloud er altid inden for omfanget, også når infrastrukturen er outsourcet

Den første auditfælde er at antage, at outsourcet infrastruktur ligger uden for ISMS. Det gør den ikke. Outsourcing ændrer kontrolgrænsen; den fjerner ikke ansvarlighed.

ISO/IEC 27001:2022 kræver, at organisationen definerer sin kontekst, interessenter, ISMS-omfang, grænseflader, afhængigheder og processer. I en cloud-first-virksomhed er identitetsudbyderen, cloudhostingkontoen, CRM, e-mailplatformen, data warehouse, CI/CD-pipeline, helpdesk-systemet og backuptjenesten ofte central forretningsinfrastruktur.

Clarysecs Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint fremhæver dette i fasen ISMS-grundlag og ledelse, trin 2, interessentbehov og ISMS-omfang:

“Hvis du outsourcer din IT-infrastruktur til en cloududbyder, udelukker det den ikke fra omfanget; i stedet medtager du styringen af den relation og cloudaktiverne som en del af omfanget (fordi sikkerheden for dine data i cloud er dit ansvar).”

Denne formulering er et auditanker. Jeres omfang bør ikke sige: “AWS er udelukket, fordi Amazon administrerer det.” Det bør sige, at informationsaktiver og processer relateret til tjenester hostet på AWS er inden for omfanget, herunder styring af cloudsikkerhedskontroller, identitet, logning, kryptering, backup, leverandørdokumentation og hændelseshåndtering.

For ISO 27001:2022 understøtter dette klausul 4.1 til 4.4 om kontekst, interessenter, omfang og ISMS-processer. For NIS2 understøtter det Article 21-forventninger til risikoanalyse, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker anskaffelse og vedligeholdelse, adgangsstyring, politik for aktivstyring, kryptografi, kontroleffektivitet og MFA, hvor det er relevant. For DORA understøtter det princippet om, at finansielle enheder fortsat er ansvarlige for IKT-risiko, også når IKT-tjenester er outsourcet.

Spørgsmålet er ikke, om jeres cloududbyder er sikker. Spørgsmålet er, om I styrer jeres brug af udbyderen, konfigurerer jeres del korrekt, overvåger tjenesten, styrer leverandørforpligtelser og opbevarer revisionsbevis.

Delt ansvar skal blive til delt revisionsbevis

Cloududbydere forklarer delt ansvar. Auditorer tester, om I har operationaliseret det.

I IaaS sikrer udbyderen normalt fysiske faciliteter, kerneinfrastruktur og hypervisoren. Kunden kontrollerer identitet, workloadkonfiguration, hærdning af operativsystemer, applikationssikkerhed, dataklassificering, krypteringsindstillinger, netværksregler, logning, backup, patching og hændelseshåndtering.

I SaaS kontrollerer udbyderen størstedelen af platformens drift, men kunden kontrollerer stadig tenantkonfiguration, brugere, administratorroller, integrationer, datadeling, opbevaring, logningsmuligheder og eskalationsprocedurer.

Clarysecs Zenith Controls: Vejledning til tværgående efterlevelse Zenith Controls behandler ISO/IEC 27002:2022 control 5.23, informationssikkerhed ved brug af cloudtjenester, som en central cloudstyringskontrol med forebyggende formål på tværs af fortrolighed, integritet og tilgængelighed. Den forbinder cloudtjenester med leverandørrelationer, sikker informationsoverførsel, aktivfortegnelse, forebyggelse af datalækage, endpoint- og netværkssikkerhed samt praksis for sikker udvikling.

En central fortolkning i Zenith Controls siger:

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

Denne sondring er kritisk. Leverandørcertifikater alene opfylder ikke Annex A.5.23. I har brug for revisionsbevis fra kundesiden, der dokumenterer, at cloudtjenesten er styret, konfigureret, overvåget og gennemgået.

Dette er forskellen mellem at have cloudkontroller og at have cloudkontroller, der er klar til audit.

Start med et register over cloudtjenester, som auditorer kan bruge

Den hurtigste måde at forbedre cloud-revisionsberedskabet på er at oprette et komplet register over cloudtjenester. Det må ikke blot være en indkøbsliste eller en eksport fra økonomisystemet. Det skal forbinde cloudtjenester med data, ejere, regioner, adgang, kontrakter, kritikalitet, regulatorisk relevans og revisionsbevis.

Clarysecs SMV Politik for brug af cloudtjenester-sme Politik for brug af cloudtjenester-sme giver en kompakt og auditvenlig baseline i klausul 5.3:

“Et register over cloudtjenester skal vedligeholdes af IT-leverandøren eller GM. Det skal registrere: 5.3.1 Navn og formål for hver godkendt cloudtjeneste 5.3.2 Den ansvarlige person eller det ansvarlige team (applikationsansvarlig) 5.3.3 De typer data, der lagres eller behandles 5.3.4 Det land eller den region, hvor data lagres 5.3.5 Brugeradgangstilladelser og administrative konti 5.3.6 Kontraktdetaljer, datoer for kontraktfornyelse og supportkontakter”

For enterprise-miljøer fastlægger Clarysecs Politik for brug af cloudtjenester Politik for brug af cloudtjenester det bredere mandat:

“Denne politik fastlægger organisationens obligatoriske krav til sikker, compliant og ansvarlig brug af cloud computing-tjenester på tværs af leveringsmodellerne Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) og Software-as-a-Service (SaaS).”

Politik for brug af cloudtjenester kræver et centraliseret register, der ejes af CISO, og godkendte baselinekonfigurationer for cloudmiljøer. Dette register bliver grundlaget for revisionsbevis til flere forpligtelser på én gang.

For ISO 27001:2022 understøtter det aktivfortegnelse, styring af brugen af cloudtjenester, leverandørrelationer, adgangsstyring, juridiske og kontraktlige krav, risikobehandling og dokumenteret information. For NIS2 understøtter det forsyningskædesikkerhed, politik for aktivstyring, risikoanalyse, hændelseshåndtering og forretningskontinuitet. For DORA understøtter det kortlægning af IKT-aktiver og afhængigheder, IKT-tredjepartsregistre, kortlægning af kritiske eller vigtige funktioner og analyse af koncentrationsrisiko. For GDPR identificerer det, om personoplysninger behandles, hvor de befinder sig, hvilken udbyder der fungerer som databehandler, og hvilke overførselsvilkår eller databehandleraftalevilkår der gælder.

Hvis registret ikke identificerer datakategorier og regioner, vil dokumentation for databeskyttelse og robusthed være ufuldstændig. Hvis det ikke identificerer applikationsejere, bliver adgangsgennemgange ejerløse. Hvis det ikke identificerer kontrakter og datoer for kontraktfornyelse, kan leverandørernes sikkerhedsklausuler ikke testes.

Gør ISO 27001:2022 til rygraden i cloud-revisionsbeviset

ISO 27001:2022 er den bedste rygrad for cloud-revisionsbevis, fordi standarden forbinder forretningskontekst, risiko, kontroller, driftsdokumentation, overvågning og forbedring.

Vigtige cloudrelevante ISO 27001:2022-krav omfatter:

• Klausul 4.1 til 4.4 for kontekst, interessenter, ISMS-omfang, grænseflader, afhængigheder og processer.
• Klausul 5.1 til 5.3 for ledelse, politik, roller, ansvar og ansvarlighed.
• Klausul 6.1.1 til 6.1.3 for risikovurdering, risikobehandling, sammenligning med Annex A, Anvendelseserklæring og accept af restrisiko.
• Klausul 7.5 for kontrolleret dokumenteret information.
• Klausul 8.1 til 8.3 for operationel planlægning, gennemførelse af risikovurdering og gennemførelse af risikobehandling.
• Klausul 9.1 til 9.3 for overvågning, måling, intern audit og ledelsens gennemgang.
• Klausul 10 for afvigelse, korrigerende handling og løbende forbedring.

De Annex A-kontroller, der bærer mest cloud-revisionsbevis, omfatter A.5.19 Informationssikkerhed i leverandørrelationer, A.5.20 Håndtering af informationssikkerhed i leverandøraftaler, A.5.21 Styring af informationssikkerhed i IKT-forsyningskæden, A.5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester, A.5.23 Informationssikkerhed ved brug af cloudtjenester, A.5.24 til A.5.27 hændelsesstyring, A.5.29 Informationssikkerhed under driftsforstyrrelser, A.5.30 IKT-beredskab for forretningskontinuitet, A.5.31 Retlige, lovbestemte, regulatoriske og kontraktlige krav, A.5.34 Privatliv og beskyttelse af personhenførbare oplysninger (PII), A.5.36 Overholdelse af politikker, regler og standarder for informationssikkerhed, A.8.8 styring af tekniske sårbarheder, A.8.9 konfigurationsstyring, A.8.13 Informationsbackup, A.8.15 Logning, A.8.16 Overvågningsaktiviteter, A.8.24 Brug af kryptografi, A.8.25 Sikker udviklingslivscyklus, A.8.29 Sikkerhedstest i udvikling og accept samt A.8.32 Ændringsstyring.

I Zenith Blueprint forklarer fasen Kontroller i praksis, trin 23, cloudtjenester på en måde, der giver mening for auditorer:

“Skiftet til cloudtjenester medfører grundlæggende ændringer i tillidsmodellen. Du kontrollerer ikke længere serveren, netværksperimeteren eller hypervisoren. Ofte ved du ikke engang, hvor data fysisk befinder sig. Det, du kontrollerer, og det denne kontrol håndhæver, er styringen af relationen, synligheden i det, du bruger, og de sikkerhedsforventninger, du stiller til dine udbydere.”

En stærk Anvendelseserklæring-post for A.5.23 bør ikke kun sige “Relevant, cloududbyder certificeret.” Den bør forklare, hvorfor kontrollen gælder, hvilke risici den behandler, hvordan den er implementeret, og hvor revisionsbeviset opbevares.

Tilføj en kolonne for placering af revisionsbevis i SoA eller kontroltrackeren. Auditorer bør ikke være nødt til at søge i e-mail, helpdesk-systemer og fællesdrev for at finde dokumentation.

Brug én bevismodel for ISO 27001:2022, NIS2 og DORA

NIS2 og DORA kræver begge dokumenteret, risikobaseret og ledelsesforankret cybersikkerhed. Overlappet er betydeligt, men det tilsynsmæssige pres er forskelligt.

NIS2 gælder for mange væsentlige og vigtige enheder i EU, herunder udbydere af digital infrastruktur, managed service providers (MSP’er), managed security service providers, banker, finansielle markedsinfrastrukturer og digitale udbydere. Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker anskaffelse og vedligeholdelse, sårbarhedshåndtering, vurdering af kontroleffektivitet, cyberhygiejne, træning, kryptografi, adgangsstyring, politik for aktivstyring og MFA eller sikker kommunikation, hvor det er relevant.

For revisionsbevis for cloudsikkerhed spørger NIS2, om cloud- og leverandørrisici styres som en del af risikoen ved tjenestelevering. NIS2 medfører også struktureret rapportering af væsentlige hændelser, herunder tidlig varsling inden for 24 timer, hændelsesunderretning inden for 72 timer og en endelig rapport inden for én måned.

DORA finder anvendelse fra 17. januar 2025 på mange finansielle enheder i EU og fastlægger ensartede krav til styring af IKT-risiko, rapportering af større IKT-hændelser, test af digital operationel robusthed, informationsdeling og IKT-tredjepartsrisiko. For finansielle enheder, der også er identificeret under NIS2, behandles DORA som den sektorspecifikke EU-retsakt for overlappende driftsmæssige forpligtelser.

For cloud er DORA direkte. Finansielle enheder forbliver ansvarlige for IKT-risiko, når tjenester outsources. De har brug for strategier for IKT-tredjeparter, kontraktregistre, prækontraktuelle vurderinger, due diligence, revisions- og adgangsrettigheder, ophørsudløsere, analyse af koncentrationsrisiko, kontroller for underleverandører og testede exitstrategier.

Zenith Controls kortlægger ISO/IEC 27002:2022 control 5.23 til EU NIS2 Article 21 og DORA Articles 28 to 31. Den peger også på understøttende standarder som ISO/IEC 27017 for cloudsikkerhedsroller og overvågning, ISO/IEC 27018 for beskyttelse af PII i public cloud, ISO/IEC 27701 for privatlivsstyring i relationer med cloud-databehandlere, ISO/IEC 27036-4 for overvågning af cloudtjenester og leverandøraftaler samt ISO/IEC 27005 for cloudrisikovurdering.

Den praktiske konsekvens er enkel. Opbyg ikke separate bevispakker for ISO 27001:2022, NIS2, DORA og GDPR. Opbyg én cloud-bevisarkitektur med rammeværksspecifikke kortlægninger.

Leverandørkontrakter er kontrolbevis, ikke juridiske arkiver

Cloud-revisionsbevis bryder ofte sammen i kontraktlaget. Sikkerhed har et leverandørspørgeskema. Jura har MSA’en. Indkøb har fornyelsesdatoen. DPO har DPA’en. Ingen har et samlet overblik over, om aftalen indeholder de sikkerhedsklausuler, der kræves af ISO 27001:2022, NIS2, DORA og GDPR.

Clarysecs SMV Politik for tredjeparts- og leverandørsikkerhed-sme Politik for tredjeparts- og leverandørsikkerhed-sme angiver i klausul 5.3:

“Kontrakter skal indeholde obligatoriske klausuler, der dækker: 5.3.1 Fortrolighed og fortrolighedsaftale 5.3.2 Informationssikkerhedsforpligtelser 5.3.3 Underretningsfrister ved brud på persondatasikkerheden (f.eks. inden for 24–72 timer) 5.3.4 Revisionsrettigheder eller tilgængelighed af dokumentation for efterlevelse 5.3.5 Begrænsninger i yderligere underleverandørkæder uden godkendelse 5.3.6 Ophørsvilkår, herunder sikker returnering eller destruktion af data”

For auditmæssig konsistens bør disse klausuler omsættes til en kontraktgennemgangsmatrix. ISO 27001:2022 Annex A.5.20 forventer, at sikkerhedskrav aftales med leverandører. GDPR Article 28 kræver databehandlervilkår, der dækker fortrolighed, sikkerhedsforanstaltninger, bistand, underdatabehandlere, sletning eller returnering af data og auditbistand. DORA Article 30 kræver detaljerede kontraktlige bestemmelser for IKT-tredjepartsudbydere, herunder tjenestebeskrivelser, dataplacering, sikkerhed, hændelsesbistand, samarbejde med myndigheder, revisionsrettigheder, adgangsrettigheder, ophør og overgangsordninger. NIS2-forsyningskædesikkerhed kræver også bindende leverandørsamarbejde.

Zenith Controls kortlægger ISO/IEC 27002:2022 control 5.20 til leverandøraftaler og bemærker forbindelser til 5.19 leverandørrelationer, 5.14 informationsoverførsel, 5.22 leverandørovervågning, 5.11 returnering af aktiver og 5.36 efterlevelse.

Det centrale er operationalisering. Hvis en cloudkontrakt giver adgang til SOC 2-rapporter, kan auditorer spørge, om I indhentede rapporten, gennemgik undtagelser, sporede afhjælpning og revurderede risiko. Hvis kontrakten lover underretning ved brud, kan de spørge, om jeres hændelses-playbook indeholder leverandørens kontaktvej og regulatoriske beslutningspunkter. Hvis ændringer i underleverandører kræver godkendelse eller varsel, kan de spørge, om underdatabehandlerunderretninger gennemgås før accept.

En kontrakt uden dokumenteret gennemgang er et arkiv. En kontrakt, der er koblet til leverandørrisiko, overvågningsregistreringer og hændelsesworkflows, er en kontrol.

SaaS-logning og -konfiguration er almindelige auditblinde vinkler

Cloudkonstateringer kommer ofte fra SaaS, ikke IaaS. Infrastrukturteams har normalt tekniske ejere, logningspipelines, baselinekontroller og ændringsregistreringer. SaaS-platforme er fragmenteret på tværs af salg, HR, økonomi, customer success, marketing og drift. Hver af dem kan behandle følsomme eller regulerede data.

Clarysecs Lognings- og overvågningspolitik-sme Lognings- og overvågningspolitik-sme adresserer dette direkte i klausul 5.5:

“5.5 Cloudtjenester og tredjepartslogning 5.5.1 For platforme, hvor logning ikke er under direkte IT-kontrol (f.eks. SaaS-e-mail), gælder følgende krav: 5.5.1.1 Logning skal aktiveres og konfigureres, hvor det er tilgængeligt 5.5.1.2 Alarmer skal sendes til IT-supportleverandøren 5.5.1.3 Kontrakter skal kræve, at udbydere opbevarer logfiler i mindst 12 måneder og giver adgang efter anmodning”

For enterprise-miljøer tilføjer Politik for brug af cloudtjenester:

“Cloudtjenester skal integreres i organisationens SIEM med henblik på løbende overvågning.”

Dette krav flytter SaaS fra “forretningsværktøj” til “overvåget informationssystem.” Revisionsbevis bør omfatte eksport af logningsindstillinger, dokumentation for SIEM-connector, alarmregler, triagetickets, opbevaringsindstillinger og gennemgang af administratoradgang.

For kritisk SaaS skal der forberedes revisionsbevis for oprettelse af administratorkonti, mistænkelige login, massedownloads, offentlig deling, deaktivering af MFA, oprettelse af API-tokens, ekstern gæsteaktivitet og eskalering af rettigheder. For IaaS skal der forberedes CloudTrail eller tilsvarende kontrolplanslogning, logfiler for lageradgang, IAM-ændringer, flowlogfiler hvor relevant, CSPM-konstateringer, sårbarhedsscanninger, patchdokumentation, krypteringsindstillinger, backupstatus, gennemgange af netværkssikkerhedsgrupper og ændringstickets.

Zenith Controls revisionsmetodik for control 5.23 bemærker, at en ISO/IEC 27007-lignende audit kan inspicere AWS S3 bucket-tilladelser, kryptering, IAM-politikker og CloudTrail-logning. En COBIT-orienteret auditor kan gennemgå alarmkonfigurationer, DLP-kontroller, brug af Microsoft 365 Secure Score og ændringsstyringslogfiler. Et NIST SP 800-53A-perspektiv kan teste kontostyring og overvågning, herunder om cloudworkloads patches, scannes og overvåges med samme grundighed som interne systemer.

Forskellige auditorer taler forskellige dialekter. Jeres revisionsbevis bør være det samme.

Opbyg en bevispakke klar til myndighedstilsyn for én SaaS- og én IaaS-tjeneste

En praktisk arbejdsgang starter med én kritisk SaaS-platform og ét kritisk IaaS-miljø. For eksempel Microsoft 365 til samarbejde og AWS til produktionshosting.

Trin 1: Opdater registret over cloudtjenester

For Microsoft 365 registreres formål, ejer, datatyper, region, administratorkonti, kontrakt, DPA, supportkontakt, fornyelsesdato og kritikalitet. For AWS registreres produktionskontoen, regioner, datakategorier, workloads, kontoejer, status for root-konto, supportplan, kontraktvilkår og tilknyttede forretningstjenester.

Brug felterne fra Politik for brug af cloudtjenester-sme som minimumsdatasæt. Tilføj kritikalitet, regulatorisk relevans og placering af revisionsbevis.

Trin 2: Dokumentér delt ansvar

For Microsoft 365 omfatter kundens ansvarsområder brugerens livscyklus, MFA, betinget adgang, gæstedeling, opbevaringsmærkninger, DLP hvor det bruges, logning og hændelseseskalering. For AWS omfatter kundens ansvarsområder IAM, netværksregler, workloadhærdning, krypteringskonfiguration, backup, logning, patching og applikationssikkerhed.

Vedhæft udbyderens dokumentation for delt ansvar, og kortlæg derefter hvert kundeansvar til en kontrolansvarlig og en kilde til revisionsbevis.

Trin 3: Indsaml konfigurationsbevis

For Microsoft 365 eksporteres eller tages skærmbilleder af MFA og politikker for betinget adgang, administratorroller, indstillinger for ekstern deling, revisionslogning, opbevaringskonfiguration og handlinger vedrørende sikkerhedsscore. For AWS eksporteres IAM-adgangskodepolitik, privilegeret MFA-status, CloudTrail-konfiguration, S3-blokering af offentlig adgang, krypteringsstatus, gennemgang af security groups, backupjob og status for sårbarhedsscanning.

Politik for brug af cloudtjenester kræver, at cloudmiljøer overholder en dokumenteret baselinekonfiguration godkendt af Cloud Security Architect. Jeres bevispakke bør omfatte både baselinen og dokumentation for overensstemmelse.

Trin 4: Kobl leverandør- og privatlivsbevis

Vedhæft kontrakten, DPA, listen over underdatabehandlere, vilkår for underretning ved brud, auditdokumentationsrapporter og dokumentation for dataplacering. Hvis personoplysninger behandles, registreres det, om udbyderen fungerer som databehandler, hvordan sletning håndteres, hvordan support til anmodninger fra registrerede fungerer, og hvilke overførselsgarantier der gælder.

For DORA skal det identificeres, om cloudtjenesten understøtter en kritisk eller vigtig funktion. Hvis ja, kobles revisionsbeviset til IKT-tredjepartsregistret, due diligence-filen, revisionsrettigheder, exitplanen og gennemgangen af koncentrationsrisiko.

Trin 5: Forbind logning med hændelseshåndtering

Dokumentér, at logfiler er aktiveret, videresendt, gennemgået og brugt. Vedhæft SIEM-dashboards, alarmregler og mindst én lukket alarmticket. Kortlæg derefter workflowet til rapporteringsmæssige beslutningspunkter i NIS2 og DORA.

For NIS2 skal hændelsesprocessen understøtte 24-timers tidlig varsling, 72-timers hændelsesunderretning og en endelig rapport inden for én måned for væsentlige hændelser. For DORA bør IKT-hændelsesprocessen klassificere hændelser efter berørte kunder, transaktioner, varighed, nedetid, geografisk udbredelse, datapåvirkning, tjenestens kritikalitet og økonomisk påvirkning.

Trin 6: Opbevar revisionsbevis disciplineret

Clarysecs Politik for revisions- og efterlevelsesovervågning-sme Politik for revisions- og efterlevelsesovervågning-sme klausul 6.2 definerer praktisk disciplin for revisionsbevis:

“6.2 Indsamling og dokumentation af bevismateriale 6.2.1 Alt bevismateriale skal opbevares i en central revisionsmappe. 6.2.2 Filnavne skal tydeligt henvise til revisionsemnet og datoen. 6.2.3 Metadata (f.eks. hvem der indsamlede det, hvornår og fra hvilket system) skal dokumenteres. 6.2.4 Bevismateriale skal opbevares i mindst to år eller længere, hvor det kræves efter certificerings- eller kundeaftaler.”

Enterprise-versionen Politik for revisions- og efterlevelsesovervågning Politik for revisions- og efterlevelsesovervågning angiver målet:

“At generere juridisk forsvarligt bevismateriale og et revisionsspor til støtte for regulatoriske forespørgsler, retssager eller anmodninger fra kunder om dokumentation.”

Et skærmbillede kaldet “screenshot1.png” er svagt revisionsbevis. En fil kaldet “AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” er stærkere, fordi den beskriver systemet, kontrollen, datoen og indsamleren. Metadata betyder noget, fordi auditorer skal kunne stole på, hvornår revisionsbeviset blev indsamlet, hvem der indsamlede det, og fra hvilket system.

Hvordan auditorer tester den samme cloudkontrol

De stærkeste cloud-bevispakker er designet til flere auditvinkler. ISO 27001:2022-auditorer tester, om kontrollen findes i ISMS, risikovurderingen, risikobehandlingen og SoA. NIST-orienterede vurderingsparter tester den tekniske implementering. COBIT 2019-auditorer tester styring, leverandørperformance og procesintegration. Privatlivsauditorer fokuserer på databehandlerforpligtelser, dataresidens, brudberedskab og registreredes rettigheder. DORA-tilsynsgennemgange fokuserer på IKT-tredjepartsrisiko og robusthed.

Zenith Controls omfatter disse forskelle i revisionsmetodik for cloudtjenester, leverandøraftaler og leverandørovervågning. For 5.22, overvågning, gennemgang og ændringsstyring af leverandørtjenester, fremhæver den, at auditorer kan inspicere kvartalsvise referater fra leverandørgennemgange, KPI-rapporter, evalueringer af SOC-rapporter, ændringslogfiler, risikovurderinger, leverandørhændelser og sagssporing. For 5.20, håndtering af informationssikkerhed i leverandøraftaler, fremhæver den kontraktstikprøver for fortrolighed, sikkerhedsforpligtelser, underretning ved brud, revisionsrettigheder, godkendelse af underleverandører og ophørsvilkår.

Tværgående compliancekontroller, der bærer cloud-revisionsbyrden

En cloud-bevismodel, der er klar til myndighedstilsyn, bygges omkring et mindre antal højeffektive kontroller. Disse kontroller bærer en stor del af compliancebyrden på tværs af ISO 27001:2022, NIS2, DORA, GDPR, NIST og COBIT 2019.

NIST SP 800-53 Rev.5 tilføjer teknisk dybde gennem kontostyring, eksterne systemtjenester, løbende overvågning, systemovervågning og beskyttelse af systemgrænser. COBIT 2019 tilføjer styringsmæssig dybde gennem styring af leverandørrelationer, leverandørrisiko, dataudveksling, netværkssikkerhed og ændringsberedskab.

Understøttende ISO-standarder skærper bevismodellen. ISO/IEC 27017 giver cloudspecifik vejledning om delte roller, konfiguration af virtuelle maskiner og overvågning af kundeaktivitet. ISO/IEC 27018 fokuserer på beskyttelse af PII i public cloud. ISO/IEC 27701 udvider privatlivsforpligtelser til databehandler- og dataansvarliges drift. ISO/IEC 27036-4 understøtter cloudleverandøraftaler og overvågning. ISO/IEC 27005 understøtter cloudrisikovurdering.

Ledelsens gennemgang skal se cloudrisiko, ikke kun cloudoppetid

Et af de mest oversete auditspor er ledelsens gennemgang. ISO 27001:2022 forventer, at ledelsens gennemgang tager højde for ændringer, interessentbehov, performancetendenser, auditresultater, risikobehandlingsstatus og forbedringsmuligheder. NIS2 kræver, at ledelsesorganer godkender foranstaltninger til cybersikkerhedsrisikostyring og fører tilsyn med implementeringen. DORA kræver, at ledelsesorganet definerer, godkender, fører tilsyn med og forbliver ansvarligt for styring af IKT-risiko.

Et kvartalsvist dashboard for cloudsikkerhed og leverandører bør vise:

• Antal godkendte cloudtjenester.
• Kritiske cloudtjenester og ejere.
• Tjenester, der behandler personoplysninger.
• Tjenester, der understøtter kritiske eller vigtige funktioner.
• Åbne højrisiko-fejlkonfigurationer i cloud.
• Status for MFA og gennemgang af privilegeret adgang.
• Logdækning for kritiske SaaS- og IaaS-platforme.
• Modtagne og gennemgåede leverandørdokumentationsrapporter.
• Kontraktundtagelser og accepterede risici.
• Cloudhændelser, nærved-hændelser og læringspunkter.
• Resultater af backup- og gendannelsestest.
• Status for koncentrationsrisiko og exitplan.

Dette dashboard bliver revisionsbevis for ISO 27001:2022-ledelse og præstationsevaluering, NIS2-styring og DORA-ledelsesansvarlighed.

Zenith Blueprint anbefaler i risikostyringsfasen, trin 14, krydshenvisning til regulatoriske krav ved implementering af risikobehandlinger og politikker. Den angiver, at kortlægning af centrale reguleringskrav til ISMS-kontroller er en nyttig intern øvelse og “også imponerer revisorer/vurderingsparter, fordi I ikke styrer sikkerhed i et vakuum, men er opmærksomme på den juridiske kontekst.”

Det er den modenhed, tilsynsmyndigheder og enterprise-kunder forventer.

Almindelige cloud-auditkonstateringer, og hvordan de undgås

På tværs af arbejde med cloud-revisionsberedskab er tilbagevendende konstateringer forudsigelige:

1. Registeret over cloudtjenester findes, men SaaS-værktøjer mangler.
2. Dataplacering er ikke registreret eller er kopieret fra marketingsider i stedet for kontraktdokumentation.
3. MFA er håndhævet for medarbejdere, men ikke for alle administrative konti eller break-glass-konti.
4. Cloudlogfiler er aktiveret, men ikke gennemgået, opbevaret eller forbundet med hændelseshåndtering.
5. Leverandørers SOC-rapporter arkiveres, men vurderes ikke.
6. Kontraktklausuler findes for nye leverandører, men ikke for ældre kritiske tjenester.
7. Underretninger om underdatabehandlere modtages via e-mail, men risikovurderes ikke.
8. Backupjob kører korrekt, men gendannelsestest er ikke dokumenteret.
9. Delt ansvar forstås af teknikere, men dokumenteres ikke for auditorer.
10. SoA markerer cloudkontroller som relevante, men linker ikke til risikoposter, revisionsbevis eller ejere.

Dette er sporbarhedsproblemer. Løsningen er at forbinde politik, risiko, kontrol, ejer, revisionsbevis og gennemgang.

Da Maria nåede auditdagen, var hun ikke længere afhængig af spredte skærmbilleder. Hun åbnede et centralt dashboard, der viste registret over cloudtjenester, risikovurderinger, SoA-poster, bevis for baselinekonfiguration, leverandørgennemgangsfiler, logningsbevis og DORA-gennemgang af koncentrationsrisiko. Da auditoren spurgte, hvordan cloudrisici blev styret, viste hun ISMS. Da auditoren spurgte, hvordan tjenester blev konfigureret sikkert, viste hun baselinen og CSPM-beviset. Da auditoren spurgte om IKT-tredjepartsrisiko, viste hun kontraktgennemgangen, leverandørovervågningen og exitplanlægningen.

Resultatet var ikke et perfekt miljø. Intet cloudmiljø er perfekt. Forskellen var, at risikobeslutninger var dokumenteret, revisionsbevis var forsvarligt, og ansvarlighed var synlig.

Opbyg jeres cloud-bevispakke, før auditoren spørger

Hvis jeres organisation er afhængig af SaaS, IaaS eller PaaS, vil jeres næste audit ikke acceptere “udbyderen håndterer det” som et tilstrækkeligt svar. I skal dokumentere delt ansvar, kundesidens konfiguration, leverandørklausuler, logning, hændelsesberedskab, robusthed og ledelsestilsyn.

Start med tre praktiske handlinger i denne uge:

1. Opret eller opdater jeres register over cloudtjenester ved hjælp af Clarysecs Politik for brug af cloudtjenester Politik for brug af cloudtjenester eller Politik for brug af cloudtjenester-sme Politik for brug af cloudtjenester-sme.
2. Kortlæg jeres fem vigtigste cloudtjenester til ISO 27001:2022 Annex A-kontroller, NIS2 Article 21, DORA IKT-tredjepartsforpligtelser hvor relevant og GDPR-databehandlerkrav.
3. Opbyg en central bevismappe ved hjælp af disciplinen for opbevaring og metadata fra Politik for revisions- og efterlevelsesovervågning Politik for revisions- og efterlevelsesovervågning eller Politik for revisions- og efterlevelsesovervågning-sme Politik for revisions- og efterlevelsesovervågning-sme.

Brug derefter Zenith Blueprint Zenith Blueprint til at placere arbejdet i den 30-trins ISMS-auditkøreplan, og Zenith Controls Zenith Controls til at validere kortlægninger på tværs af compliance, understøttende ISO-standarder og forventninger til revisionsmetodik.

Clarysec kan hjælpe jer med at omsætte spredte cloudskærmbilleder, leverandørfiler og SaaS-indstillinger til en bevispakke, der er klar til myndighedstilsyn og kan modstå ISO 27001:2022-certificeringsaudits, NIS2-tilsynsspørgsmål, DORA-gennemgange af IKT-tredjeparter og enterprise-kunders krav om dokumentation.