SaaS Security Posture Management til revisioner i 2026

SaaS-revisionskonstateringen, som ingen ejede

Kl. 08:15 en tirsdag modtager CISO’en i en hurtigt voksende fintech-virksomhed en besked fra databeskyttelsesrådgiveren (DPO): “Hvorfor kan en kundeeksport deles offentligt fra et samarbejdsværktøj, og hvem godkendte OAuth-appen, der kan læse den?”

Kl. 09:00 bekræfter økonomiafdelingen, at værktøjet betales med et afdelingskort og ikke via centralt indkøb. Kl. 10:30 opdager IT, at brugeren, der oprettede det offentlige link, fratrådte virksomheden for tre måneder siden. Ved middagstid spørger Legal, om der er tale om et brud på persondatasikkerheden efter GDPR. Kl. 14:00 spørger risikokomitéen, om forholdet påvirker NIS2-cyberhygiejne og DORA IKT-tredjepartsrisiko. Kl. 16:00 beder intern revision om baselinekonfigurationer, gennemgange af administratoradgang, ejerskab for cloudtjenester, logfiler og leverandør-due diligence.

Den ubehagelige sandhed er, at organisationen ikke oplevede et klassisk SaaS-nedbrud eller et leverandørsvigt. Den oplevede et styringssvigt.

Det scenarie er ikke længere usædvanligt. Et marketingteam kobler en AI-platform til et CRM med brede OAuth-tilladelser. HR køber et nicheværktøj til analyse uden om indkøb. Et kundesupportteam aktiverer offentlige ticket-eksporter af hensyn til bekvemmelighed. Engineering integrerer en browserudvidelse i en udviklingsarbejdsgang. Hver beslutning kan virke lille, men tilsammen skaber de en distribueret kontrolflade fyldt med regulerede data, privilegerede arbejdsgange og driftsmæssige afhængigheder.

SaaS Security Posture Management, eller SSPM, er disciplinen, der omsætter denne spredte SaaS-virkelighed til styret, testet og revisionsbar kontrol. Når det udføres korrekt, giver det CISO’er, complianceansvarlige, revisorer og forretningsejere ét samlet revisionsspor for ISO/IEC 27001:2022, NIS2-cyberhygiejne, DORA IKT-risiko og sikkerhedsansvarlighed efter GDPR.

Clarysecs holdning er klar: SSPM bør ikke behandles som endnu et dashboard. Det skal indlejres i ISMS, kobles til risikoejerskab, kortlægges til retlige forpligtelser, understøttes af politikker og testes gennem tilbagevendende bevismateriale.

Det er her, Zenith Blueprint: en revisors 30-trins køreplan Zenith Blueprint, Zenith Controls: vejledning på tværs af efterlevelseskrav Zenith Controls og Clarysecs politikskabeloner bliver praktiske. De hjælper med at omsætte SaaS-spredning til en kontrolmodel, som en revisor kan forstå, og som et ledelsesorgan kan føre tilsyn med.

Hvorfor SaaS Security Posture Management er blevet et complianceproblem

SaaS blev tidligere behandlet som “software, andre driver.” Den forståelse er ikke længere forsvarlig.

Efter NIS2 kan mange cloud-, SaaS-, digital infrastruktur-, managed service- og managed security-udbydere være omfattet af regulerede cybersikkerhedsforventninger afhængigt af sektor, størrelse, rolle og kritikalitet. Vigtigere er det, at organisationer, der baserer sig på SaaS, skal styre det som en del af deres egne risikostyringsforanstaltninger. NIS2 Article 20 gør ledelsesorganer ansvarlige for at godkende foranstaltninger til styring af cybersikkerhedsrisici, føre tilsyn med implementeringen og modtage træning. Article 21 kræver praktiske tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder risikoanalyse, politikker, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og vedligeholdelse, test af effektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, politik for aktivstyring og multifaktorautentifikation, hvor det er relevant.

DORA hæver kravene yderligere for finansielle enheder. Siden 17. januar 2025 har DORA været gældende for mange organisationer i den finansielle sektor som regime for operationel robusthed for omfattede enheder. DORA kræver IKT-governance, identifikation og klassificering af IKT-aktiver og understøttede funktioner, beskyttelses- og forebyggelseskontroller, hændelsesstyring, kontinuitet, test og styring af IKT-tredjepartsrisiko. SaaS-udbydere, der understøtter kritiske eller vigtige funktioner, bliver en del af DORA-bevismaterialets perimeter, mens den regulerede finansielle enhed fortsat er ansvarlig.

