Revisionsbevis för molnmiljöer enligt ISO 27001, NIS2 och DORA

Maria, informationssäkerhetschef på ett snabbväxande företag inom finansiell analys, hade sex veckor på sig innan tre tidsfrister sammanföll. Den uppföljande revisionen enligt ISO 27001:2022 var redan inplanerad. NIS2 hade placerat bolaget i en ny nivå av ledningsansvar som viktig entitet. DORA skulle snart pröva om hennes fintechverksamhet kunde visa digital operativ resiliens. Samtidigt höll en större företagskund inne ett avtal tills hennes team kunde klara en detaljerad säkerhetsgranskning.

Företaget var inte osäkert. Det körde produktionsarbetslaster i AWS och Azure, använde Microsoft 365 och flera kritiska SaaS-plattformar, krävde MFA, säkerhetskopierade data, genomförde sårbarhetsskanningar och samlade in loggar från molnmiljöer. Problemet var bevisningen.

Underlaget var utspritt över skärmdumpar från Slack, wiki-sidor för utvecklare, exporter från molnkonsoler, upphandlingsmappar, juridiska avtal och muntliga försäkringar från plattformsägare. När en revisor frågade: ”Visa hur ni styr er molnmiljö”, skulle en länk till molnleverantörens sida om regelefterlevnad inte räcka. Leverantörens certifikat visade leverantörens kontroller. De visade inte Marias del av modellen för delat ansvar.

Det är där många program för revisionsbevis inom molnsäkerhet brister. Inte för att kontroller saknas, utan för att organisationen inte kan visa, på ett strukturerat och spårbart sätt, vilket ansvar som ligger hos leverantören, vilket ansvar som ligger hos kunden, hur SaaS- och IaaS-kontroller är konfigurerade, hur leverantörsåtaganden görs gällande och hur underlag bevaras för revisorer, tillsynsmyndigheter och kunder.

Efterlevnad i molnmiljöer är inte längre en teknisk bilaga. För en SaaS-leverantör under NIS2, en finansiell entitet under DORA eller vilken ISO 27001:2022-organisation som helst som använder IaaS, PaaS och SaaS är molnstyrning en del av ISMS-omfattningen, riskbehandlingsplanen, leverantörslivscykeln, incidentprocessen, ansvarsskyldigheten för integritet och ledningens genomgång.

Det praktiska målet är enkelt: bygg en samlad, regulatoriskt granskningsbar bevisarkitektur för molnmiljöer som besvarar frågor från ISO 27001:2022, NIS2, DORA, GDPR, kundförsäkran och internrevision utan att underlag behöver byggas om för varje ramverk.

Molnet ingår alltid i omfattningen, även när infrastrukturen är outsourcad

Den första revisionsfällan är att anta att outsourcad infrastruktur ligger utanför ISMS. Det gör den inte. Outsourcing förändrar kontrollgränsen, men tar inte bort ansvarsskyldigheten.

ISO/IEC 27001:2022 kräver att organisationen definierar sitt sammanhang, intressenter, ISMS-omfattning, gränssnitt, beroenden och processer. I en molnorienterad verksamhet är identitetsleverantören, kontot för molndrift, CRM, e-postplattformen, datalagret, CI/CD-pipelinen, ärendehanteringsverktyget och tjänsten för säkerhetskopiering ofta central verksamhetsinfrastruktur.

Clarysecs Zenith Blueprint: en revisors 30-stegs färdplan Zenith Blueprint tydliggör detta i fasen ISMS-grund och ledarskap, steg 2, intressentbehov och ISMS-omfattning:

”Om du outsourcar din IT-infrastruktur till en molnleverantör innebär det inte att den utesluts från omfattningen; i stället inkluderar du hanteringen av den relationen och molntillgångarna som en del av omfattningen (eftersom säkerheten för dina data i molnet är ditt ansvar).”

Det uttalandet är ett revisionsankare. Er omfattning bör inte säga: ”AWS är undantaget eftersom Amazon hanterar det.” Den bör säga att informationstillgångar och processer kopplade till tjänster som driftas på AWS ingår i omfattningen, inklusive hantering av säkerhetskontroller i molnmiljön, identitet, loggning, kryptering, säkerhetskopiering, leverantörsförsäkran och incidenthantering.

