Cloud-audit er vurderingen af sikkerhed, kontroller og efterlevelse i cloudmiljøer, og disciplinen er blevet stadig vigtigere, efterhånden som organisationer har flyttet mere forretning til AWS, Microsoft Azure, Google Cloud eller hybride platforme.
En Cloud Security Auditor vurderer, om cloudmiljøer er designet, konfigureret og drevet på en måde, der beskytter data, understøtter compliance og giver ledelsen et retvisende billede af risiko. Rollen ligger i krydsfeltet mellem teknisk cloud-sikkerhed, it-revision, risikostyring og juridisk forståelse, især i danske og europæiske organisationer hvor GDPR, databehandleraftaler og internationale dataoverførsler ofte er en del af auditens scope.
Efterspørgslen hænger sammen med, at cloud ikke længere kun er et infrastrukturvalg. Cloud er blevet platformen for kundedata, udviklingsmiljøer, analyse, identitetsstyring og forretningskritiske applikationer. Gartner pegede i 2022 på fortsat vækst i sikkerheds- og risikostyringsudgifter, herunder cloud security, i sin pressemeddelelse om markedsudviklingen. Den slags prognoser bør læses som markedsbaggrund, ikke som garanti for job eller løn, men de forklarer, hvorfor cloud-audit fylder mere i både interne sikkerhedsteams, konsulenthuse og revisionsmiljøer.
Sidst opdateret: 2026. Artiklen er redigeret med fokus på certificeringer, der faktisk findes, dansk og europæisk compliance-kontekst samt praktiske auditopgaver frem for generelle karriereråd. Kilder og referencepunkter omfatter blandt andet Cloud Security Alliance, NIST SP 800-53, ISO/IEC 27001:2022, ISACA CISA, (ISC)² CCSP, Datatilsynet, EU-retspraksis om internationale overførsler og cloud-udbydernes egne sikkerheds- og compliance-dokumenter.
En Cloud Security Auditor skal kunne læse både teknik og risiko. Det betyder, at vedkommende skal forstå identitets- og adgangsstyring, logging, netværkssegmentering, kryptering, backup, konfigurationsstyring og DevOps-praksis, men også kunne omsætte tekniske observationer til kontroller, afvigelser, risikovurderinger og anbefalinger, som ledelse og compliance-funktioner kan bruge.
Rollen passer ofte til tre typer profiler. Den første er it-revisoren, der allerede forstår revisionsmetodik, evidens og kontroltest, men skal styrke sin cloudforståelse. Den anden er sikkerheds- eller compliance-specialisten, der arbejder med ISO 27001, GDPR eller risikostyring og vil tættere på cloudmiljøernes faktiske konfigurationer. Den tredje er cloud-ingeniøren, der har teknisk erfaring fra drift eller platformsteams og ønsker at arbejde mere struktureret med assurance, governance og kontrolmodning.
En almindelig fejl er at se rollen som enten ren compliance eller ren teknik. En cloud-audit bliver svag, hvis den kun bekræfter, at der findes politikker, uden at teste om de virker. Den bliver også svag, hvis den kun finder tekniske fejlkonfigurationer uden at koble dem til risiko, kontrolmål og forretningens krav. Den dygtige auditor kan bevæge sig mellem begge niveauer.
En cloud-audit starter sjældent med værktøjer. Den starter med scope. Auditoren skal forstå, hvilke cloudkonti, abonnementer, projekter, workloads, data og tredjepartsintegrationer der er omfattet, og om auditens formål er intern risikovurdering, ISO 27001-understøttelse, leverandørkontrol, GDPR-vurdering eller forberedelse til ekstern revision.
Derefter kortlægges kontrollerne. I praksis kan en organisation bruge CSA Cloud Controls Matrix, NIST SP 800-53, ISO/IEC 27001:2022 Annex A, CIS Controls eller egne interne kontrolkataloger. Opgaven er ikke at kopiere en ramme ukritisk, men at oversætte den til cloudmiljøets faktiske arkitektur. En kontrol om adgangsstyring skal for eksempel konkretiseres til IAM-roller, privilegerede konti, betinget adgang, servicekonti, nøglerotation og godkendelsesflows.
Herefter indsamles evidens. I AWS kan det være CloudTrail, AWS Config, IAM-politikker, KMS-konfigurationer og S3 bucket-indstillinger. I Azure kan det være Activity Log, Entra ID-roller, Azure Policy, Key Vault-konfiguration, Defender for Cloud-anbefalinger og ressourcehistorik. I Google Cloud kan det være Cloud Audit Logs, IAM-bindings, Organization Policies, Cloud KMS og Security Command Center-observationer. Infrastruktur som kode er også vigtig evidens, fordi Terraform-, Bicep- eller CloudFormation-skabeloner kan vise, om sikkerhedskontroller er indbygget i deployment-processen eller manuelt efterjusteret.
Kontroltestene bør være få nok til at være grundige og relevante nok til at sige noget om risiko. En adgangskontroltest kan undersøge, om privilegerede roller er begrænset, godkendt og logget. En krypteringstest kan dokumentere, om data er krypteret under lagring, om nøgler styres passende, og om adgang til nøgler er adskilt fra adgang til data. En backup-test kan vurdere, om gendannelse faktisk er testet, ikke blot om backup er aktiveret.
Rapporteringen er den del, hvor mange tekniske profiler undervurderer arbejdet. Et godt fund beskriver ikke bare, at en indstilling er forkert. Det forklarer kriteriet, observationen, risikoen, påvirkningen, årsagen og en realistisk anbefaling. Det skelner også mellem en isoleret fejlkonfiguration og et systemisk problem i governance, deployment eller ejeransvar.
Cloud-udbydere leverer omfattende sikkerhedsfunktioner, men kunden er stadig ansvarlig for store dele af konfigurationen. Det kaldes modellen for delt ansvar. I praksis betyder det, at auditoren skal afgøre, hvilke kontroller organisationen selv skal teste, og hvilke der kan arves gennem cloud-udbyderens dokumentation, certificeringer og rapporter.
For eksempel vil en cloud-udbyders ISO 27001-certifikat eller SOC-rapport typisk sige noget om udbyderens datacentre, driftsprocesser og platformskontroller. Den dokumentation beviser ikke, at kundens egne IAM-roller er passende, at logging er aktiveret, at krypteringsnøgler er styret korrekt, eller at udviklingsteamet har undgået offentligt eksponerede storage-containere. Auditoren skal derfor læse udbyderdokumentation som arvet assurance, ikke som en erstatning for kundens egne kontroltests.
En praktisk faldgrube er at acceptere screenshots som tilstrækkelig evidens uden at vurdere tidspunkt, kilde, scope og ændringshistorik. Et screenshot kan være nyttigt, men cloudmiljøer ændrer sig hurtigt. Eksporter, logudtræk, policy-definitioner, konfigurationshistorik og IaC-repositorier giver ofte bedre dokumentation, fordi de kan knyttes til tid, ressource og ændringsproces.
I Danmark og EU kan en cloud-audit ikke begrænses til tekniske sikkerhedskontroller, hvis personoplysninger indgår i scope. GDPR stiller krav til behandlingsgrundlag, passende tekniske og organisatoriske foranstaltninger, databehandleraftaler og dokumenteret risikovurdering. For en auditor betyder det, at sikkerhedstest og juridisk-compliance dokumentation skal hænge sammen.
Databehandleraftaler efter GDPR artikel 28 er et konkret auditområde. Auditoren bør undersøge, om aftalen beskriver behandlingsformål, underdatabehandlere, sikkerhedsforanstaltninger, sletteprocesser, auditrettigheder og håndtering af brud på persondatasikkerheden. Det er ikke nok at konstatere, at en aftale findes; den skal matche den faktiske cloudbrug og de data, der behandles.
Schrems II og efterfølgende EU-vejledning om internationale dataoverførsler har gjort lokation, adgang og supplerende foranstaltninger mere relevante. En audit kan derfor omfatte, hvor data lagres, hvem der kan tilgå dem, hvilke support- og fjernadgangsmodeller der bruges, om krypteringsnøgler kontrolleres af kunden, og om organisationen har dokumenteret sin vurdering af overførselsrisici. Det er især vigtigt i regulerede sektorer som finans, sundhed, offentlig sektor og kritisk infrastruktur.
Certificeringer kan hjælpe med at strukturere læring og gøre kompetencer lettere at vurdere, men de erstatter ikke praktisk erfaring. En nuanceret diskussion af værdien af it-certificeringer bør altid skelne mellem viden, eksamensbevis og dokumenteret evne til at anvende stoffet i et rigtigt miljø.
For cloud-audit er CSA CCSK ofte et godt fundament, fordi den giver en bred forståelse af cloud-sikkerhed, governance og risikoområder. CCSP fra (ISC)² er mere avanceret og passer bedre til profiler med solid sikkerhedserfaring; credentialet har erfaringskrav, mens Associate-vejen kan være relevant for kandidater, der endnu ikke opfylder hele kravet. CISA fra ISACA er stærk for it-revision og kontrolforståelse, mens ISO/IEC 27001:2022 Lead Auditor er relevant for dem, der skal planlægge, gennemføre og rapportere audits op mod et ledelsessystem for informationssikkerhed.
Udbyderspecifikke certificeringer bør vælges efter det miljø, kandidaten faktisk arbejder med. AWS Security Specialty, Microsoft AZ-500, Microsoft SC-100 og Google Professional Cloud Security Engineer kan alle være relevante, men de løser forskellige problemer. En auditor med revisionsbaggrund kan begynde med CCSK, CISA eller ISO 27001 Lead Auditor og derefter tilføje en cloudplatform. En cloud-ingeniør kan gøre det omvendt: først dokumentere platformsikkerhed og derefter bygge revisionsmetodik ovenpå.
Det er værd at være præcis her, fordi markedet rummer mange upræcise råd. Certifikater som “CompTIA Certified Cloud Security Specialist” eller en generisk “ISACA Cloud Security Auditor” bør ikke bruges som karrieremål, hvis de ikke findes som faktiske, aktuelle credentials. Læsere, der vil fordybe sig i (ISC)²-sporet, kan orientere sig i ISC2-relateret træning, men certificeringsvalget bør altid afhænge af erfaring, rolle og det cloudmiljø, der skal auditeres.
Den mest holdbare vej begynder med fundamentet: netværk, identitet, kryptering, logging, risikostyring og grundlæggende cloudarkitektur. Derefter bør kandidaten lære én cloudplatform godt nok til at kunne finde og forstå relevante sikkerhedsindstillinger uden konstant at følge en guide. Først når den tekniske base er på plads, giver det fuld værdi at arbejde systematisk med auditrammer, kontrolmapping og rapportering.
Et stærkt læringsprojekt er at bygge en lille cloudløsning med infrastruktur som kode, aktivere logging, oprette roller med mindst mulige rettigheder, konfigurere kryptering og dokumentere en kontroltest. Projektet behøver ikke være stort. Det vigtige er, at kandidaten kan vise, hvad scope var, hvilken kontrol der blev testet, hvilken evidens der blev indsamlet, hvilke afvigelser der blev fundet, og hvordan anbefalingen blev formuleret.
Et eksempel kan være en storage-løsning med følsomme testdata, hvor kandidaten dokumenterer adgangsstyring, offentlig eksponering, kryptering, logning og backup. Til en jobsamtale er en sådan portefølje ofte mere overbevisende end en generel erklæring om cloudinteresse, fordi den viser både teknisk forståelse og auditorens måde at tænke på.
Løn for Cloud Security Auditor-roller i Danmark bør vurderes i danske kroner og ud fra danske kilder som Jobindex, Glassdoor DK, fagforeningers lønstatistikker og konkrete stillingsopslag. Den internationale lønside Glassdoor-eksemplet for cloud security engineer-løn kan give kontekst for et beslægtet amerikansk jobmarked, men den bør ikke bruges direkte til danske lønforventninger, fordi titel, geografi, pensionsforhold, skat og branche varierer.
I Danmark vil lønnen typisk afhænge af, om rollen er intern eller konsulentbaseret, hvor teknisk hands-on arbejdet er, hvor meget revisionsansvar der følger med, og om kandidaten kan dække både cloudplatform, ISO/GDPR og interessenthåndtering. Regulerede sektorer kan stille højere krav til dokumentation og auditmodenhed, mens cloud-native virksomheder ofte vægter praktisk platformserfaring og automatisering højere.
Stillingsbetegnelser kan også skjule rollen. Cloud Security Auditor kan optræde som IT Auditor, Cloud Security Consultant, Security Assurance Specialist, GRC Consultant, Compliance Engineer eller Cloud Risk Specialist. Jobsøgningen bør derfor fokusere på opgaver og krav, ikke kun på én titel.
En kandidat bør kunne forklare en cloud-audit fra start til slut uden at gøre den abstrakt. Interviewere vil ofte lede efter tegn på, at kandidaten kan afgrænse scope, forstå delt ansvar, indsamle troværdig evidens, teste kontroller og formulere fund på en måde, der kan handles på. Det er også vigtigt at kunne sige, hvornår et fund er kritisk, og hvornår det er en forbedringsmulighed.
Fra et praktisk perspektiv er kommunikation lige så vigtig som teknisk kontroltest. En auditor skal kunne udfordre et cloudteam uden at skabe unødvendig modstand, og samtidig kunne forklare ledelsen, hvorfor en tilsyneladende lille konfiguration kan have stor konsekvens for adgang, sporbarhed eller databeskyttelse.
Cloud Security Auditor-rollen bliver mere teknisk, men også mere forretningsnær. Automatiserede kontroller, policy-as-code og continuous compliance betyder, at auditoren i stigende grad skal forstå pipelines, konfigurationsdrift og cloud-native sikkerhedsværktøjer. Samtidig kræver ledelser og tilsyn mere dokumentation for, at cloudbrug er styret, risikovurderet og i overensstemmelse med krav til databeskyttelse.
Det mest effektive næste skridt er at kombinere ét solidt cloudspor med revisionsmetodik og EU-compliance. Readynez kan være relevant som én læringspartner for kandidater, der vil strukturere certificeringsforberedelsen, men karriereudviklingen bør måles på evnen til at gennemføre en troværdig audit i praksis. Læsere, der ønsker et bredere sikkerhedsspor, kan bruge sikkerhedstræning på tværs af teknologier eller Unlimited Security Training som en måde at samle flere relevante emner uden at miste fokus på den konkrete rolle.
Få ubegrænset adgang til ALLE de LIVE instruktørledede sikkerhedskurser du ønsker - til en pris mindre end prisen for ét kursus.
Du ser vores Denmark (DKK) hjemmeside fra United States
Vil du gerne se siden i
English
med priser i
Dollar?