SaaS Security Posture Management inför revisioner 2026

SaaS-iakttagelsen i revisionen som ingen ägde

Klockan 08:15 en tisdag får informationssäkerhetschefen på ett snabbväxande fintechbolag ett meddelande från dataskyddsombudet: ”Varför kan en kundexport delas publikt från ett samarbetsverktyg, och vem godkände OAuth-appen som kan läsa den?”

Klockan 09:00 bekräftar ekonomiavdelningen att verktyget betalas med ett avdelningskort, inte via central upphandling. Klockan 10:30 upptäcker IT att användaren som skapade den publika länken lämnade organisationen för tre månader sedan. Vid lunch frågar juridikfunktionen om detta är en personuppgiftsincident enligt GDPR. Klockan 14:00 frågar riskkommittén om frågan påverkar NIS2-cyberhygien och DORA IKT-tredjepartsrisk. Klockan 16:00 begär internrevisorn säkra baslinjer, åtkomstgranskningar för administratörer, ägarskap för molntjänster, loggar och leverantörsgranskningar.

Den smärtsamma sanningen är att organisationen inte drabbades av ett klassiskt SaaS-avbrott eller ett leverantörsfel. Den drabbades av ett styrningsfel.

Scenariot är inte längre ovanligt. Ett marknadsteam kopplar en AI-plattform till ett CRM med breda OAuth-behörigheter. HR köper ett nischat analysverktyg utanför upphandlingsprocessen. Ett kundsupportteam aktiverar publika ärendeexporter av bekvämlighetsskäl. Utvecklingsteamet integrerar ett webbläsartillägg i ett utvecklingsflöde. Varje beslut kan verka litet, men tillsammans skapar de en distribuerad kontrollyta fylld med reglerade data, privilegierade arbetsflöden och operativa beroenden.

SaaS Security Posture Management, eller SSPM, är disciplinen som omvandlar denna utspridda SaaS-verklighet till styrd, testad och granskningsbar kontroll. Rätt genomfört ger den informationssäkerhetschefer, regelefterlevnadsansvariga, revisorer och verksamhetsägare ett gemensamt revisionsspår för ISO/IEC 27001:2022, NIS2-cyberhygien, DORA IKT-risk och ansvarsskyldighet för säkerhet enligt GDPR.

Clarysecs ståndpunkt är tydlig: SSPM ska inte behandlas som ännu en instrumentpanel. Det ska byggas in i ISMS, kopplas till riskägarskap, mappas mot rättsliga skyldigheter, stödjas av policy och testas genom återkommande underlag.

Det är här Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls och Clarysecs policymallar blir praktiskt användbara. De hjälper till att omvandla SaaS-sprawl till en kontrollmodell som en revisor kan förstå och som ett ledningsorgan kan utöva tillsyn över.

Varför SaaS Security Posture Management blev en fråga om regelefterlevnad

SaaS brukade behandlas som ”programvara som någon annan driver”. Den synen är inte längre försvarbar.

Enligt NIS2 kan många leverantörer av molntjänster, SaaS, digital infrastruktur, hanterade tjänster och hanterade säkerhetstjänster omfattas av reglerade cybersäkerhetskrav beroende på sektor, storlek, roll och kritikalitet. Ännu viktigare är att organisationer som förlitar sig på SaaS måste styra det som en del av sina egna riskhanteringsåtgärder. NIS2 Article 20 gör ledningsorgan ansvariga för att godkänna riskhanteringsåtgärder för cybersäkerhet, övervaka genomförandet och genomgå utbildning. Article 21 kräver praktiska tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, policyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och säkert underhåll, effektivitetsprovning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och flerfaktorsautentisering där det är lämpligt.

DORA höjer ribban ytterligare för finansiella entiteter. Sedan den 17 januari 2025 gäller DORA för många organisationer i finanssektorn som regelverk för operativ resiliens för entiteter inom tillämpningsområdet. DORA kräver IKT-styrning, identifiering och klassificering av IKT-tillgångar och stödda funktioner, skydds- och förebyggande kontroller, incidenthantering, kontinuitet, testning och hantering av IKT-tredjepartsrisk. SaaS-leverantörer som stödjer kritiska eller viktiga funktioner blir en del av DORA:s bevisperimeter, samtidigt som den reglerade finansiella entiteten förblir ansvarig.

