EUCS-certifiering av molntjänster som revisionsunderlag 2026
Ljuset från projektorn i styrelserummet föll över Amelias ansikte när hon tittade på en bild med rubriken ”Efterlevnadshorisont 2026”. Som informationssäkerhetschef (CISO) i ett snabbväxande fintechbolag hade hon tre akronymer på skärmen och ett återkommande operativt problem bakom dem alla: NIS2, DORA och GDPR pekade alla tillbaka mot samma molnplattformar.
DORA-revisorn ville se underlag för hantering av IKT-tredjepartsrisk för de molntjänster som driftade betalningsapplikationerna. Den behöriga myndigheten enligt NIS2 hade klassificerat företaget som en viktig entitet och frågade hur säkerheten i leveranskedjan styrdes. Dataskyddsombudet förberedde en GDPR-granskning med fokus på biträdessäkerhet, datalagringsplats och beredskap för personuppgiftsincidenter. Upphandling vidarebefordrade därefter ett kort mejl från en leverantör av molnbaserad analys:
”Vi förbereder oss för EUCS-certifiering. Kan detta ersätta er granskning av leverantörssäkerhet?”
För en pressad informationssäkerhetschef, complianceansvarig eller grundare är det frestande svaret ja. En europeisk cybersäkerhetscertifiering för molntjänster låter som exakt den typ av underlag som borde minska frågeformulär, lugna revisorer och tillfredsställa kunder.
Det mer korrekta svaret är mer precist: EUCS-certifiering av molntjänster kan bli ett starkt underlag för säkerhetsförsäkran från molnleverantörer, men endast när det mappas in i organisationens egen riskbedömning enligt ISO/IEC 27001:2022, tillämpbarhetsförklaring, leverantörsregister, register över molntjänster, avtalsmässiga kontroller, incidenthanteringsplaner och register som visar ansvarsskyldighet enligt GDPR.
Den skillnaden är viktig. NIS2 gör säkerhet i leveranskedjan och digital infrastrukturs resiliens till en tillsynsfråga. DORA innebär att finansiella entiteter fortsatt ansvarar för IKT-tredjepartsrisk, även när molntjänster är outsourcade. GDPR kräver att personuppgiftsansvariga och personuppgiftsbiträden kan visa att behandlingen är laglig, säker och förenlig med kravet på ansvarsskyldighet. ISO/IEC 27001:2022 kräver ett avgränsat, riskbaserat ledningssystem som beaktar rättsliga, regulatoriska, avtalsmässiga och tredjepartsrelaterade beroenden.
EUCS tar inte bort dessa skyldigheter. Det ger ett strukturerat underlag som kan utvärderas, normaliseras, ifrågasättas och återanvändas.
Clarysecs arbetssätt är enkelt: behandla EUCS som värdefull indata till säkerhetsförsäkran från leverantörer, inte som en genväg till efterlevnad. I Zenith Controls: guiden för korsvis efterlevnad börjar klustret för molnförsäkran med ISO/IEC 27002:2022 kontroll 5.23, informationssäkerhet vid användning av molntjänster, och kopplar den till 5.20, hantering av informationssäkerhet i leverantörsavtal, samt 5.22, övervakning, granskning och ändringshantering av leverantörstjänster. Dessa tre kontroller utgör ryggraden i en försvarbar granskning av EUCS-underlag.
Varför molnförsäkran brister under NIS2, DORA och GDPR
År 2026 är molnförsäkran inte längre bara ett arbetsflöde inom upphandling. Det är en fråga för styrelse, tillsynsmyndighet och revision.
NIS2-direktivet, Directive (EU) 2022/2555, utökar cybersäkerhetsskyldigheterna för väsentliga och viktiga entiteter. Dess tillämpningsområde omfattar många sektorer som är starkt beroende av molntjänster, och dess digitala infrastrukturlandskap omfattar leverantörer av molntjänster, leverantörer av datacentertjänster, nätverk för innehållsleverans, betrodda tjänsteleverantörer, DNS-tjänsteleverantörer och register för toppdomäner. Leverantörer av hanterade tjänster och leverantörer av hanterade säkerhetstjänster står också i fokus.
Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, däribland riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och utveckling, hantering av sårbarheter, effektivitetsbedömning, cyberhygien, kryptografi, åtkomstkontroll, tillgångshantering och autentisering. Article 23 skapar stegvisa förväntningar på incidentrapportering, inklusive tidig varning inom 24 timmar och incidentanmälan inom 72 timmar, med förbehåll för direktivet och nationellt införlivande. Article 24 tillåter medlemsstater att under vissa omständigheter kräva användning av IKT-produkter, IKT-tjänster eller IKT-processer som certifierats enligt europeiska cybersäkerhetscertifieringssystem. Article 25 uppmuntrar användning av relevanta europeiska och internationella standarder.
DORA, Regulation (EU) 2022/2554, är ännu mer direkt för finansiella entiteter. Från och med den 17 januari 2025 kräver den att finansiella organisationer hanterar IKT-risk, rapporterar allvarliga IKT-relaterade incidenter, testar digital operativ resiliens och styr IKT-tredjepartsrisk. För entiteter som omfattas fungerar DORA som den sektorsspecifika unionsrättsakten för motsvarande cybersäkerhetsskyldigheter som överlappar med nationella NIS2-regler.
DORA tillåter inte att ansvar outsourcas. Articles 28 to 30 kräver att finansiella entiteter genomför leverantörsgranskning, bedömer koncentrationsrisk, underhåller register över avtalsarrangemang, inkluderar obligatoriska avtalsmässiga skyddsåtgärder, bevarar revisionsrätt och åtkomsträtt, säkerställer incidentstöd, samarbetar med behöriga myndigheter och upprätthåller exitstrategier för IKT-tjänster som stödjer kritiska eller viktiga funktioner.
GDPR, Regulation (EU) 2016/679, lägger till lagret för ansvarsskyldighet och dataskydd. Article 5 kräver att personuppgiftsansvariga följer dataskyddsprinciperna och kan visa efterlevnad. Article 28 reglerar relationer med personuppgiftsbiträden och kräver tillräckliga garantier från biträden. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder för att säkerställa säkerhet i behandlingen.
Resultatet är ett konvergensproblem. En och samma molnleverantör kan vara en kritisk IKT-tredjepart enligt DORA, en direkt leverantör i en NIS2-leveranskedja och ett personuppgiftsbiträde eller underbiträde enligt GDPR. Om säkerhetsförsäkran hanteras genom frikopplade frågeformulär, certifierings-PDF:er och avtalsmappar blir varje revision en rekonstruktionsövning.
EUCS kan minska detta kaos, men endast när det förs in i en styrd modell för underlag.
Vad EUCS kan visa och vad det inte kan visa
EU Cybersecurity Certification Scheme for Cloud Services, vanligtvis kallat EUCS, är utformat för att tillhandahålla en europeisk mekanism för molnförsäkran inom det bredare EU-ramverket för cybersäkerhetscertifiering. Det praktiska värdet ligger inte i etiketten i sig. Värdet ligger i certifikatets underliggande omfattning, assuransnivå, bedömda tjänster, regioner, juridiska personer, bedömningsgränser, giltighetstid och modell för uppföljande revision.
Den korrekta frågan om molnförsäkran är inte bara: ”Har den här leverantören EUCS?” Den är:
- Vilka exakta molntjänster omfattas?
- Vilka regioner, datalagringsplatser och juridiska personer omfattas?
- Vilken assuransnivå gäller?
- Vilken bedömningsmetod användes?
- Vilka antaganden om delat ansvar ligger kvar hos kunden?
- Vilket underlag kan lämnas ut till kunder, tillsynsmyndigheter och revisorer?
- Hur påverkar certifikatet revisionsrätt, incidentavisering, insyn i underleverantörer och exitplanering?
Ett molncertifikat omfattar sällan organisationens egen konfiguration. Om organisationen inaktiverar MFA, exponerar lagring, tilldelar alltför omfattande administrativa behörigheter, misslyckas med att logga privilegierad åtkomst eller felkonfigurerar regioner kommer leverantörens certifiering inte att rädda revisionen.
Därför hör EUCS hemma i en underlagsmatris, inte på en piedestal. Det kan stödja leverantörssidan av säkerhetsförsäkran, men organisationen måste fortfarande visa sina egna kontroller för styrning, konfiguration, avtal och övervakning.
Zenith Blueprint: en revisors färdplan i 30 steg tydliggör detta i fasen Riskhantering, steg 13, planering av riskbehandling och tillämpbarhetsförklaring:
SoA är i praktiken ett bryggdokument: det kopplar din riskbedömning/riskbehandling till de faktiska kontroller du har. När du färdigställer det dubbelkontrollerar du också om du har missat några kontroller.
Det är den korrekta mentala modellen för EUCS. Certifikatet är leverantörsunderlag. Organisationens tillämpbarhetsförklaring förklarar varför relaterade kontroller är tillämpliga, hur organisationen har genomfört sin del av det delade ansvaret, vilket leverantörsunderlag som har godtagits och vilka kvarstående risker som återstår.
ISO 27001-ryggraden för EUCS-underlag
ISO/IEC 27001:2022 ger EUCS en naturlig hemvist. Dess klausuler kräver att organisationer förstår interna och externa frågor, identifierar intressenter och krav, definierar ISMS-omfattning, tilldelar ledningsansvar, bedömer risker, väljer kontroller, underhåller en tillämpbarhetsförklaring och ständigt förbättrar.
För molnförsäkran bör EUCS införas i minst sex ISMS-artefakter.
| ISMS-artefakt | Hur EUCS bör användas | Revisorns fråga |
|---|---|---|
| ISMS-omfattning | Identifiera molntjänster, regioner, juridiska personer, kunddata och outsourcade beroenden | Omfattar ISMS väsentliga molnberoenden och utlagda tjänster? |
| Riskregister | Registrera risker för leverantörsfel, felkonfiguration, datalagringsplats, underleverantörer och incidentrapportering | Bedöms molnrisker mot verksamhetskonsekvens och delat ansvar? |
| Leverantörsgranskning | Använd EUCS som underlag och verifiera därefter omfattning, assuransnivå, giltighet och luckor | Omfattar certifikatet exakt den tjänst som används? |
| Tillämpbarhetsförklaring | Koppla kontroller för moln, leverantörer, åtkomst, loggning, incidenter och kontinuitet till risker och regelverk | Är kontrollurvalet motiverat och spårbart? |
| Register över molntjänster | Registrera leverantör, syfte, datatyper, platser, åtkomst och avtalsdetaljer | Kan organisationen identifiera alla godkända molntjänster? |
| Avtals- och revisionsakt | Lagra certifiering, avtal, revisionsrätt, aviseringsvillkor, underleverantörsvillkor och exitbestämmelser | Kan organisationen visa bindande leverantörsförpliktelser? |
Clarysecs policybibliotek omsätter dessa krav i operativ disciplin.
SME-versionen av Policy för användning av molntjänster - SME, avsnittet Styrningskrav, punkt 5.2, anger en baslinje för godkända molntjänster:
Godkända molntjänster ska uppfylla följande baskriterier: 5.2.1 Leverantören har ett starkt anseende avseende tillgänglighet och säkerhet 5.2.2 Flerfaktorsautentisering (MFA) stöds och kan aktiveras 5.2.3 Datalagringsplats och integritetspraxis följer tillämpliga rättsliga krav (t.ex. GDPR) 5.2.4 Tjänsten tillhandahåller säker åtkomstkontroll, loggning och dataskyddsförmåga
Ett EUCS-certifikat kan stödja 5.2.1 samt delar av 5.2.3 och 5.2.4. Det visar inte att organisationens tenant har MFA aktiverat, loggning konfigurerad, datalagringsplats genomdriven eller administrativ åtkomst granskad.
För större organisationer höjer Enterprise-versionen av Policy för användning av molntjänster, avsnittet Styrningskrav, punkt 5.2, kravnivån:
All användning av molntjänster ska genomgå riskbaserad leverantörsgranskning före aktivering, inklusive leverantörsbedömning, validering av efterlevnad av rättsliga krav och granskning av kontrollvalidering.
Den meningen är den policyståndpunkt som varje EUCS-granskning bör följa: leverantörsbedömning, validering av efterlevnad av rättsliga krav och kontrollvalidering – inte blind acceptans.
Mappning av EUCS mot ISO 27001, NIS2, DORA och GDPR
EUCS blir revisionsklart när certifikatfakta mappas mot skyldigheter. En informationssäkerhetschef bör bygga en molnförsäkransmatris för korsvis efterlevnad som översätter leverantörsunderlag till återanvändbart kontrollunderlag.
| EUCS-underlag | Relevans för ISO 27001 och ISO 27002 | Relevans för NIS2 | Relevans för DORA | Relevans för GDPR |
|---|---|---|---|---|
| Certifikatets omfattning och omfattade tjänster | Stödjer leverantörsriskbedömning och kontrollerna 5.19, 5.20, 5.22 och 5.23 | Stödjer säkerhet i leveranskedjan och certifieringsunderlag | Stödjer leverantörsgranskning av IKT-leverantörer och korrekt registerföring | Stödjer bedömning av personuppgiftsbiträden och underbiträden |
| Assuransnivå och bedömningsmetod | Stödjer kontrollvalidering och motivering i SoA | Visar proportionalitet i förhållande till risk och tjänstens kritikalitet | Stödjer bedömning av kritiska eller viktiga funktioner | Stödjer ansvarsskyldighet för driftade personuppgifter |
| Underlag för datalagringsplats och jurisdiktion | Stödjer mappning av rättsliga, regulatoriska och avtalsmässiga krav | Stödjer tjänstekontinuitet och riskanalys för leveranskedjan | Stödjer bedömning av koncentrationsrisk och underleverantörsrisk | Stödjer analys av datalagringsplats och överföringsrisk |
| Åtaganden om incidentavisering | Stödjer incidentplanering och kontroller i leverantörsavtal | Stödjer beredskap för rapportering av betydande incidenter | Stödjer beroenden i rapportering av allvarliga IKT-incidenter | Stödjer beredskap för hantering av personuppgiftsincidenter |
| Underlag om underleverantörer och leveranskedja | Stödjer leverantörsövervakning och ändringshantering | Stödjer leverantörsspecifik sårbarhetsbedömning | Stödjer analys av underleverantörskedja och koncentrationsrisk | Stödjer ansvarsskyldighet i biträdeskedjan |
| Underlag för exit och återlämning av data | Stödjer kontinuitet, avslut och säker datahantering | Stödjer resiliens och kontinuitet för alla typer av störningar | Stödjer testade exitstrategier för kritiska IKT-tjänster | Stödjer underlag för radering, databevarande och begränsning av behandling |
Den här tabellen är inte bara till för dokumentation av regelefterlevnad. Den är bryggan mellan leverantörens säkerhetsförsäkran och organisationens ansvarsskyldighet.
NIS2 frågar om entiteten har vidtagit lämpliga och proportionerliga åtgärder. DORA frågar om den finansiella entiteten styr IKT-tredjepartsrisk genom leverantörsgranskning, avtal, övervakning och exitplanering. GDPR frågar om behandlingen av personuppgifter är laglig, säker och möjlig att visa. ISO/IEC 27001:2022 frågar om allt detta är integrerat i ett riskbaserat ledningssystem.
Ett praktiskt exempel: granskning av EUCS för en leverantör av molnbaserad analys
Återgå till Amelias fintechbolag, Northstar Pay. Företaget vill införa en molnbaserad analysplattform för bedrägeridetektering och transaktionsrapportering. Leverantören presenterar ett EUCS-certifikat och hävdar att det bör uppfylla säkerhetsgranskningen.
Clarysec skulle strukturera granskningen av underlaget i sex steg.
Steg 1: Uppdatera registret över molntjänster
Policy för användning av molntjänster - SME, avsnittet Styrningskrav, punkt 5.3, kräver ett register som dokumenterar molntjänstens namn, syfte, ansvarig ägare, datatyper, land eller region, åtkomstbehörigheter, administrativa konton, avtalsdetaljer, förnyelsedatum och supportkontakter.
För större organisationer börjar Policy för användning av molntjänster, avsnittet Styrningskrav, punkt 5.1, med ägarskap:
Organisationen ska underhålla ett centraliserat register över molntjänster, ägt av CISO, som innehåller:
Northstar Pay registrerar tjänsten före godkännande, inte efter produktionssättning.
| Registerfält | Exempelpost |
|---|---|
| Molntjänst | Leverantörens analysplattform |
| Verksamhetssyfte | Bedrägerianalys och rapportering av transaktionstrender |
| Applikationsägare | Chef för dataplattformar |
| Datatyper | Kundidentifierare, transaktionsmetadata, pseudonymiserade analyshändelser |
| Datalagringsplats | Endast EU-region, avtalsmässigt begränsad |
| Åtkomst | SSO, MFA, namngivna administratörskonton, roller enligt principen om minsta privilegium |
| Underlag | EUCS-certifikat, ISO 27001-certifikat, säkerhetsbeskrivning, personuppgiftsbiträdesavtal, avtal, lista över underbiträden |
| Granskningsdatum | Årlig granskning samt granskning vid väsentlig tjänsteändring |
Steg 2: Validera certifikatets omfattning
Teamet verifierar om EUCS-certifikatet omfattar exakt den analystjänst, driftsättningsmodell, region och juridiska person som Northstar Pay kommer att använda. Om certifikatet omfattar infrastrukturtjänster men utesluter analysmodulen är underlagets värde begränsat.
Det är här många revisioner fallerar. Leverantören säger ”certifierad”, men kunden kan inte visa att certifikatet gäller den tjänst som behandlar reglerade data.
Steg 3: Mappa EUCS mot riskbehandling och SoA
Med hjälp av Zenith Blueprint, steg 13, mappar Northstar Pay certifikatet in i riskregistret och tillämpbarhetsförklaringen.
| Riskscenario | Värde av EUCS-underlag | Kundsidans kontroll som fortfarande krävs |
|---|---|---|
| Obehörig åtkomst till analysdata | Stödjer säkerhetsförsäkran för leverantörens infrastruktur | Kräv SSO, MFA, RBAC, administratörsgranskning och loggning |
| Data lagras utanför godkänd region | Kan stödja leverantörens platskontroller | Avtalsmässig lagring endast inom EU, tenantkonfiguration och periodisk verifiering |
| Leverantörsincident fördröjer rapportering | Kan stödja säkerhetsförsäkran för incidentprocess | Avtalsmässiga aviseringstider, eskaleringskontakter och incidenthanteringsplan |
| Ändring av underbiträde påverkar risk | Kan stödja styrning av leveranskedjan | Avtalsenliga godkännanderättigheter, övervakning av underbiträden och omprövning |
| Molnavbrott påverkar rapportering | Kan stödja tillgänglighetskontroller | Plan för verksamhetskontinuitet, RTO- och RPO-analys, strategi för säkerhetskopiering eller export |
SoA registrerar därefter ISO/IEC 27002:2022-kontrollerna 5.20, 5.22 och 5.23 som tillämpliga eftersom organisationen använder molntjänster för reglerad behandling och viktiga analysarbetsflöden.
Steg 4: Bekräfta avtalsklausuler och revisionsrätt
SME-versionen av Policy för leverantörssäkerhet och tredjepartssäkerhet - SME, avsnittet Styrningskrav, punkt 5.3, kräver obligatoriska avtalsklausuler:
Avtal ska innehålla obligatoriska klausuler som omfattar: 5.3.1 Konfidentialitet och sekretess 5.3.2 Informationssäkerhetsskyldigheter 5.3.3 Tidsfrister 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 anlitande av underleverantörer utan godkännande 5.3.6 Villkor för uppsägning, inklusive säker återlämning eller förstöring av data
EUCS-underlag och avtalsenliga rättigheter fyller olika syften. Certifikatet stödjer säkerhetsförsäkran. Avtalet skapar villkor som kan göras gällande.
Enterprise-versionen av Policy för leverantörssäkerhet och tredjepartssäkerhet, avsnittet Krav för genomförande av policyn, punkt 6.1.2.2, inkluderar uttryckligen:
Granskning av revisionsrapporter (t.ex. SOC 2, ISO 27001, ISAE 3402)
EUCS hör hemma i denna underlagsfamilj, tillsammans med andra rapporter om säkerhetsförsäkran. Det bör inte ersätta avtalsgranskning, revisionsrätt, incidentstöd eller exitstrategiklausuler som krävs enligt DORA.
Steg 5: Genomdriv datalagringsplats för reglerade data
Policy för användning av molntjänster, avsnittet Krav för genomförande av policyn, punkt 6.6.2, anger:
Krav på datalagringsplats ska genomdrivas avtalsmässigt (t.ex. lagring endast inom EU för data som omfattas av GDPR).
För ansvarsskyldighet enligt GDPR är ett certifikat som beskriver regionala kontroller användbart. Det räcker fortfarande inte. Northstar Pay behöver personuppgiftsbiträdesavtalet, avtalsformulering om lagring endast inom EU, underlag för tenantkonfiguration och en metod för att övervaka förändring.
Om analysplattformen tillåter administratörer att välja regioner bör revisionsakten innehålla skärmbilder av konfiguration, exporterade inställningar eller andra registreringar som visar den godkända EU-regionen.
Steg 6: Schemalägg årliga och händelsestyrda granskningar
Policy för leverantörssäkerhet och tredjepartssäkerhet - SME, avsnittet Krav för genomförande av policyn, punkt 6.3.1, kräver årlig granskning av kritiska leverantörer eller högriskleverantörer för att verifiera säkra åtkomstmetoder, giltiga säkerhetscertifieringar eller uppdaterat kontrollunderlag, incidenthistorik och avtalsefterlevnad.
Granskningen bör också utlösas när leverantören ändrar underleverantörer, regioner, tjänster, identitetsarkitektur, krypteringsmodell, incidenthistorik eller certifikatstatus. Underlag för säkerhetsförsäkran åldras, och leverantörsrisk är inte statisk.
Clarysecs EUCS-underlagspaket
Ett moget EUCS-försäkringspaket innehåller mer än certifikat-PDF:en. Clarysec strukturerar underlaget i sju avsnitt.
| Underlagsavsnitt | Innehåll | Varför det är viktigt |
|---|---|---|
| 1. Molngodkännande | Verksamhetsmässig motivering, ägare, riskklassning, godkännandebeslut | Visar kontrollerad anskaffning och användning av molntjänster |
| 2. Leverantörsförsäkran | EUCS-certifikat, andra certifieringar, säkerhetsöversikt, modell för delat ansvar | Visar leverantörens säkerhetsunderlag och omfattning |
| 3. Juridik och integritet | Personuppgiftsbiträdesavtal, villkor för datalagringsplats, lista över underbiträden, mappning av behandling med rättslig grund | Stödjer ansvarsskyldighet enligt GDPR och avtalskrav |
| 4. Teknisk konfiguration | MFA, SSO, RBAC, kryptering, loggning, säkerhetskopiering, nätverksbegränsningar | Visar kundens del av det delade ansvaret |
| 5. Leverantörsavtal | Säkerhetsförpliktelser, rätt till revisionsunderlag, incidentavisering, underleverantörer, uppsägning | Stödjer leverantörsstyrning enligt ISO, NIS2 och DORA |
| 6. Incident och resiliens | Leverantörens eskaleringsväg, integrering i incidenthanteringsplan, RTO och RPO, testregistreringar | Stödjer NIS2-rapportering och DORA-operativ resiliens |
| 7. Övervakning och granskning | Årlig granskning, certifikatgiltighet, incidenter, tjänsteändringar, undantag | Stödjer löpande leverantörsövervakning och ständig förbättring |
Policy för rättslig och regulatorisk efterlevnad, avsnittet Krav för genomförande av policyn, punkt 6.2.1, fångar den operativa principen:
Alla rättsliga och regulatoriska skyldigheter ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet.
Det är skillnaden mellan att samla certifikat och att bygga en försvarbar operativ modell för regelefterlevnad.
Incident- och resiliensunderlag: där EUCS inte räcker
NIS2 och DORA gör båda incident- och resiliensberedskap till ett skarpt test av molnstyrning.
En molnleverantörs EUCS-certifikat kan visa att leverantören har kontroller för incidenthantering. Organisationen måste fortfarande veta vem som tar emot aviseringar, hur larm triageras, hur bevismaterial bevaras, hur påverkan på personuppgifter bedöms och vem som kommunicerar med tillsynsmyndigheter, kunder och intern ledning.
För NIS2 måste leverantörens aviseringsvillkor stödja skyldigheter för tidig varning och incidentanmälan. För DORA måste molnrelaterade incidenter flöda in i klassificering, eskalering, rapportering och kundkommunikation för IKT-relaterade incidenter. För GDPR måste arbetsflödet för personuppgiftsincidenter stödja bedömningen av om en personuppgiftsincident har inträffat och om anmälan till tillsynsmyndighet eller berörda personer krävs.
NIST CSF 2.0 är användbart som integrationsspråk här. Dess funktioner GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER hjälper organisationer att översätta rättsliga skyldigheter och tekniska kontroller till operativa resultat. Dess resultat för leveranskedjan kräver att leverantörer är kända, prioriterade, avtalsmässigt styrda, övervakade, inkluderade i incidentplanering och hanterade vid avslut. Dess resultat för respons och återställning omfattar triagering, eskalering, samordning med tredje part, underrättelse till intressenter, genomförande av återställning och verifiering av återställning.
Certifikatet läggs i akten. Incidenthanteringsplanen visar beredskap.
Hur revisorer kommer att testa EUCS-underlag
Olika revisorer angriper molnförsäkran från olika vinklar. En underlagsmodell för korsvis efterlevnad hindrar att samma fakta måste återskapas inför varje granskning.
| Revisionsperspektiv | Vad revisorn kommer att fokusera på | Underlag som förväntas |
|---|---|---|
| ISO 27001-revisor | ISMS-omfattning, riskbedömning, SoA, leverantörskontroller, molnstyrning, ständig förbättring | Register över molntjänster, riskregister, SoA, leverantörsbedömning, avtal, konfigurationsregistreringar, granskningsunderlag |
| NIS2-tillsynsmyndighet eller bedömare | Ledningens godkännande, Article 21-åtgärder, säkerhet i leveranskedjan, beredskap för incidentrapportering | Styrelserapportering, leverantörsriskanalys, incidenthanteringsplan, underlag för verksamhetskontinuitet, notifieringsarbetsflöde |
| DORA-revisor | IKT-tredjepartsregister, bedömning av kritisk eller viktig funktion, avtal, revisionsrätt, exitplaner, resiliensprovning | IKT-avtalsregister, leverantörsgranskning, analys av koncentrationsrisk, Article 30-avtalsklausuler, testregistreringar, exitstrategi |
| GDPR-granskare | Ansvarsskyldighet, behandlingsändamål, datakategorier, datalagringsplats, säkerhet, beredskap för personuppgiftsincidenter | RoPA-indata, personuppgiftsbiträdesavtal, villkor för datalagringsplats, åtkomstkontroller, arbetsflöde för bedömning av personuppgiftsincident, biträdesunderlag |
| NIST CSF-bedömare | Current and Target Profiles, styrning, riskhantering i leveranskedjan, övervakning, respons och återställning | Profilbaserad gap-analys, registreringar över leverantörslivscykel, övervakningsrapporter, incidentövningar, validering av återställning |
| COBIT 2019- eller ISACA-revisor | Styrningsmål, ledningens ansvarsskyldighet, tillsyn över tjänsteleverantörer, riskoptimering, övervakning av efterlevnad | Styrningsprotokoll, kontrollägarskap, prestandamått, poster över tredjepartstillsyn, efterlevnadspanel |
Zenith Blueprint, fasen Kontroller i praktiken, steg 23, varnar för att molnkontroller granskas noggrant:
Denna kontroll granskas ofta mycket noggrant. Revisorer kommer att fråga:
✓ ”Vilka molntjänster använder ni?” ✓ ”Vem godkände dem?” ✓ ”Hur säkerställer ni att data skyddas?”
Dessa frågor är kärnan i EUCS-försäkran. Ett certifikat kan hjälpa till att besvara hur skydd på leverantörssidan är styrkt, men det kan inte besvara vilka tjänster som används eller vem som godkände dem om registret över molntjänster och godkännandearbetsflödet inte är aktuella.
Vanliga misstag i EUCS-försäkran att undvika
Det första misstaget är att behandla EUCS som ett universellt frikort. Det är underlag med en avgränsad omfattning. Om certifikatet inte omfattar den köpta tjänsten, regionen, driftsättningsmodellen eller juridiska personen kan dess värde som säkerhetsförsäkran vara begränsat.
Det andra misstaget är att blanda ihop leverantörskontroller med kundkontroller. Leverantörscertifiering visar inte MFA i kundens tenant, RBAC, loggning, krypteringsinställningar, säkerhetskopior, granskning av administrativ åtkomst eller övervakning.
Det tredje misstaget är att förbise DORA:s avtalskrav. Finansiella entiteter behöver skriftliga rättigheter och skyldigheter, inklusive tjänstebeskrivningar, datalagringsplatser, informationssäkerhetskrav, åtkomst- och revisionsrätt, servicenivåer, incidentstöd, samarbete med myndigheter, rätt att säga upp avtalet och exitstrategier för kritiska eller viktiga funktioner.
Det fjärde misstaget är att ignorera GDPR-underlag. Formuleringar om datalagringsplats, insyn i underbiträden, hantering av personuppgiftsincidenter, behandling med rättslig grund och register över ansvarsskyldighet är fortfarande nödvändiga. EUCS kan stödja säkerhetsunderlag enligt Article 32, men det definierar inte organisationens rättsliga grund, behandlingsändamål eller regler för bevarande.
Det femte misstaget är att inte övervaka certifikatstatus. Om certifieringen löper ut, omfattningen ändras, iakttagelser från uppföljande revision uppstår eller leverantören ändrar arkitektur måste leverantörsriskgranskningen fånga upp förändringen.
En praktisk checklista för EUCS-granskning 2026
Använd denna checklista innan EUCS godtas som underlag för säkerhetsförsäkran från molnleverantör:
- Bekräfta certifieringssystem, assuransnivå, certifikatinnehavare och giltighetstid.
- Bekräfta exakta tjänster, regioner, driftsättningsmodeller och juridiska personer inom omfattningen.
- Jämför certifikatets omfattning med posten i organisationens register över molntjänster.
- Mappa underlag till ISO/IEC 27002:2022-kontrollerna 5.20, 5.22 och 5.23.
- Uppdatera riskregistret och SoA med certifikatunderlag och kvarstående risk.
- Validera kundsidans kontroller, särskilt identitet, MFA, loggning, kryptering, säkerhetskopiering och administratörsåtkomst.
- Bekräfta klausuler om datalagringsplats, underbiträden, incidentanmälan, revisionsunderlag och uppsägning.
- Koppla vägar för incidentavisering till tidslinjer enligt NIS2, DORA och GDPR.
- Granska koncentrationsrisk och exitstrategi för kritiska eller viktiga tjänster.
- Schemalägg årlig granskning och händelsestyrd omprövning.
Få EUCS-underlag att fungera i organisationens ISMS
EUCS-certifiering av molntjänster kan påtagligt förbättra säkerhetsförsäkran från molnleverantörer under 2026. Den kan minska frågeformulärströtthet, stärka leverantörsgranskning och stödja underlag för ISO 27001, NIS2, DORA och GDPR. Men den blir försvarbar först när den mappas in i organisationens styrningssystem.
Clarysec hjälper organisationer att omsätta certifieringsunderlag för molntjänster till revisionsklara efterlevnadsprocesser genom Zenith Blueprint, Zenith Controls, Policy för användning av molntjänster, Policy för användning av molntjänster - SME, Policy för leverantörssäkerhet och tredjepartssäkerhet - SME, Policy för leverantörssäkerhet och tredjepartssäkerhet och Policy för rättslig och regulatorisk efterlevnad.
Om organisationens färdplan för 2026 omfattar EUCS, NIS2-beredskap, DORA-relaterad IKT-tredjepartsrisk, GDPR-behandling i molntjänster eller ISO/IEC 27001:2022-certifiering, börja med en praktisk åtgärd: bygg registret över molntjänster, bifoga underlag för säkerhetsförsäkran från leverantörer och mappa varje kritisk molntjänst till risker, avtal, kontroller och ägare. Det är där molnförsäkran blir försvarbar.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