GDPR tilføjer et lag af bevismateriale for databeskyttelse. Article 5 kræver integritet, fortrolighed og ansvarlighed. Article 32 kræver passende behandlingssikkerhed. I praksis skal en organisation vide, hvilke personoplysninger der findes, hvor de behandles, hvem der kan tilgå dem, hvilke leverandører der behandler dem, og hvilke sikkerhedsforanstaltninger der beskytter dem. En SaaS-fejlkonfiguration gør disse spørgsmål til presserende spørgsmål om vurdering af brud.

ISO/IEC 27001:2022 er broen. Clauses 4.1 to 4.4 kræver, at organisationen definerer kontekst, krav fra interessenter, omfang, grænseflader og afhængigheder. Clause 5 kræver lederskab, politik, roller og ansvarlighed. Clauses 6.1.1 to 6.1.3 kræver risikovurdering, risikobehandling, anvendelighedserklæring (SoA) og beslutninger om restrisiko. Clauses 8.1, 8.2 and 8.3 kræver operationel planlægning, risikovurdering og risikobehandling. Clauses 9 and 10 kræver overvågning, intern revision, ledelsens gennemgang og forbedring.

Hvis du ikke kan svare på, hvilke SaaS-værktøjer der behandler regulerede data, hvem der ejer dem, hvordan de er konfigureret, hvem der har administratoradgang, hvilke integrationer der er aktive, og hvilket bevismateriale der dokumenterer, at kontrollen virker, er din complianceposition skrøbelig.

Clarysecs SSPM-model: fortegnelse, ejerskab, baseline, bevismateriale

Clarysec behandler SaaS Security Posture Management som en gentagelig kontrolsløjfe, ikke som et engangsoprydningsprojekt.

1. Identificér alle SaaS-tjenester, herunder shadow SaaS.
2. Tildel en forretningsejer og en teknisk ejer.
3. Klassificér data, brugere, integrationer og driftsmæssig kritikalitet.
4. Anvend sikre baselinekonfigurationer.
5. Gennemgå brugere, administratorer, gæster, servicekonti og OAuth-scopes.
6. Aktivér logning, alarmering og opbevaring.
7. Overvåg offentlig deling og dataeksponering.
8. Knyt leverandører, kontrakter, databehandleraftale og exit-planlægning sammen.
9. Indsaml bevismateriale efter en defineret frekvens.
10. Før konstateringer ind i risikobehandling, ledelsens gennemgang og forbedring.

Denne model er tæt afstemt med kontrollerne i ISO/IEC 27002:2022 ISO/IEC 27002:2022, især 5.9 fortegnelse over information og andre tilknyttede aktiver, 5.15 adgangsstyring, 5.18 adgangsrettigheder, 5.19 informationssikkerhed i leverandørrelationer, 5.20 håndtering af informationssikkerhed i leverandøraftaler, 5.21 styring af informationssikkerhed i IKT-forsyningskæden, 5.23 informationssikkerhed ved brug af cloudtjenester, 8.2 privilegerede adgangsrettigheder, 8.3 begrænsning af adgang til information, 8.9 konfigurationsstyring, 8.15 logning, 8.16 overvågningsaktiviteter og 8.32 ændringsstyring.

Zenith Blueprint anfører i fasen Kontroller i praksis, trin 23 for organisatoriske kontroller:

Cloud er ikke længere en destination; det er standarden. Fra lagring til samarbejde, fra infrastruktur til maskinlæring, bygger organisationer i stigende grad på lag af tredjepartsbaserede, abstraherede og fjernadministrerede miljøer. Control 5.23 anerkender denne virkelighed og kræver, at informationssikkerhed adresseres eksplicit ved valg, brug og styring af cloudtjenester – ikke som en eftertanke, men som et designprincip fra begyndelsen.

Det er kernen i SSPM. Det handler ikke kun om at opdage fejlkonfigurationer efterfølgende. Det handler om at gøre valg, onboarding, drift, overvågning og exit for SaaS til en del af ledelsessystemet.