GDPR tillför ett lager av integritetsunderlag. Article 5 kräver korrekthet, konfidentialitet och ansvarsskyldighet. Article 32 kräver lämplig säkerhet vid behandling. I praktiken måste en organisation veta vilka personuppgifter som finns, var de behandlas, vem som kan få åtkomst till dem, vilka leverantörer som behandlar dem och vilka skyddsåtgärder som skyddar dem. En SaaS-felkonfiguration omvandlar dessa frågor till akuta frågor om incidentbedömning.

ISO/IEC 27001:2022 är bryggan. Avsnitt 4.1 till 4.4 kräver att organisationen definierar kontext, intressentkrav, omfattning, gränssnitt och beroenden. Avsnitt 5 kräver ledarskap, policy, roller och ansvar. Avsnitt 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling, tillämpbarhetsförklaring och beslut om kvarstående risk. Avsnitt 8.1, 8.2 och 8.3 kräver operativ planering, riskbedömning och riskbehandling. Avsnitt 9 och 10 kräver övervakning, internrevision, ledningens genomgång och förbättring.

Om ni inte kan svara på vilka SaaS-verktyg som behandlar reglerade data, vem som äger dem, hur de är konfigurerade, vem som har administratörsåtkomst, vilka integrationer som är aktiva och vilket underlag som visar att kontrollerna fungerar, är er efterlevnadsposition skör.

Clarysecs SSPM-modell: register, ägarskap, baslinje, underlag

Clarysec behandlar SaaS Security Posture Management som en återkommande kontrollslinga, inte som ett engångsprojekt för uppstädning.

1. Upptäck varje SaaS-tjänst, inklusive skugg-SaaS.
2. Tilldela en verksamhetsägare och en teknisk ägare.
3. Klassificera data, användare, integrationer och operativ kritikalitet.
4. Tillämpa säkra baslinjekonfigurationer.
5. Granska användare, administratörer, gäster, tjänstekonton och OAuth-behörigheter.
6. Aktivera loggning, larmning och loggbevarande.
7. Övervaka publik delning och dataexponering.
8. Koppla leverantörer, avtal, personuppgiftsbiträdesavtal och exit-planering.
9. Samla in underlag enligt en definierad periodicitet.
10. För in iakttagelser i riskbehandling, ledningens genomgång och förbättringsarbete.

Denna modell är nära anpassad till kontrollerna i ISO/IEC 27002:2022 ISO/IEC 27002:2022, särskilt 5.9 förteckning över information och andra tillhörande tillgångar, 5.15 åtkomstkontroll, 5.18 åtkomsträttigheter, 5.19 informationssäkerhet i leverantörsrelationer, 5.20 hantering av informationssäkerhet i leverantörsavtal, 5.21 hantering av informationssäkerhet i IKT-leveranskedjan, 5.23 informationssäkerhet vid användning av molntjänster, 8.2 privilegierade åtkomsträttigheter, 8.3 begränsning av informationsåtkomst, 8.9 konfigurationshantering, 8.15 loggning, 8.16 övervakningsaktiviteter och 8.32 ändringshantering.

Zenith Blueprint, i fasen Controls in Action, Step 23 för organisatoriska kontroller, anger:

Molnet är inte längre en destination, det är standardläget. Från lagring till samarbete, från infrastruktur till maskininlärning byggs organisationer i allt högre grad på lager av tredjepartsmiljöer som är abstraherade och fjärrhanterade. Control 5.23 erkänner denna verklighet och kräver att informationssäkerhet uttryckligen hanteras vid val, användning och hantering av molntjänster, inte som en eftertanke, utan som en designprincip från början.

Detta är kärnan i SSPM. Det handlar inte bara om att upptäcka felkonfigurationer i efterhand. Det handlar om att göra val, införande, drift, övervakning och avveckling av SaaS till en del av ledningssystemet.

Samma avsnitt i Zenith Blueprint förklarar delat ansvar på ett språk som varje styrelseledamot bör höra:

Molnleverantörer säkrar infrastrukturen, men ni är fortfarande ansvariga för era data, era konfigurationer, era åtkomstpolicyer och er incidentberedskap. En felkonfigurerad lagringsbucket, en publikt exponerad kontrollpanel eller för långtgående behörigheter i en molnbaserad IAM-konfiguration är inte molnfel. De är styrningsfel.

Er leverantör kan driva plattformen, men ni äger fortfarande tenant-konfiguration, identiteter, åtkomstgodkännanden, exponerade data, integrationer, incidentarbetsflöden och underlag för efterlevnad.

Kontroll 5.23 är ankaret, men SSPM kräver en kontrollfamilj

I Zenith Controls kategoriseras ISO/IEC 27002:2022 kontroll 5.23, informationssäkerhet vid användning av molntjänster, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Dess cybersäkerhetskoncept är Protect, med operativ förmåga inom säkerhet i leverantörsrelationer och domänerna styrning, ekosystem och skydd.

Det är viktigt eftersom SSPM inte är en enskild kontroll. Det är en disciplin som spänner över flera kontroller.

Zenith Controls kopplar 5.23 till leverantörsrelationer enligt 5.19 eftersom SaaS-leverantörer är kritiska leverantörer, men 5.23 tillför SaaS-specifika frågor som multitenancy, transparens om datalagringsplats och delat ansvar. Den kopplar 5.23 till informationsöverföring eftersom API:er, integrationer och arbetsflöden mellan SaaS-tjänster flyttar data kontinuerligt. Den kopplar 5.23 till tillgångsförteckning eftersom organisationer behöver aktuell insyn i data som lagras i molntjänster och SaaS-resurser. Den kopplar även molnstyrning till övervakning, åtkomstbegränsning, konfigurationshantering och leverantörstillsyn.

För åtkomsträttigheter mappar Zenith Controls 5.18 till 5.15 åtkomstkontroll, 5.16 identitetshantering, 5.3 funktionsuppdelning, 5.36 efterlevnad av policyer, regler och standarder för informationssäkerhet samt 8.2 privilegierade åtkomsträttigheter. För SSPM innebär detta att åtkomstgranskning inte bara är en kalkylbladsövning. Det är operativt bevis på att identitetslivscykel, principen om minsta privilegium, funktionsuppdelning och styrning av privilegierad åtkomst fungerar i SaaS-applikationer.

Policygrund: definiera god praxis innan verktyg köps

Många SaaS-brister börjar med otydligt policyspråk. ”Använd godkända verktyg säkert” räcker inte. Clarysecs policyer definierar specifika krav på register, åtkomst, loggning, konfiguration och leverantörsgranskning.

För små och medelstora företag ger Policy för användning av molntjänster-sme Policy för användning av molntjänster - SME en praktisk startpunkt. Från avsnittet ”Styrningskrav”, policyklausul 5.3:

Ett register över molntjänster ska upprätthållas av IT-leverantören eller GM. Det ska registrera: 5.3.1 Namn och syfte för varje godkänd molntjänst 5.3.2 Ansvarig person eller ansvarigt team (applikationsägare) 5.3.3 Typer av data som lagras eller behandlas 5.3.4 Land eller region där data lagras 5.3.5 Användarnas åtkomstbehörigheter och administrativa konton 5.3.6 Avtalsuppgifter, förnyelsedatum och supportkontakter

Denna klausul är den operativa kärnan i SSPM. Den ger revisorer det första bevisobjektet: ett register som kopplar SaaS-användning till ägare, data, geografi, åtkomst och avtal.

Samma Policy för användning av molntjänster-sme, från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2, definierar baslinjeinställningar:

Krav på säkerhetskonfiguration 6.2.1 Följande ska vara aktiverat på alla molnplattformar: 6.2.2 Flerfaktorsautentisering (MFA) för administrativa konton och användarkonton 6.2.3 Inställningar för lösenordskomplexitet (minst 10 tecken, ingen återanvändning) 6.2.4 Aktivitetsloggning för inloggningsförsök och dataåtkomst 6.2.5 Åtkomstbegränsningar (t.ex. IP-tillåtelselista, där det stöds) 6.2.6 Administrativ åtkomst ska begränsas till namngivna personer eller behöriga supportleverantörer. 6.2.7 Publikt delat innehåll ska övervakas regelbundet för att förhindra dataläckage. 6.2.8 När användarkonton inte längre krävs ska åtkomst återkallas omedelbart och eventuella kvarvarande data granskas och arkiveras eller raderas.