För ISO 27001:2022 stödjer detta klausulerna 4.1 till 4.4 om sammanhang, intressenter, omfattning och ISMS-processer. För NIS2 stödjer det förväntningarna i Article 21 på riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och underhåll, åtkomstkontroll, tillgångshantering, kryptografi, kontrolleffektivitet och MFA där det är lämpligt. För DORA stödjer det principen att finansiella entiteter fortsatt ansvarar för IKT-risk även när IKT-tjänster är outsourcade.

Frågan är inte om molnleverantören är säker. Frågan är om ni styr er användning av leverantören, konfigurerar er sida korrekt, övervakar tjänsten, hanterar leverantörsåtaganden och bevarar underlag.

Delat ansvar måste bli delat underlag

Molnleverantörer förklarar delat ansvar. Revisorer testar om ni har omsatt det i praktiken.

I IaaS säkrar leverantören normalt fysiska anläggningar, kärninfrastruktur och hypervisorn. Kunden styr identitet, konfiguration av arbetslaster, härdning av operativsystem, applikationssäkerhet, dataklassificering, krypteringsinställningar, nätverksregler, loggning, säkerhetskopiering, patchning och incidenthantering.

I SaaS styr leverantören de flesta plattformsoperationer, men kunden styr fortfarande tenantkonfiguration, användare, administratörsroller, integrationer, datadelning, bevarande, loggningsalternativ och eskaleringsrutiner.

Clarysecs Zenith Controls: vägledningen för tvärgående regelefterlevnad Zenith Controls behandlar ISO/IEC 27002:2022 control 5.23, informationssäkerhet vid användning av molntjänster, som en central kontroll för molnstyrning med förebyggande syfte för konfidentialitet, riktighet och tillgänglighet. Den kopplar molntjänster till leverantörsrelationer, säker informationsöverföring, tillgångsförteckning, förebyggande av dataläckage, endpoint- och nätverkssäkerhet samt säker utvecklingspraxis.

En central tolkning i Zenith Controls anger:

”Molntjänstleverantörer (CSP:er) fungerar som kritiska leverantörer, och därför gäller alla kontroller avseende leverantörsurval, avtalstecknande och riskhantering enligt 5.19. 5.23 går dock längre genom att hantera molnspecifika risker, såsom multitenancy, transparens kring dataplats och modeller för delat ansvar.”

Den skillnaden är avgörande. Enbart leverantörscertifikat uppfyller inte Annex A.5.23. Ni behöver kundstyrt underlag som visar att molntjänsten styrs, konfigureras, övervakas och granskas.

Detta är skillnaden mellan att ha molnkontroller och att ha molnkontroller med revisionsberedskap.

Börja med ett register över molntjänster som revisorer kan använda

Det snabbaste sättet att förbättra revisionsberedskapen för molnmiljöer är att skapa ett komplett register över molntjänster. Det ska inte vara en upphandlingslista eller en export från ekonomi. Det ska koppla molntjänster till data, ägare, regioner, åtkomst, avtal, kritikalitet, regulatorisk relevans och underlag.

Clarysecs SME Policy för användning av molntjänster-sme Policy för användning av molntjänster-sme ger en kompakt och revisionsvänlig baslinje i klausul 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”

För företagsmiljöer fastställer Clarysecs Policy för användning av molntjänster Policy för användning av molntjänster det bredare mandatet:

”Denna policy fastställer organisationens obligatoriska krav för säker, regelrätt och ansvarsfull användning av molntjänster över leveransmodellerna Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) och Software-as-a-Service (SaaS).”

Policy för användning av molntjänster kräver ett centraliserat register som ägs av informationssäkerhetschefen och godkända baskonfigurationer för molnmiljöer. Registret blir grunden för underlag till flera skyldigheter samtidigt.

För ISO 27001:2022 stödjer det tillgångsförteckning, styrning av molnanvändning, leverantörsrelationer, åtkomstkontroll, rättsliga och avtalsmässiga krav, riskbehandling och dokumenterad information. För NIS2 stödjer det säkerhet i leveranskedjan, tillgångshantering, riskanalys, incidenthantering och kontinuitet. För DORA stödjer det kartläggning av IKT-tillgångar och beroenden, register över IKT-tredjepartsleverantörer, kartläggning av kritiska eller viktiga funktioner och analys av koncentrationsrisk. För GDPR identifierar det om personuppgifter behandlas, var de finns, vilken leverantör som agerar personuppgiftsbiträde och vilka överförings- eller personuppgiftsbiträdesvillkor som gäller.