Den samme Zenith Blueprint-sektion forklarer virkeligheden med delt ansvar i et sprog, som ethvert bestyrelsesmedlem bør høre:

Cloududbydere sikrer infrastrukturen, men I er stadig ansvarlige for jeres data, jeres konfigurationer, jeres adgangspolitikker og jeres beredskab til hændelseshåndtering. En fejlkonfigureret storage bucket, et offentligt eksponeret dashboard eller for brede tilladelser i en cloud-IAM-opsætning er ikke cloudfejl. Det er styringssvigt.

Jeres udbyder kan drive platformen, men I ejer fortsat tenant-konfiguration, identiteter, adgangsgodkendelser, eksponerede data, integrationer, hændelsesarbejdsgange og bevismateriale for compliance.

Control 5.23 er ankeret, men SSPM kræver en kontrolfamilie

I Zenith Controls kategoriseres ISO/IEC 27002:2022 control 5.23, informationssikkerhed ved brug af cloudtjenester, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Dets cybersikkerhedskoncept er Protect med operationel kapacitet inden for sikkerhed i leverandørrelationer og domæner på tværs af governance, økosystem og beskyttelse.

Det er vigtigt, fordi SSPM ikke er én enkelt kontrol. Det er en disciplin på tværs af kontroller.

Zenith Controls kobler 5.23 til leverandørrelationer under 5.19, fordi SaaS-udbydere er kritiske leverandører, men 5.23 tilføjer SaaS-specifikke forhold såsom multi-tenancy, gennemsigtighed om datalokation og delt ansvar. Den kobler 5.23 til informationsoverførsel, fordi API’er, integrationer og arbejdsgange mellem SaaS-løsninger konstant flytter data. Den kobler 5.23 til aktivfortegnelse, fordi organisationer har brug for aktuel synlighed over cloudlagrede data og SaaS-ressourcer. Den kobler også cloudstyring til overvågning, adgangsbegrænsning, konfigurationsstyring og tilsyn med leverandører.

For adgangsrettigheder kortlægger Zenith Controls 5.18 til 5.15 adgangsstyring, 5.16 identitetsstyring, 5.3 funktionsadskillelse, 5.36 efterlevelse af politikker, regler og standarder for informationssikkerhed og 8.2 privilegerede adgangsrettigheder. For SSPM betyder det, at gennemgang af adgangsrettigheder ikke blot er en øvelse i regneark. Det er driftsmæssigt bevis på, at identitetslivscyklus, mindst privilegieprincip, funktionsadskillelse og styring af privilegeret adgang fungerer inde i SaaS-applikationer.

Politikfundament: definér det gode, før der købes værktøjer

Mange SaaS-svigt begynder, fordi politikkens ordlyd er vag. “Brug godkendte værktøjer sikkert” er ikke nok. Clarysec-politikker definerer konkrete forventninger til registre, adgang, logning, konfiguration og leverandørgennemgang.

For SMV’er giver Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV et praktisk udgangspunkt. Fra afsnittet “Styringskrav,” politikklausul 5.3:

Et register over cloudtjenester skal vedligeholdes af IT-leverandøren eller direktøren. Det skal registrere: 5.3.1 Navn og formål for hver godkendt cloudtjeneste 5.3.2 Den ansvarlige person eller det ansvarlige team (applikationsejere) 5.3.3 De typer data, der lagres eller behandles 5.3.4 Landet eller regionen, hvor data lagres 5.3.5 Brugeradgangstilladelser og administrative konti 5.3.6 Kontraktoplysninger, fornyelsesdatoer og supportkontakter

Denne klausul er den driftsmæssige kerne i SSPM. Den giver revisorer det første bevisobjekt: et register, der forbinder SaaS-brug med ejere, data, geografi, adgang og kontrakter.

Den samme Politik for brug af cloudtjenester - SMV definerer baselineindstillinger i afsnittet “Krav til implementering af politikken,” politikklausul 6.2:

Krav til sikkerhedskonfiguration 6.2.1 Følgende skal være aktiveret på alle cloudplatforme: 6.2.2 Flerfaktorautentifikation (MFA) for administrative konti og brugerkonti 6.2.3 Indstillinger for adgangskodekompleksitet (mindst 10 tegn, ingen genbrug) 6.2.4 Aktivitetslogning for loginforsøg og dataadgang 6.2.5 Adgangsbegrænsninger (f.eks. IP-tilladelsesliste, hvor det understøttes) 6.2.6 Administrativ adgang skal begrænses til navngivne personer eller godkendte supportleverandører. 6.2.7 Offentligt delt indhold skal overvåges regelmæssigt for at forhindre datalækage. 6.2.8 Når brugerkonti ikke længere er nødvendige, skal adgang tilbagekaldes straks, og eventuelle resterende data skal gennemgås og arkiveres eller slettes.

For virksomhedsmiljøer tildeler Politik for brug af cloudtjenester Politik for brug af cloudtjenester stærkere central styring. Fra afsnittet “Styringskrav,” politikklausul 5.3:

Hver cloudtjeneste skal have en tildelt serviceejer, som er ansvarlig for livscyklusstyring af informationsaktiver, styring af brug, budgetopfølgning og løbende overvågning af efterlevelse.

Den sætning lukker et almindeligt revisionshul. Hvis ingen ejer en SaaS-tjeneste, ejer ingen afvigelser fra baselinekonfigurationen, recertificering af adgang, dataeksponering, fornyelsesbeslutninger, hændelseskontakt eller exit-planlægning.

Styring af privilegier skal også være eksplicit. Politik for styring af brugerkonti og privilegier - SMV Politik for styring af brugerkonti og privilegier - SMV, fra afsnittet “Krav til implementering af politikken,” politikklausul 6.4, anfører:

Gennemgang af adgangsrettigheder og logning 6.4.1 En gennemgang af alle brugerkonti og privilegier skal udføres hver sjette måned. 6.4.2 Under gennemgange skal IT-ansvarlig validere, om hver konto fortsat er aktiv, nødvendig og tildelt de korrekte tilladelser. 6.4.3 Logfiler for oprettelse af konti, deaktivering af konti og ændringer af privilegier skal opbevares sikkert i mindst 12 måneder.

For SaaS har hver kritisk platform brug for en defineret cyklus for gennemgang af adgangsrettigheder, også når platformen administreres af et forretningsteam og ikke af central IT.

Logning skal også være eksplicit. Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV, fra afsnittet “Styringskrav,” politikklausul 5.5, anfører:

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 være aktiveret og konfigureret, hvor det er tilgængeligt 5.5.1.2 Alarmer skal dirigeres 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

Endelig skal leverandørstyring for SaaS dokumenteres. Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV, fra afsnittet “Krav til implementering af politikken,” politikklausul 6.3, anfører:

Løbende overvågning af leverandørsikkerhed 6.3.1 Kritiske eller højrisikoleverandører skal gennemgås mindst årligt. Gennemgangen skal verificere: 6.3.1.1 Fortsat brug af sikre adgangsmetoder 6.3.1.2 Gyldige sikkerhedscertificeringer eller opdateret kontrolbevismateriale 6.3.1.3 Hændelseshistorik eller rapporterede forhold 6.3.1.4 Kontraktlig overholdelse af sikkerhedsklausuler 6.3.2 Disse gennemgange skal dokumenteres og opbevares sammen med leverandørens registrering. Opfølgningshandlinger skal spores tydeligt. 6.3.3 Hvor leverandører administrerer IT-infrastruktur eller applikationer, kan overvågning omfatte: 6.3.3.1 Anmodning om revisionslogs 6.3.3.2 Gennemgang af kontoaktivitet 6.3.3.3 Bekræftelse af, at der ikke er sket uautoriseret adgang

Tilsammen omsætter disse politikker SSPM fra en sikkerhedsambition til en håndhævelig driftsmodel.

Et 30-dages sprint for SSPM-bevismateriale

En praktisk CISO eller complianceansvarlig kan begynde med et 30-dages evidenssprint. Vælg de fem SaaS-platforme, der er vigtigst for regulerede data eller kritiske driftsaktiviteter. Typiske kandidater er Microsoft 365 eller Google Workspace, CRM, ticketing, HRIS, økonomiautomatisering, kundesupport og analyse.

Uge 1: Opret SaaS-registeret

Brug felterne i Politik for brug af cloudtjenester - SMV clause 5.3 som minimumsregister. Registrér for hver SaaS-tjeneste:

• Tjenestenavn og forretningsformål
• Applikationsejer og teknisk ejer
• Datatyper, herunder personoplysninger og særlige kategorier af data, hvor det er relevant
• Land eller region for datalagring
• Brugergrupper og administratorkonti
• OAuth-apps og tredjepartsintegrationer
• Kontraktejer, fornyelsesdato og supportkontakt
• Kritikalitet for driften
• Relevante forpligtelser, såsom NIS2, DORA, GDPR eller kundekontrakter

Dette understøtter ISO/IEC 27001:2022 clauses 4.2 og 4.3, fordi regulatoriske, kontraktlige og tredjepartsafhængigheder skal forme ISMS-omfanget. Det understøtter også identifikation og klassificering af IKT-understøttede forretningsfunktioner, informationsaktiver, IKT-aktiver og afhængigheder i tråd med DORA Article 8.

Uge 2: Definér sikre baselinekonfigurationer

Definér 10 til 15 baselinekontroller for hver udvalgt SaaS-platform.

• MFA håndhæves for alle brugere, med phishing-resistent MFA for administratorer, hvor det er muligt
• Ekstern deling deaktiveres som standard eller begrænses til godkendte domæner
• Offentlige links deaktiveres eller tidsbegrænses
• Gæstekonti gennemgås månedligt
• Administratorroller tildeles navngivne personer
• Legacy-autentifikation deaktiveres
• Godkendelsesarbejdsgang for OAuth-apps aktiveres
• Højrisiko-OAuth-scopes blokeres eller kræver sikkerhedsgodkendelse
• Revisionslogning aktiveres
• Tilladelser til dataeksport begrænses
• Opbevaringsindstillinger afstemmes med retlige og forretningsmæssige krav
• API-tokens gennemgås og roteres
• Sikkerhedsalarmer dirigeres til IT eller SOC
• Indstillinger for datatabsforebyggelse aktiveres, hvor det understøttes
• “break glass”-administratorkonti dokumenteres og overvåges

Zenith Blueprint, fasen Kontroller i praksis, trin 19, control 8.9 konfigurationsstyring, forklarer, hvorfor dette er vigtigt:

Mange brud skyldes ikke softwarefejl; de skyldes dårlige konfigurationsvalg. Standardadgangskoder, der ikke ændres, usikre tjenester, der er aktiveret, unødvendige porte, der er åbne, eller systemer, der eksponeres mod internettet uden begrundelse. Control 8.9 sikrer, at hvert system bygges efter en sikker baselinekonfiguration og gennemgås regelmæssigt for at forhindre drift over tid.

For SaaS omfatter afvigelser fra baselinekonfigurationen, at en forretningsejer aktiverer offentlig deling, at en administrator godkender bred tredjepartsadgang, eller at en leverandør ændrer standardindstillinger efter en release.

Uge 3: Gennemgå adgang og integrationer

Eksportér brugere, grupper, administratorer og tilknyttede applikationer. Bekræft for hver administratorkonto den navngivne person, forretningsmæssig begrundelse, MFA-status, seneste login, privilegieniveau, backupdækning, eventuelle funktionsadskillelsesforhold og godkendelsesbevismateriale.

For OAuth-apps og integrationer skal app-ejer, tilgåede data, anmodede tilladelser, leverandørrisikostatus, seneste anvendelsesdato, fortsat behov og om samtykke er givet af bruger eller godkendt af administrator bekræftes.

Zenith Blueprint, fasen Kontroller i praksis, trin 19, control 8.3 begrænsning af adgang til information, angiver det operationelle princip:

Adgang til information bør være så åben som nødvendigt, men så begrænset som muligt.

Dette gælder ikke kun personer, men også applikationer, tjenester og API’er. En inaktiv OAuth-integration kan bevare adgang længe efter, at den medarbejder eller det projekt, der oprettede den, er forsvundet.

Uge 4: Udarbejd revisionsklart bevismateriale og risikobehandling

For hver SaaS-platform skal registerposten, baselinekonfigurationen, screenshots eller eksporter, der dokumenterer nøgleindstillinger, godkendelse af adgangsgennemgang, bevismateriale for administratorgennemgang, bevismateriale for OAuth-gennemgang, bevismateriale for logning og alarmering, registrering af leverandørsikkerhedsgennemgang, åbne konstateringer og risikobehandlingshandlinger opbevares.