För företagsmiljöer tilldelar Policy för användning av molntjänster Policy för användning av molntjänster starkare centraliserad styrning. Från avsnittet ”Styrningskrav”, policyklausul 5.3:

Varje molntjänst ska ha en tilldelad tjänsteägare som ansvarar för hantering av informationstillgångars livscykel, användningsstyrning, budgetuppföljning och löpande övervakning av efterlevnad.

Den meningen stänger en vanlig revisionslucka. Om ingen äger en SaaS-tjänst äger ingen konfigurationsdrift, åtkomstomcertifiering, dataexponering, förnyelsebeslut, incidentkontakt eller exit-planering.

Privilegiestyrning måste också vara uttrycklig. Policy för hantering av användarkonton och privilegier-sme Policy för hantering av användarkonton och privilegier - SME, från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.4, anger:

Åtkomstgranskning och loggning 6.4.1 En granskning av alla användarkonton och privilegier ska utföras var sjätte månad. 6.4.2 Vid granskningar ska IT-ansvarig validera om varje konto fortfarande är aktivt, nödvändigt och tilldelat korrekta behörigheter. 6.4.3 Loggar över kontoskapande, kontoavaktivering och privilegieändringar ska bevaras säkert i minst 12 månader.

För SaaS behöver varje kritisk plattform en definierad cykel för åtkomstgranskning, även om plattformen administreras av ett verksamhetsteam snarare än av central IT.

Loggning måste också vara uttrycklig. Loggnings- och övervakningspolicy-sme Loggnings- och övervakningspolicy - SME, från avsnittet ”Styrningskrav”, policyklausul 5.5, anger:

Molntjänster och tredjepartsloggning 5.5.1 För plattformar där loggning inte står under direkt IT-kontroll (t.ex. SaaS-e-post) gäller följande krav: 5.5.1.1 Loggning ska aktiveras och konfigureras där det är tillgängligt 5.5.1.2 Larm ska dirigeras till IT-supportleverantören 5.5.1.3 Avtal ska kräva att leverantörer bevarar loggar i minst 12 månader och tillhandahåller åtkomst på begäran

Slutligen måste SaaS-leverantörsstyrning dokumenteras. Policy för leverantörssäkerhet och tredjepartssäkerhet-sme Policy för leverantörssäkerhet och tredjepartssäkerhet - SME, från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3, anger:

Löpande övervakning av leverantörssäkerhet 6.3.1 Kritiska eller högriskleverantörer ska granskas minst årligen. Granskningen ska verifiera: 6.3.1.1 Fortsatt användning av säkra åtkomstmetoder 6.3.1.2 Giltiga säkerhetscertifieringar eller uppdaterat kontrollunderlag 6.3.1.3 Incidenthistorik eller rapporterade problem 6.3.1.4 Avtalsenlig efterlevnad av säkerhetsklausuler 6.3.2 Dessa granskningar ska dokumenteras och bevaras tillsammans med leverantörens uppgifter. Uppföljningsåtgärder ska följas upp tydligt. 6.3.3 Där leverantörer hanterar IT-infrastruktur eller applikationer kan övervakning omfatta: 6.3.3.1 Begäran om revisionsloggar 6.3.3.2 Granskning av kontoaktivitet 6.3.3.3 Bekräftelse av att ingen obehörig åtkomst har inträffat

Tillsammans omvandlar dessa policyer SSPM från en säkerhetsambition till en tillämpbar operativ modell.

En 30-dagars SSPM-sprint för underlag

En praktiskt inriktad informationssäkerhetschef eller regelefterlevnadsansvarig kan börja med en 30-dagars sprint för underlag. Välj de fem SaaS-plattformar som är viktigast för reglerade data eller kritisk drift. Typiska kandidater är Microsoft 365 eller Google Workspace, CRM, ärendehantering, HRIS, finansautomatisering, kundsupport och analys.