Om registret inte identifierar datakategorier och regioner blir underlag för integritet och resiliens ofullständigt. Om det inte identifierar applikationsägare blir åtkomstgranskning utan ägare. Om det inte identifierar avtal och förnyelsedatum kan leverantörssäkerhetsklausuler inte testas.

Gör ISO 27001:2022 till ryggraden för molnunderlag

ISO 27001:2022 är den bästa ryggraden för molnunderlag eftersom den kopplar verksamhetens sammanhang, risk, kontroller, operativt bevismaterial, övervakning och förbättring.

Viktiga ISO 27001:2022-krav med relevans för molnmiljöer omfattar:

• Klausulerna 4.1 till 4.4 för sammanhang, intressenter, ISMS-omfattning, gränssnitt, beroenden och processer.
• Klausulerna 5.1 till 5.3 för ledarskap, policy, roller, ansvar och ansvarsskyldighet.
• Klausulerna 6.1.1 till 6.1.3 för riskbedömning, riskbehandling, jämförelse mot Annex A, uttalande om tillämplighet (SoA) och acceptans av kvarstående risk.
• Klausul 7.5 för styrd dokumenterad information.
• Klausulerna 8.1 till 8.3 för operativ planering, genomförande av riskbedömning och genomförande av riskbehandling.
• Klausulerna 9.1 till 9.3 för övervakning, mätning, internrevision och ledningens genomgång.
• Klausul 10 för avvikelse, korrigerande åtgärder och ständig förbättring.

De Annex A-kontroller som bär mest tyngd för molnunderlag omfattar A.5.19 informationssäkerhet i leverantörsrelationer, A.5.20 hantering av informationssäkerhet i leverantörsavtal, A.5.21 hantering av informationssäkerhet i IKT-leveranskedjan, A.5.22 övervakning, granskning och ändringshantering av leverantörstjänster, A.5.23 informationssäkerhet vid användning av molntjänster, A.5.24 till A.5.27 incidenthantering, A.5.29 informationssäkerhet vid störning, A.5.30 IKT-beredskap för verksamhetskontinuitet, A.5.31 rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav, A.5.34 integritet och skydd av PII, A.5.36 efterlevnad av policyer, regler och standarder för informationssäkerhet, A.8.8 hantering av tekniska sårbarheter, A.8.9 konfigurationshantering, A.8.13 informationssäkerhetskopiering, A.8.15 loggning, A.8.16 övervakningsaktiviteter, A.8.24 användning av kryptografi, A.8.25 säker utvecklingslivscykel, A.8.29 säkerhetstestning vid utveckling och acceptans samt A.8.32 ändringshantering.

I Zenith Blueprint beskriver fasen Kontroller i praktiken, steg 23, molntjänster med ett språk som revisorer känner igen:

”Övergången till molntjänster medför betydande förändringar i tillitsmodellen. Du kontrollerar inte längre servern, nätverksperimetern eller hypervisorn. Ofta vet du inte ens var data fysiskt finns. Det du kontrollerar, och det den här kontrollen kräver, är styrningen av relationen, insynen i vad du använder och de säkerhetsförväntningar du ställer på dina leverantörer.”

En stark SoA-post för A.5.23 bör inte bara säga ”Tillämplig, molnleverantör certifierad”. Den bör förklara varför kontrollen är tillämplig, vilka risker den behandlar, hur den är införd och var underlag lagras.

Lägg till en kolumn för underlagets plats i SoA eller kontrolluppföljningen. Revisorer ska inte behöva söka i e-post, ärendehanteringssystem och delade enheter för att hitta bevismaterial.

Använd en gemensam underlagsmodell för ISO 27001:2022, NIS2 och DORA

NIS2 och DORA kräver båda dokumenterad, riskbaserad och ledningsstyrd cybersäkerhet. Överlappningen är betydande, men tillsynstrycket skiljer sig åt.