Udarbejd derefter et ledelsesresumé på én side, der viser kritiske konstateringer, forfaldne ejere, uløste konfigurationshuller med høj risiko, ikke-godkendte integrationer, logningshuller, undtagelser og nødvendige beslutninger. Dette understøtter ISO/IEC 27001:2022 clause 9.1 overvågning, clause 9.2 intern revision og clause 9.3 ledelsens gennemgang. Det skaber også en praktisk bro til ledelsesansvar efter NIS2 Article 20 og DORA-tilsyn fra ledelsesorganet.

Kortlægning på tværs af efterlevelseskrav: én SSPM-evidenspakke, mange forpligtelser

Forretningsværdien af SSPM er ikke kun bedre sikkerhed. Det er også mindre dobbeltarbejde i compliance.

NIS2 Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger. SaaS-fortegnelse understøtter politik for aktivstyring. Baselinekonfigurationer understøtter cyberhygiejne. MFA og gennemgang af adgangsrettigheder understøtter adgangsstyring. Logning understøtter hændelseshåndtering. Leverandørgennemgang understøtter sikkerhed i forsyningskæden. Frekvens for bevismateriale understøtter politikker og procedurer til vurdering af effektivitet.

DORA kræver, at finansielle enheder identificerer og klassificerer IKT-understøttede funktioner, informationsaktiver, IKT-aktiver og tredjepartsafhængigheder. DORA kræver også beskyttelses- og forebyggelsesforanstaltninger, adgangskontroller, stærk autentifikation, kryptering, kontinuitet, test, hændelsesstyring og styring af IKT-tredjepartsrisiko. En SSPM-evidenspakke for SaaS kan understøtte DORA-registre, kortlægning af afhængigheder, kontrakttilsyn, revisionsrettigheder og exit-planlægning.

GDPR kræver, at dataansvarlige kan dokumentere overholdelse af integritet, fortrolighed og ansvarlighed. SaaS-registre identificerer, hvor personoplysninger behandles. Baselinekonfigurationer reducerer uautoriseret videregivelse. Gennemgang af adgangsrettigheder understøtter mindst privilegieprincip. Logning understøtter undersøgelse af brud. Leverandørregistreringer understøtter databehandlerstyring og ansvarlighed.

NIST CSF 2.0 tilføjer et nyttigt kommunikationslag. GOVERN-funktionen kræver, at juridiske, regulatoriske og kontraktlige cybersikkerhedskrav forstås og styres. Dens resultater for forsyningskæden kræver leverandørroller, kontrakter, due diligence, overvågning og aktiviteter efter ophør af relationen. Funktionerne IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER kortlægges naturligt til SaaS-fortegnelse, adgangsstyring, databeskyttelse, logning, hændelseshåndtering og genopretning.

COBIT 2019- og ISACA-orienterede revisorer vil normalt tilgå SSPM gennem governance, ledelsesmål, risikoejerskab, kontroludførelse og assurance. De vil spørge, om SaaS-beslutninger er afstemt med virksomhedens mål, om risikoresponser er dokumenteret, om ansvar er tildelt, og om assurance-aktiviteter dokumenterer, at kontrollerne fungerer.

Revisionsperspektivet: hvordan forskellige revisorer tester SaaS-sikkerhedstilstanden

Et stærkt SSPM-program kan modstå forskellige revisionsstile, fordi det producerer bevismateriale på det rette niveau.

En ISO/IEC 27001:2022-revisor vil starte med omfang, interessenter, risikovurdering, anvendelighedserklæring (SoA) og driftsmæssigt bevismateriale. Hvis control 5.23 er inkluderet, forventes bevismateriale for valg, brug, styring og exit af cloudtjenester. Hvis kontroller for adgangsrettigheder er inkluderet, vil revisoren udtage brugere i stikprøve og spørge, om ændringer ved tiltrædelser, omplaceringer og fratrædelser er afspejlet i SaaS-tilladelser.