Vecka 1: Skapa SaaS-registret

Använd fälten i Policy för användning av molntjänster-sme klausul 5.3 som minimiregister. För varje SaaS-tjänst ska följande registreras:

• Tjänstens namn och verksamhetssyfte
• Applikationsägare och teknisk ägare
• Datatyper, inklusive personuppgifter och särskilda kategorier av personuppgifter där det är tillämpligt
• Land eller region för datalagring
• Användargrupper och administratörskonton
• OAuth-appar och tredjepartsintegrationer
• Avtalsägare, förnyelsedatum och supportkontakt
• Operativ kritikalitet
• Tillämpliga skyldigheter, såsom NIS2, DORA, GDPR eller kundavtal

Detta stödjer ISO/IEC 27001:2022 avsnitt 4.2 och 4.3 eftersom regulatoriska, avtalsmässiga och tredjepartsrelaterade beroenden måste forma ISMS-omfattningen. Det stödjer även DORA Article 8-liknande identifiering och klassificering av IKT-stödda verksamhetsfunktioner, informationstillgångar, IKT-tillgångar och beroenden.

Vecka 2: Definiera säkra baslinjekonfigurationer

För varje vald SaaS-plattform definieras 10 till 15 baslinjekontroller.

• MFA genomdrivs för alla användare, med phishingresistent MFA för administratörer där det är möjligt
• Extern delning är inaktiverad som standard eller begränsad till godkända domäner
• Publika länkar är inaktiverade eller tidsbegränsade
• Gästkonton granskas månadsvis
• Administratörsroller tilldelas namngivna personer
• Äldre autentisering är inaktiverad
• Arbetsflöde för godkännande av OAuth-appar är aktiverat
• OAuth-behörigheter med hög risk blockeras eller kräver säkerhetsgodkännande
• Revisionsloggning är aktiverad
• Behörigheter för dataexport är begränsade
• Bevarandeinställningar är anpassade till rättsliga krav och verksamhetskrav
• API-token granskas och roteras
• Säkerhetslarm dirigeras till IT eller SOC
• Inställningar för dataförlustskydd (DLP) är aktiverade där det stöds
• Nödkonton för break-glass är dokumenterade och övervakade

Zenith Blueprint, fasen Controls in Action, Step 19, kontroll 8.9 konfigurationshantering, förklarar varför detta är viktigt:

Många incidenter beror inte på programvarubrister, utan på dåliga konfigurationsval. Standardlösenord som inte ändras, osäkra tjänster som är aktiverade, onödiga portar som är öppna eller system som exponeras mot internet utan motivering. Control 8.9 säkerställer att varje system byggs mot en säker baslinjekonfiguration och granskas regelbundet för att förhindra drift över tid.

För SaaS omfattar konfigurationsdrift att en verksamhetsägare aktiverar publik delning, att en administratör godkänner bred tredjepartsåtkomst eller att en leverantör ändrar standardinställningar efter ett funktionssläpp.

Vecka 3: Granska åtkomst och integrationer

Exportera användare, grupper, administratörer och anslutna applikationer. För varje administratörskonto ska namngiven person, verksamhetsmässig motivering, MFA-status, senaste inloggning, behörighetsnivå, ersättare eller reservrutin, eventuella frågor om funktionsuppdelning och godkännandeunderlag bekräftas.

För OAuth-appar och integrationer ska appägare, åtkomna data, begärda behörigheter, leverantörsriskstatus, datum för senaste användning, fortsatt behov och om samtycket lämnades av användare eller godkändes av administratör bekräftas.

Zenith Blueprint, fasen Controls in Action, Step 19, kontroll 8.3 begränsning av informationsåtkomst, anger den operativa principen:

Åtkomst till information ska vara så öppen som nödvändigt, men så begränsad som möjligt.

Detta gäller inte bara personer, utan även applikationer, tjänster och API:er. En inaktiv OAuth-integration kan behålla åtkomst långt efter att den anställda eller det projekt som skapade den har försvunnit.

Vecka 4: Ta fram revisionsklart underlag och riskbehandling