NIS2 gäller för många väsentliga och viktiga entiteter i EU, inklusive leverantörer av digital infrastruktur, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, banker, infrastrukturer för finansiella marknader och digitala leverantörer. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och underhåll, sårbarhetshantering, bedömning av kontrolleffektivitet, cyberhygien, utbildning, kryptografi, åtkomstkontroll, tillgångshantering och MFA eller säker kommunikation där det är lämpligt.

För revisionsbevis inom molnsäkerhet frågar NIS2 om moln- och leverantörsrisker hanteras som en del av risken i tjänsteleveransen. Direktivet medför också strukturerad rapportering av betydande incidenter, inklusive tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och slutrapport inom en månad.

DORA gäller från den 17 januari 2025 för många finansiella entiteter i EU och skapar enhetliga krav för IKT-riskhantering, rapportering av större IKT-incidenter, testning av digital operativ resiliens, informationsdelning och IKT-tredjepartsrisk. För finansiella entiteter som också identifieras enligt NIS2 behandlas DORA som den sektorsspecifika unionsrättsakten för överlappande operativa skyldigheter.

För molntjänster är DORA direkt. Finansiella entiteter ansvarar fortsatt för IKT-risk när tjänster är outsourcade. De behöver strategier för IKT-tredjepart, avtalsregister, förhandsbedömningar inför avtal, leverantörsgranskning, revisionsrätt och åtkomsträttigheter, utlösare för uppsägning, analys av koncentrationsrisk, kontroller för underleverantörer och testade exitstrategier.

Zenith Controls kartlägger ISO/IEC 27002:2022 control 5.23 mot EU:s NIS2-direktiv Article 21 och DORA Articles 28 to 31. Den pekar också på stödjande standarder såsom ISO/IEC 27017 för molnsäkerhetsroller och övervakning, ISO/IEC 27018 för skydd av PII i publika moln, ISO/IEC 27701 för integritetshantering i relationer med molnbaserade personuppgiftsbiträden, ISO/IEC 27036-4 för övervakning av molntjänster och leverantörsavtal samt ISO/IEC 27005 för riskbedömning av molnmiljöer.

Den praktiska konsekvensen är enkel. Bygg inte separata underlagspaket för ISO 27001:2022, NIS2, DORA och GDPR. Bygg en molnbaserad bevisarkitektur med ramverksspecifika kartläggningar.

Leverantörsavtal är kontrollunderlag, inte juridiska arkiv

Revisionsbevis för molnmiljöer brister ofta i avtalslagret. Säkerhetsfunktionen har ett leverantörsfrågeformulär. Juridik har huvudavtalet. Upphandling har förnyelsedatumet. Dataskyddsombudet har DPA. Ingen har en samlad bild av om avtalet innehåller de säkerhetsklausuler som krävs enligt ISO 27001:2022, NIS2, DORA och GDPR.

Clarysecs SME Policy för leverantörssäkerhet och tredjepartssäkerhet-sme Policy för leverantörssäkerhet och tredjepartssäkerhet-sme anger i klausul 5.3:

”Avtal ska innehålla obligatoriska klausuler som omfattar: 5.3.1 Sekretess och tystnadsplikt 5.3.2 Informationssäkerhetsskyldigheter 5.3.3 Tidslinjer för anmälan av personuppgiftsincidenter (t.ex. inom 24–72 timmar) 5.3.4 Revisionsrätt eller tillgång till underlag för regelefterlevnad 5.3.5 Begränsningar av vidare underleverantörer utan godkännande 5.3.6 Uppsägningvillkor, inklusive säker återlämning eller förstöring av data”

För revisionsmässig konsekvens bör dessa klausuler översättas till en avtalsgranskningsmatris. ISO 27001:2022 Annex A.5.20 förväntar sig att säkerhetskrav avtalas med leverantörer. GDPR Article 28 kräver villkor för personuppgiftsbiträden som omfattar sekretess, säkerhetsåtgärder, assistans, underbiträden, radering eller återlämning av data och revisionsstöd. DORA Article 30 kräver detaljerade avtalsbestämmelser för IKT-tredjepartsleverantörer, inklusive tjänstebeskrivningar, dataplats, säkerhet, incidentstöd, samarbete med myndigheter, revisionsrätt, åtkomsträttigheter, uppsägning och övergångsarrangemang. NIS2:s krav på säkerhet i leveranskedjan behöver också leverantörssamarbete som kan göras gällande.