En DORA-gennemgang vil fokusere på kritiske eller vigtige funktioner, IKT-tredjepartsafhængighed, registerets fuldstændighed, kontrakter, hændelsesklassificering, test og exit-planlægning. Hvis en SaaS-platform understøtter betalingsaktiviteter, kundeonboarding, handel, risikoanalyse eller kundekommunikation, stiger kravet til bevismateriale.

En GDPR-revisor eller privatlivsgennemgang vil spørge, hvor personoplysninger lagres, hvem der kan tilgå dem, hvilke eksport- og delingsindstillinger der findes, om databehandlere styres, om logfiler understøtter vurdering af brud, og om kontroller står i rimeligt forhold til risikoen.

Leverandørrisiko, delt ansvar og hændelsesberedskab

SSPM starter ofte med konfiguration, men kan ikke stoppe der. SaaS er også et spørgsmål om leverandørrisiko og hændelsesberedskab.

DORA kræver, at finansielle enheder fører registre over IKT-servicekontrakter, skelner mellem aftaler, der understøtter kritiske eller vigtige funktioner, vurderer koncentrationsrisiko, evaluerer udbyderes egnethed og opretholder exit-strategier. Kontrakter bør adressere servicebeskrivelser, datalokation, beskyttelse af tilgængelighed, autenticitet, integritet og fortrolighed, dataadgang, genopretning og tilbagelevering, hændelsesassistance, samarbejde med myndigheder, opsigelsesrettigheder, sikkerhedskrav, revisionsrettigheder og overgangsstøtte.

NIS2 Article 21 omfatter også sikkerhed i forsyningskæden og kræver, at enheder tager højde for sårbarheder, der er specifikke for direkte leverandører og tjenesteudbydere, produkternes kvalitet og leverandørers cybersikkerhedspraksis.

I praksis bør en gennemgang af kritisk SaaS kombinere bevismateriale fra sikkerhedsspørgeskemaer, kontraktgennemgang, status for databehandleraftale, hændelseshistorik, serviceniveauforpligtelser, adgang til logfiler, revisionsrapporter, konfigurationsbevismateriale og gennemførlighed af exit.

Hullet i delt ansvar opstår, når teams antager, at leverandørens certificering dækker tenant-konfigurationen. Det gør den ikke. En leverandør kan drive en sikker platform, mens kunden aktiverer offentlig deling, lader inaktive administratorkonti være aktive eller tildeler for brede API-scopes. SSPM lukker det hul.

Hændelsesberedskab er lige så vigtigt. NIS2-rapportering af væsentlige hændelser omfatter en tidlig varsling inden for 24 timer, en underretning inden for 72 timer og en endelig rapport senest én måned efter 72-timersunderretningen. DORA kræver håndtering af IKT-relaterede hændelser med detektion, registrering, klassificering, eskalering, kommunikation og underretning. GDPR-vurdering af brud på persondatasikkerheden afhænger også af rettidig forståelse af, hvad der skete, hvilke data der var berørt, og hvem der blev påvirket.

Hvis en mistænkelig OAuth-app har tilgået kundefiler, skal du vide, hvornår appen blev godkendt, hvilken bruger der godkendte den, hvilke scopes der blev tildelt, hvilke data der blev tilgået, om data blev downloadet eller delt, hvilke brugere eller kunder der blev berørt, om adgangen fortsat er aktiv, og hvilke inddæmningshandlinger der blev udført.

Uden logning og opbevaring kan organisationen blive tvunget til at lægge worst case-antagelser til grund. Det øger den juridiske eksponering, presset på kundekommunikation og den regulatoriske usikkerhed. Hvis en SaaS-udbyder opkræver ekstra betaling for revisionslogs, bør risikoejeren eksplicit acceptere restrisikoen eller godkende det nødvendige licensniveau. Den beslutning hører hjemme i registreringen for risikobehandling og i ledelsens gennemgang.

Almindelige SSPM-fejlmønstre

De samme fejlmønstre går igen på tværs af sektorer.

For det første opdages shadow SaaS gennem fakturaer, browserhistorik eller SSO-logfiler i stedet for gennem indkøb. Løsningen er ikke kun at blokere værktøjer. Det er en enkel intake-proces, som forretningsteams kan bruge.

For det andet er SaaS-ejerskab uklart. CRM er “ejet af Salg,” men ingen i Salg kan forklare administratorroller, API-tokens, dataeksporter eller opbevaringsindstillinger. Tildel applikationsejere og tekniske ejere separat.