För varje SaaS-plattform ska registerposten, baslinjekonfigurationen, skärmdumpar eller exporter som visar nyckelinställningar, godkännande från åtkomstgranskning, underlag från administratörsgranskning, underlag från OAuth-granskning, underlag för loggning och larmning, leverantörssäkerhetsgranskning, öppna iakttagelser och riskbehandlingsåtgärder sparas.

Skapa därefter en ensidig ledningssammanfattning som visar kritiska iakttagelser, försenade ägare, olösta högriskluckor i konfiguration, icke godkända integrationer, loggningsluckor, undantag och beslut som krävs. Detta stödjer ISO/IEC 27001:2022 avsnitt 9.1 övervakning, avsnitt 9.2 internrevision och avsnitt 9.3 ledningens genomgång. Det skapar också en praktisk brygga till ledningens ansvarsskyldighet enligt NIS2 Article 20 och DORA:s tillsyn på ledningsorgansnivå.

Korsvis efterlevnadsmappning: ett SSPM-underlagspaket, många skyldigheter

Verksamhetsnyttan med SSPM är inte bara bättre säkerhet. Den är också minskat dubbelarbete inom regelefterlevnad.

NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder. SaaS-registret stödjer tillgångshantering. Baslinjekonfigurationer stödjer cyberhygien. MFA och åtkomstgranskning stödjer åtkomstkontroll. Loggning stödjer incidenthantering. Leverantörsgranskning stödjer säkerhet i leveranskedjan. Underlagscykeln stödjer policyer och rutiner för att bedöma effektivitet.

DORA kräver att finansiella entiteter identifierar och klassificerar IKT-stödda funktioner, informationstillgångar, IKT-tillgångar och tredjepartsberoenden. DORA kräver också skydds- och förebyggande åtgärder, åtkomstkontroller, stark autentisering, kryptering, kontinuitet, testning, incidenthantering och styrning av IKT-tredjepartsrisk. Ett SSPM-underlagspaket för SaaS kan stödja DORA-register, beroendekartläggning, avtalsöversyn, revisionsrätt och exit-planering.

GDPR kräver att personuppgiftsansvariga kan visa efterlevnad av riktighet, konfidentialitet och ansvarsskyldighet. SaaS-register identifierar var personuppgifter behandlas. Baslinjekonfigurationer minskar risken för obehörigt röjande. Åtkomstgranskning stödjer principen om minsta privilegium. Loggning stödjer incidentutredning. Leverantörsposter stödjer styrning av personuppgiftsbiträden och ansvarsskyldighet.

NIST CSF 2.0 tillför ett användbart kommunikationslager. Funktionen GOVERN kräver att rättsliga, regulatoriska och avtalsmässiga cybersäkerhetskrav förstås och hanteras. Dess utfall för leveranskedjan kräver leverantörsroller, avtal, leverantörsgranskning, övervakning och aktiviteter efter avslutad relation. Funktionerna IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER mappar naturligt mot SaaS-register, åtkomstkontroll, dataskydd, loggning, incidentrespons och återställning.

COBIT 2019- och ISACA-orienterade revisorer närmar sig vanligtvis SSPM genom styrning, ledningsmål, riskägarskap, kontrolldrift och kontrollsäkring. De kommer att fråga om SaaS-beslut är anpassade till organisationens mål, om risksvar är dokumenterade, om ansvar har tilldelats och om kontrollsäkringsaktiviteter visar att kontroller fungerar.

Revisionsperspektivet: hur olika revisorer testar SaaS-läge

Ett starkt SSPM-program klarar olika revisionsstilar eftersom det producerar underlag på rätt nivå.

En ISO/IEC 27001:2022-revisor börjar med omfattning, intressenter, riskbedömning, tillämpbarhetsförklaring och operativt underlag. Om kontroll 5.23 ingår förväntas underlag för val, användning, hantering och avveckling av molntjänster. Om kontroller för åtkomsträttigheter ingår kommer revisorn att ta stickprov på användare och fråga om ändringar kopplade till nyanställningar, interna förflyttningar och avslutade anställningar återspeglas i SaaS-behörigheter.