Zenith Controls kartlägger ISO/IEC 27002:2022 control 5.20 mot leverantörsavtal och noterar kopplingar till 5.19 leverantörsrelationer, 5.14 informationsöverföring, 5.22 leverantörsövervakning, 5.11 återlämning av tillgångar och 5.36 efterlevnad.

Den centrala punkten är att omsätta avtalet i drift. Om ett molnavtal ger tillgång till SOC 2-rapporter kan revisorer fråga om ni har hämtat rapporten, granskat undantag, följt upp åtgärdande och omprövat risk. Om avtalet utlovar incidentanmälan kan de fråga om er åtgärdsplan för incidenter innehåller leverantörens kontaktväg och regulatoriska beslutspunkter. Om ändringar av underleverantörer kräver godkännande eller avisering kan de fråga om aviseringar om underbiträden granskas före acceptans.

Ett avtal utan granskningsunderlag är ett arkiv. Ett avtal kopplat till leverantörsrisk, övervakningsposter och incidentarbetsflöden är en kontroll.

SaaS-loggning och SaaS-konfiguration är vanliga blinda fläckar vid revision

Iakttagelser i molnrevisioner kommer ofta från SaaS, inte IaaS. Infrastrukturteam har vanligtvis tekniska ägare, loggningspipelines, baslinjekontroller och ändringsposter. SaaS-plattformar är fragmenterade över sälj, HR, ekonomi, kundframgång, marknad och drift. Var och en kan behandla känsliga eller reglerade data.

Clarysecs Loggnings- och övervakningspolicy-sme Loggnings- och övervakningspolicy-sme hanterar detta direkt i klausul 5.5:

”5.5 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”

För företagsmiljöer tillägger Policy för användning av molntjänster:

”Molntjänster ska integreras i organisationens SIEM för kontinuerlig övervakning.”

Detta krav flyttar SaaS från ”verksamhetsverktyg” till ”övervakat informationssystem”. Underlag bör omfatta exporter av loggningsinställningar, bevis på SIEM-anslutning, larmregler, triageärenden, inställningar för bevarande och granskningar av administrativ åtkomst.

För kritiska SaaS-tjänster ska underlag förberedas för skapande av administratörskonton, misstänkta inloggningar, massnedladdningar, publik delning, inaktivering av MFA, skapande av API-token, extern gästanvändaraktivitet och privilegiehöjning. För IaaS ska CloudTrail eller motsvarande loggning på kontrollplanet, åtkomstloggar för lagring, IAM-ändringar, flödesloggar där det är lämpligt, CSPM-iakttagelser, sårbarhetsskanningar, patchunderlag, krypteringsinställningar, status för säkerhetskopiering, granskningar av nätverkssäkerhetsgrupper och ändringsärenden förberedas.

Zenith Controls revisionsmetodik för control 5.23 noterar att en revision enligt ISO/IEC 27007-stil kan granska behörigheter för AWS S3-buckets, kryptering, IAM-policyer och CloudTrail-loggning. En COBIT-inriktad revisor kan granska larmkonfigurationer, DLP-kontroller, användning av Microsoft 365 Secure Score och ändringsloggar. Ett NIST SP 800-53A-perspektiv kan testa kontohantering och övervakning, inklusive om arbetslaster i molnet patchas, skannas och övervakas med samma noggrannhet som interna system.

Olika revisorer talar olika dialekter. Ert underlag bör vara detsamma.

Bygg ett regulatoriskt granskningsbart underlagspaket för en SaaS-tjänst och en IaaS-tjänst

Ett praktiskt arbetsflöde börjar med en kritisk SaaS-plattform och en kritisk IaaS-miljö. Exempelvis Microsoft 365 för samarbete och AWS för produktionsdrift.

Steg 1: Uppdatera registret över molntjänster

För Microsoft 365, registrera syfte, ägare, datatyper, region, administratörskonton, avtal, DPA, supportkontakt, förnyelsedatum och kritikalitet. För AWS, registrera produktionskontot, regioner, datakategorier, arbetslaster, kontoägare, status för root-konto, supportplan, avtalsvillkor och kopplade verksamhetstjänster.

Använd fälten i Policy för användning av molntjänster-sme som minsta dataset. Lägg till kritikalitet, regulatorisk relevans och underlagets plats.