For det tredje er gennemgang af adgangsrettigheder for generisk. En gennemgangsansvarlig godkender “alle brugere godkendt” uden at kontrollere højrisikoroller, inaktive brugere, gæster, eksterne samarbejdspartnere eller servicekonti. SSPM-adgangsgennemgang skal risikoprioriteres.

For det fjerde ignoreres OAuth-apps. Mange organisationer gennemgår menneskelige brugere, men ikke app-til-app-tilladelser. I moderne SaaS kan integrationer være mere magtfulde end brugere.

For det femte findes baselinekonfigurationer kun som screenshots fra certificeringsprojektet. De overvåges ikke for drift. Afstem SSPM med konfigurationsstyring, så baselinekontroller bliver tilbagevendende bevismateriale.

For det sjette er leverandørgennemgang og gennemgang af SaaS-sikkerhedstilstand adskilt. Indkøb har kontrakten, IT har administratorkonsollen, Privacy har databehandleraftalen, og Security har risikoregisteret. Revisoren ser fragmenter. SSPM samler dem.

Ledelsesrapportering: gør SaaS-risiko synlig for bestyrelsen

NIS2 og DORA gør begge IKT- og cybersikkerhedsstyring til et ledelsesanliggende. ISO/IEC 27001:2022 kræver også lederskab, ressourcer, rolletildeling, overvågning og ledelsens gennemgang.

En effektiv SSPM-ledelsesrapport bør besvare:

• Hvilke kritiske SaaS-tjenester er omfattet?
• Hvilke regulerede processer afhænger af dem?
• Hvilke indeholder personoplysninger eller følsomme forretningsdata?
• Hvilke har forfaldne adgangsgennemgange?
• Hvilke har uløste konfigurationshuller med høj risiko?
• Hvilke har ikke-godkendte OAuth-apps eller integrationer?
• Hvilke leverandører mangler aktuelt sikkerhedsbevismateriale?
• Hvilke logningshuller påvirker hændelsesrapportering?
• Hvilke undtagelser kræver risikoaccept?
• Hvilke investeringer eller beslutninger er nødvendige?

Dette omsætter SSPM fra et teknisk oprydningsprojekt til et styringsinput. Det gør også CISO’en mere effektiv, fordi risikoaccept flyttes til det rette niveau.

Omsæt SaaS-sikkerhedstilstand til revisionsklart bevismateriale

Hvis din organisation anvender SaaS til regulerede data, finansielle aktiviteter, kundesupport, HR, samarbejde, engineering eller analyse, er SSPM ikke længere valgfrit. Det er en del af cyberhygiejne, IKT-risikostyring, ansvarlighed for databeskyttelse og revisionsberedskab.

Clarysec kan hjælpe jer med at gå fra spredte SaaS-konstateringer til et struktureret, evidensdrevet program ved at bruge:

• Zenith Blueprint: en revisors 30-trins køreplan Zenith Blueprint til at strukturere implementering på tværs af cloudbrug, adgangsbegrænsning og konfigurationsstyring.
• Zenith Controls: vejledning på tværs af efterlevelseskrav Zenith Controls til at kortlægge ISO/IEC 27002:2022-kontroller til NIS2, DORA, GDPR, NIST CSF 2.0 og revisionsforventninger.
• Clarysec-politikskabeloner såsom Politik for brug af cloudtjenester Politik for brug af cloudtjenester, Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV, Politik for styring af brugerkonti og privilegier - SMV Politik for styring af brugerkonti og privilegier - SMV, Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV og Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV til at skabe håndhævelige driftsregler.

Start med jeres fem SaaS-platforme med højest risiko. Tildel ejere. Registrér data, adgang, konfiguration, integrationer, logfiler og leverandørbevismateriale. Omsæt konstateringer til risikobehandlingshandlinger og ledelsesbeslutninger.

Sådan bliver SaaS Security Posture Management mere end en værktøjskategori. Det bliver en forsvarlig compliancedisciplin for 2026.

Download Clarysec-politikskabelonerne, brug Zenith Blueprint til at planlægge jeres 30-dages sprint for SSPM-bevismateriale, og kortlæg jeres SaaS-kontroller med Zenith Controls, før jeres næste revision finder hullerne for jer.