En DORA-granskare fokuserar på kritiska eller viktiga funktioner, IKT-tredjepartsberoenden, registrets fullständighet, avtal, incidentklassificering, testning och exit-planering. Om en SaaS-plattform stödjer betalningsverksamhet, kundonboarding, handel, riskanalys eller kundkommunikation höjs kraven på underlag.

En GDPR-revisor eller integritetsgranskare frågar var personuppgifter lagras, vem som kan få åtkomst till dem, vilka export- och delningsinställningar som finns, om personuppgiftsbiträden styrs, om loggar stödjer incidentbedömning och om kontrollerna är proportionerliga i förhållande till risken.

Leverantörsrisk, delat ansvar och incidentberedskap

SSPM börjar ofta med konfiguration, men får inte stanna där. SaaS är också en fråga om leverantörsrisk och incidentberedskap.

DORA kräver att finansiella entiteter upprätthåller register över IKT-tjänsteavtal, skiljer mellan arrangemang som stödjer kritiska eller viktiga funktioner, bedömer koncentrationsrisk, utvärderar leverantörens lämplighet och upprätthåller exit-strategier. Avtal bör omfatta tjänstebeskrivningar, datalagringsplats, skydd av tillgänglighet, autenticitet, riktighet och konfidentialitet, dataåtkomst, återställning och återlämning, incidentstöd, samarbete med myndigheter, rätt att säga upp avtalet, säkerhetskrav, revisionsrätt och övergångsstöd.

NIS2 Article 21 omfattar även säkerhet i leveranskedjan och kräver att entiteter beaktar sårbarheter som är specifika för direkta leverantörer och tjänsteleverantörer, produkternas kvalitet och leverantörers cybersäkerhetspraxis.

I praktiken bör en kritisk SaaS-granskning kombinera underlag från säkerhetsfrågeformulär, avtalsgranskning, status för personuppgiftsbiträdesavtal, incidenthistorik, servicenivååtaganden, åtkomst till loggar, revisionsrapporter, konfigurationsunderlag och exit-genomförbarhet.

Luckan i delat ansvar uppstår när team antar att leverantörens certifiering täcker tenant-konfiguration. Det gör den inte. En leverantör kan driva en säker plattform medan kunden aktiverar publik delning, lämnar inaktiva administratörskonton aktiva eller beviljar för omfattande API-behörigheter. SSPM stänger den luckan.

Incidentberedskap är lika viktig. NIS2-rapportering av betydande incidenter omfattar en tidig varning inom 24 timmar, en anmälan inom 72 timmar och en slutrapport senast en månad efter 72-timmarsanmälan. DORA kräver hantering av IKT-relaterade incidenter med detektering, registrering, klassificering, eskalering, kommunikation och anmälan. GDPR-bedömning av personuppgiftsincident beror också på snabb förståelse av vad som hände, vilka data som påverkades och vilka registrerade som berördes.

Om en misstänkt OAuth-app har fått åtkomst till kundfiler behöver ni veta när appen auktoriserades, vilken användare som auktoriserade den, vilka behörigheter som beviljades, vilka data som åtkoms, om data laddades ned eller delades, vilka användare eller kunder som berördes, om åtkomsten fortfarande är aktiv och vilka begränsningsåtgärder som vidtogs.

Utan loggning och bevarande kan organisationen tvingas göra antaganden enligt värsta fall. Det ökar rättslig exponering, trycket i kundkommunikation och regulatorisk osäkerhet. Om en SaaS-leverantör tar extra betalt för revisionsloggar bör riskägaren uttryckligen acceptera kvarstående risk eller godkänna den licensnivå som krävs. Det beslutet hör hemma i riskbehandlingsposten och ledningens genomgång.

Vanliga felmönster inom SSPM

Samma felmönster återkommer i olika sektorer.

För det första upptäcks skugg-SaaS genom fakturor, webbläsarhistorik eller SSO-loggar snarare än via upphandling. Lösningen är inte bara att blockera verktyg. Det krävs en lättviktig intagsprocess som verksamhetsteam kan använda.

För det andra är SaaS-ägarskap oklart. CRM-systemet ”ägs av försäljning”, men ingen inom försäljning kan förklara administratörsroller, API-token, dataexporter eller bevarandeinställningar. Tilldela applikationsägare och tekniska ägare separat.