Steg 2: Dokumentera delat ansvar

För Microsoft 365 omfattar kundens ansvar användarlivscykel, MFA, villkorsstyrd åtkomst, gästdelning, bevarandetiketter, DLP där det används, loggning och incidenteskalering. För AWS omfattar kundens ansvar IAM, nätverksregler, härdning av arbetslaster, krypteringskonfiguration, säkerhetskopiering, loggning, patchning och applikationssäkerhet.

Bifoga leverantörens dokumentation om delat ansvar och kartlägg därefter varje kundansvar till en kontrollägare och underlagskälla.

Steg 3: Samla in konfigurationsunderlag

För Microsoft 365, exportera eller ta skärmdumpar av MFA och policyer för villkorsstyrd åtkomst, administratörsroller, inställningar för extern delning, revisionsloggning, bevarandekonfiguration och åtgärder för säkerhetspoäng. För AWS, exportera IAM-lösenordspolicy, MFA-status för privilegierade konton, CloudTrail-konfiguration, S3 public access block, krypteringsstatus, granskning av säkerhetsgrupper, säkerhetskopieringsjobb och status för sårbarhetsskanning.

Policy för användning av molntjänster kräver att molnmiljöer följer en dokumenterad baskonfiguration som godkänts av molnsäkerhetsarkitekten. Ert underlagspaket bör innehålla både baslinjen och bevis på överensstämmelse.

Steg 4: Koppla leverantörs- och integritetsunderlag

Bifoga avtal, DPA, lista över underbiträden, villkor för incidentanmälan, rapporter om revisionsförsäkran och underlag om dataplats. Om personuppgifter behandlas, registrera om leverantören agerar personuppgiftsbiträde, hur radering hanteras, hur stöd för registrerades begäranden fungerar och vilka skyddsåtgärder för överföring som gäller.

För DORA, identifiera om molntjänsten stödjer en kritisk eller viktig funktion. Om ja, koppla underlaget till IKT-tredjepartsregistret, leverantörsgranskningsfilen, revisionsrätten, exitplanen och granskningen av koncentrationsrisk.

Steg 5: Koppla loggning till incidenthantering

Visa att loggar är aktiverade, dirigerade, granskade och använda. Bifoga SIEM-paneler, larmregler och minst ett stängt larmärende. Kartlägg därefter arbetsflödet mot rapporteringsbeslutspunkter enligt NIS2 och DORA.

För NIS2 ska incidentprocessen stödja tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och slutrapport inom en månad för betydande incidenter. För DORA bör IKT-incidentprocessen klassificera incidenter utifrån berörda kunder, transaktioner, varaktighet, avbrottstid, geografisk spridning, datapåverkan, tjänstens kritikalitet och ekonomisk påverkan.

Steg 6: Lagra underlag disciplinerat

Clarysecs Policy för revision och regelefterlevnadsövervakning-sme Policy för revision och regelefterlevnadsövervakning-sme klausul 6.2 definierar praktisk disciplin för underlag:

”6.2 Bevisinsamling och dokumentation 6.2.1 Allt underlag ska lagras i en central revisionsmapp. 6.2.2 Filnamn ska tydligt ange revisionsämne och datum. 6.2.3 Metadata (t.ex. vem som samlade in det, när och från vilket system) ska dokumenteras. 6.2.4 Underlag ska bevaras i minst två år, eller längre där det krävs enligt certifiering eller kundavtal.”

Företagsversionen Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning anger målet:

”Att generera försvarbart underlag och ett revisionsspår till stöd för regulatoriska förfrågningar, rättsprocesser eller förfrågningar om säkerhetsförsäkran från kunder.”

En skärmdump med namnet ”screenshot1.png” är svagt underlag. En fil med namnet ”AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” är starkare eftersom den beskriver systemet, kontrollen, datumet och insamlaren. Metadata är viktigt eftersom revisorer behöver kunna lita på när underlaget samlades in, vem som samlade in det och från vilket system.

Hur revisorer testar samma molnkontroll

De starkaste underlagspaketen för molnmiljöer är utformade för flera revisionsperspektiv. ISO 27001:2022-revisorer testar om kontrollen finns i ISMS, riskbedömning, riskbehandling och SoA. NIST-inriktade bedömare testar tekniskt genomförande. COBIT 2019-revisorer testar styrning, leverantörsprestation och processintegration. Integritetsrevisorer fokuserar på personuppgiftsbiträdesskyldigheter, datalagringsplats, incidentberedskap och registrerades rättigheter. Tillsynsgranskningar enligt DORA fokuserar på IKT-tredjepartsrisk och resiliens.

Zenith Controls omfattar dessa skillnader i revisionsmetodik för molntjänster, leverantörsavtal och leverantörsövervakning. För 5.22, övervakning, granskning och ändringshantering av leverantörstjänster, framhåller den att revisorer kan granska kvartalsvisa protokoll från leverantörsgranskningar, KPI-rapporter, utvärderingar av SOC-rapporter, ändringsloggar, riskbedömningar, leverantörsincidenter och ärendeuppföljning. För 5.20, hantering av informationssäkerhet i leverantörsavtal, framhåller den avtalsurval för sekretess, säkerhetsskyldigheter, incidentanmälan, revisionsrätt, godkännande av underleverantörer och uppsägningvillkor.

Tvärgående efterlevnadskontroller som bär molnrevisionens tyngd

En regulatoriskt granskningsbar modell för molnunderlag byggs kring ett mindre antal kontroller med hög hävstång. Dessa kontroller bär en stor del av efterlevnadsbördan över ISO 27001:2022, NIS2, DORA, GDPR, NIST och COBIT 2019.

NIST SP 800-53 Rev.5 tillför tekniskt djup genom kontohantering, externa systemtjänster, kontinuerlig övervakning, systemövervakning och gränsskydd. COBIT 2019 tillför styrningsdjup genom hantering av leverantörsrelationer, leverantörsrisk, datautbyte, nätverkssäkerhet och ändringsberedskap.

Stödjande ISO-standarder skärper underlagsmodellen. ISO/IEC 27017 ger molnspecifik vägledning om delade roller, konfiguration av virtuella maskiner och övervakning av kundaktivitet. ISO/IEC 27018 fokuserar på skydd av PII i publika moln. ISO/IEC 27701 utvidgar integritetsskyldigheter till personuppgiftsbiträdens och personuppgiftsansvarigas verksamhet. ISO/IEC 27036-4 stödjer molnbaserade leverantörsavtal och övervakning. ISO/IEC 27005 gäller riskbedömning av molnmiljöer.

Ledningens genomgång måste se molnrisk, inte bara molnets upptid

En av de mest förbisedda revisionsartefakterna är ledningens genomgång. ISO 27001:2022 förväntar sig att ledningens genomgång beaktar ändringar, intressentbehov, prestationstrender, revisionsresultat, status för riskbehandling och förbättringsmöjligheter. NIS2 kräver att ledningsorgan godkänner åtgärder för cybersäkerhetsriskhantering och övervakar genomförandet. DORA kräver att ledningsorganet definierar, godkänner, övervakar och fortsatt ansvarar för IKT-riskhantering.

En kvartalsvis panel för molnsäkerhet och leverantörer bör visa:

• Antal godkända molntjänster.
• Kritiska molntjänster och ägare.
• Tjänster som behandlar personuppgifter.
• Tjänster som stödjer kritiska eller viktiga funktioner.
• Öppna högriskfelkonfigurationer i molnmiljöer.
• Status för MFA och granskning av privilegierad åtkomst.
• Loggtäckning för kritiska SaaS- och IaaS-plattformar.
• Rapporter om leverantörsförsäkran som mottagits och granskats.
• Avtalsundantag och accepterade risker.
• Molnrelaterade incidenter, nära-händelser och erfarenhetsåterföring.
• Resultat från tester av säkerhetskopiering och återställning.
• Status för koncentrationsrisk och exitplan.

Denna panel blir underlag för ledarskap och prestationsutvärdering enligt ISO 27001:2022, styrning enligt NIS2 och ledningens ansvarsskyldighet enligt DORA.

Zenith Blueprint, i riskhanteringsfasen, steg 14, rekommenderar korsreferenser till regulatoriska krav när riskbehandlingar och policyer genomförs. Den anger att kartläggning av centrala regulatoriska krav mot ISMS-kontroller är en användbar intern övning och ”också imponerar på revisorer/bedömare eftersom ni inte hanterar säkerhet i ett vakuum utan är medvetna om den rättsliga kontexten.”