För det tredje är åtkomstgranskningar för generiska. En granskare godkänner ”alla användare” utan att kontrollera högriskroller, inaktiva användare, gäster, externa samarbetspartner eller tjänstekonton. SSPM-åtkomstgranskning måste riskprioriteras.

För det fjärde ignoreras OAuth-appar. Många organisationer granskar mänskliga användare men inte app-till-app-behörigheter. I modern SaaS kan integrationer vara kraftfullare än användare.

För det femte finns baslinjekonfigurationer bara som skärmdumpar från certifieringsprojektet. De övervakas inte för drift. Anpassa SSPM till konfigurationshantering så att baslinjekontroller blir återkommande underlag.

För det sjätte är leverantörsgranskning och granskning av SaaS-läge separerade. Upphandling har avtalet, IT har administratörskonsolen, dataskyddsfunktionen har personuppgiftsbiträdesavtalet och säkerhetsfunktionen har riskregistret. Revisorn ser fragment. SSPM för samman dem.

Ledningsrapportering: gör SaaS-risk synlig för styrelsen

NIS2 och DORA gör båda IKT- och cybersäkerhetsstyrning till en ledningsfråga. ISO/IEC 27001:2022 kräver också ledarskap, resurser, rolltilldelning, övervakning och ledningens genomgång.

En effektiv SSPM-ledningsrapport bör besvara:

• Vilka kritiska SaaS-tjänster omfattas?
• Vilka reglerade processer är beroende av dem?
• Vilka innehåller personuppgifter eller känsliga verksamhetsdata?
• Vilka har försenade åtkomstgranskningar?
• Vilka har olösta högriskluckor i konfiguration?
• Vilka har icke godkända OAuth-appar eller integrationer?
• Vilka leverantörer saknar aktuellt säkerhetsunderlag?
• Vilka loggningsluckor påverkar incidentrapportering?
• Vilka undantag kräver riskacceptans?
• Vilka investeringar eller beslut behövs?

Detta omvandlar SSPM från ett tekniskt uppstädningsprojekt till ett styrningsunderlag. Det gör också informationssäkerhetschefen mer effektiv eftersom riskacceptans flyttas till rätt nivå.

Omvandla SaaS-läge till revisionsklart underlag

Om er organisation förlitar sig på SaaS för reglerade data, finansiell verksamhet, kundsupport, HR, samarbete, utveckling eller analys är SSPM inte längre valfritt. Det är en del av cyberhygien, IKT-riskhantering, ansvarsskyldighet inom dataskydd och revisionsberedskap.

Clarysec kan hjälpa er att gå från utspridda SaaS-iakttagelser till ett strukturerat, underlagsdrivet program genom att använda:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för att strukturera införande inom användning av molntjänster, åtkomstbegränsning och konfigurationshantering.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls för att mappa ISO/IEC 27002:2022-kontroller mot NIS2, DORA, GDPR, NIST CSF 2.0 och revisionsförväntningar.
• Clarysecs policymallar, såsom Policy för användning av molntjänster Policy för användning av molntjänster, Policy för användning av molntjänster-sme Policy för användning av molntjänster - SME, Policy för hantering av användarkonton och privilegier-sme Policy för hantering av användarkonton och privilegier - SME, Loggnings- och övervakningspolicy-sme Loggnings- och övervakningspolicy - SME och Policy för leverantörssäkerhet och tredjepartssäkerhet-sme Policy för leverantörssäkerhet och tredjepartssäkerhet - SME för att skapa tillämpbara operativa regler.

Börja med era fem SaaS-plattformar med högst risk. Tilldela ägare. Registrera data, åtkomst, konfiguration, integrationer, loggar och leverantörsunderlag. Omvandla iakttagelser till riskbehandlingsåtgärder och ledningsbeslut.

Det är så SaaS Security Posture Management blir mer än en verktygskategori. Det blir en försvarbar efterlevnadsdisciplin för 2026.

Ladda ned Clarysecs policymallar, använd Zenith Blueprint för att planera er 30-dagars SSPM-sprint för underlag och mappa era SaaS-kontroller med Zenith Controls innan nästa revision hittar luckorna åt er.