Det är den mognad som tillsynsmyndigheter och företagskunder förväntar sig.

Vanliga revisionsiakttagelser i molnmiljöer och hur de undviks

I arbete med revisionsberedskap för molnmiljöer är återkommande iakttagelser förutsägbara:

1. Registret över molntjänster finns, men SaaS-verktyg saknas.
2. Dataplats är inte registrerad eller har kopierats från marknadssidor i stället för avtalsunderlag.
3. MFA krävs för anställda men inte för alla administrativa konton eller break-glass-konton.
4. Molnloggar är aktiverade men granskas inte, bevaras inte eller är inte kopplade till incidenthantering.
5. Leverantörers SOC-rapporter arkiveras men bedöms inte.
6. Avtalsklausuler finns för nya leverantörer men inte för äldre kritiska tjänster.
7. Aviseringar om underbiträden tas emot via e-post men riskbedöms inte.
8. Säkerhetskopieringsjobb körs korrekt, men återställningstester är inte dokumenterade med underlag.
9. Delat ansvar förstås av ingenjörer men är inte dokumenterat för revisorer.
10. SoA markerar molnkontroller som tillämpliga men länkar inte till riskposter, underlag eller ägare.

Detta är spårbarhetsproblem. Lösningen är att koppla policy, risk, kontroll, ägare, underlag och granskning.

När Maria nådde revisionsdagen behövde hon inte längre förlita sig på utspridda skärmdumpar. Hon öppnade en central panel som visade registret över molntjänster, riskbedömningar, SoA-poster, underlag för baskonfigurationer, leverantörsgranskningsfiler, loggningsbevis och DORA-granskning av koncentrationsrisk. När revisorn frågade hur molnrisker styrdes visade hon ISMS. När revisorn frågade hur tjänster konfigurerades säkert visade hon baslinjen och CSPM-underlaget. När revisorn frågade om IKT-tredjepartsrisk visade hon avtalsgranskningen, leverantörsövervakningen och exitplaneringen.

Resultatet var inte en perfekt miljö. Ingen molnmiljö är perfekt. Skillnaden var att riskbeslut var dokumenterade, underlag var försvarbart och ansvarsskyldighet var synlig.

Bygg ert molnunderlagspaket innan revisorn frågar

Om organisationen är beroende av SaaS, IaaS eller PaaS kommer nästa revision inte att godta ”leverantören hanterar det” som ett tillräckligt svar. Ni behöver visa delat ansvar, kundstyrd konfiguration, leverantörsklausuler, loggning, incidentberedskap, resiliens och ledningens tillsyn.

Börja med tre praktiska åtgärder den här veckan:

1. Skapa eller uppdatera ert register över molntjänster med Clarysecs Policy för användning av molntjänster Policy för användning av molntjänster eller Policy för användning av molntjänster-sme Policy för användning av molntjänster-sme.
2. Kartlägg era fem viktigaste molntjänster mot ISO 27001:2022 Annex A-kontroller, NIS2 Article 21, DORA:s IKT-tredjepartsskyldigheter där de är tillämpliga och GDPR:s krav på personuppgiftsbiträden.
3. Bygg en centraliserad underlagsmapp med bevarande- och metadatadisciplinen från Policy för revision och regelefterlevnadsövervakning Policy för revision och regelefterlevnadsövervakning eller Policy för revision och regelefterlevnadsövervakning-sme Policy för revision och regelefterlevnadsövervakning-sme.

Använd därefter Zenith Blueprint Zenith Blueprint för att placera arbetet i 30-stegs färdplanen för ISMS-revision och Zenith Controls Zenith Controls för att validera tvärgående kartläggningar av regelefterlevnad, stödjande ISO-standarder och förväntningar på revisionsmetodik.

Clarysec kan hjälpa er att omvandla utspridda skärmdumpar från molnmiljöer, leverantörsfiler och SaaS-inställningar till ett regulatoriskt granskningsbart underlagspaket som håller för ISO 27001:2022-certifieringsrevisioner, tillsynsfrågor enligt NIS2, IKT-tredjepartsgranskningar enligt DORA och krav på säkerhetsförsäkran från företagskunder.