Matris för delat ansvar i molnmiljö för ISO 27001, NIS2 och DORA

En operativ chef på ett fintechbolag ringer informationssäkerhetschefen kl. 07.15 en måndag.

En europeisk bankkund begär underlag som visar att företagets SaaS-plattform kan uppfylla DORA:s krav på IKT-tredjepartsrisk. Säljteamet har redan skickat det vanliga leverantörssäkerhetspaketet: ISO-certifikat, en ledningssammanfattning av penetrationstest, cyberförsäkringsintyg, integritetsmeddelande och en försäkransrapport från molnleverantören.

Banken återkommer med en skarpare fråga:

”Visa oss vem som äger varje kontroll i er molnmiljö. Ni, er molnleverantör, er leverantör av hanterad databas, er identitetsleverantör, er loggningsleverantör och eventuella underbiträden. Visa därefter underlaget.”

Senare samma morgon har informationssäkerhetschefen styrelsemöte. Den verkställande direktören kommer att ställa samma fråga på verksamhetsspråk: ”Är vi säkra på att plattformen är säker, och vem ansvarar om något går fel?”

Det är här många program för efterlevnad i molnmiljö kör fast.

Organisationen kan ha en stark molnleverantör, bra verktyg, rimliga policyer och ett riskregister. Men när den ska visa ansvarsgränser är underlaget utspritt. Inköp har avtalen. Juridik har personuppgiftsbiträdesavtalet. Engineering har arkitekturdiagram. Säkerhet har loggar och molnkonfigurationer. Dataskydd har listan över underbiträden. Regelefterlevnad har tillämpbarhetsförklaringen. Ingen har en kontrollerad artefakt som, kontroll för kontroll, visar vad leverantören gör, vad kunden måste konfigurera, vilket underbiträde som berörs, vilken klausul som gör skyldigheten verkställbar och vilket underlag en revisor bör förvänta sig.

Den artefakten är matrisen för delat ansvar i molnmiljö.

Inte den generiska standardbilden från en hyperskalarleverantör som säger att leverantören säkrar molnet och kunden säkrar det som finns i molnet. En verklig matris för delat ansvar i molnmiljö för ISO/IEC 27001:2022, NIS2, DORA och GDPR är en styrningspost. Den håller för kunders leverantörsgranskning, en ISO-revision, en DORA-granskning, en prövning av ansvarsskyldighet enligt GDPR och en incidentutredning.

Varför delat ansvar i molnmiljö blir en revisionsfråga

Modellen för delat ansvar lärs ofta ut som en teknisk gränsdragning. I IaaS hanterar leverantören fysiska anläggningar, hårdvara, virtualisering och central infrastruktur. Kunden hanterar identiteter, data, arbetslaster, nätverksregler, krypteringsval och konfigurationer. I SaaS tar leverantören ett större operativt ansvar, men kunden äger fortfarande användaråtkomst, styrning av data, rättslig grund, konfiguration, förväntningar på övervakning och incidenteskalering.

Den förklaringen är användbar men ofullständig.

Revisorer, tillsynsmyndigheter och företagskunder frågar efter mer än ”vem driver kontrollen?”. De vill veta:

• Vem är ansvarsskyldig för risken?
• Vilken avtalsklausul gör denna ansvarsskyldighet verkställbar?
• Vilken policy kräver kontrollen?
• Vilken molntjänst, SaaS-plattform eller vilket underbiträde omfattas?
• Vilket underlag visar att kontrollen fungerade under granskningsperioden?
• Vilket krav i ramverket uppfyller underlaget?
• Vad händer om leverantören ändrar sin tjänst, plats, underleverantör eller kontrollnivå?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 gör detta till en fråga för ledningssystemet. Klausulerna 4.1 till 4.4 kräver att organisationen förstår interna och externa förhållanden, intressenter, rättsliga och avtalsmässiga skyldigheter, ISMS-omfattning, gränssnitt och beroenden. Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling, godkännande av riskägare, acceptans av resterisk och en tillämpbarhetsförklaring. Klausul 8.1 kräver operativ planering och styrning, inklusive styrning av externt tillhandahållna processer, produkter och tjänster som är relevanta för ISMS.

Med andra ord: om en molnleverantör, SaaS-leverantör eller ett underbiträde stödjer en verksamhetsprocess inom omfattningen kan det inte ligga utanför ISMS. Det måste vara synligt i omfattning, risk, behandling, avtalsstyrning och underlag.

NIS2 höjer kraven. Article 21 kräver att väsentliga och viktiga entiteter genomför lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, kontinuitet, säkerhet i leveranskedjan, säker anskaffning, säker utveckling, sårbarhetshantering, effektivitetsbedömning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, policy för tillgångshantering och flerfaktorsautentisering eller kontinuerlig autentisering där det är lämpligt. Article 20 lägger styrningsansvaret på ledningsorganen.

DORA är ännu tydligare för finansiella entiteter. Den gäller från den 17 januari 2025 och kräver att finansiella entiteter hanterar IKT-risk, rapportering av större IKT-relaterade incidenter, testning av digital operativ resiliens och IKT-tredjepartsrisk. Articles 28 to 30 kräver hantering av IKT-tredjepartsrisk, preliminär bedömning av koncentrationsrisk, avtalsmässiga skyddsåtgärder, revisionsrätt och åtkomsträttigheter, insyn i underleverantörskedjor, rätt att säga upp avtalet och exitstrategier.

GDPR tillför testet av ansvarsskyldighet. Article 5 kräver att personuppgifter behandlas med riktighet och konfidentialitet, och Article 5(2) kräver att den personuppgiftsansvarige ska kunna visa efterlevnad. Article 28 reglerar avtal med personuppgiftsbiträden och underbiträden. Article 32 kräver säkerhet i behandlingen. Articles 33 and 34 kräver anmälan av personuppgiftsincident där det är tillämpligt.

Matrisen för delat ansvar i molnmiljö blir bryggan mellan dessa skyldigheter.

Clarysecs definition: en styrningsartefakt, inte ett diagram

I Clarysec-uppdrag är en matris för delat ansvar i molnmiljö en kontrollerad ISMS-post som kopplar molntjänster, leverantörer, underbiträden, kontroller, policyer, avtalsförpliktelser, underlag och revisionsförväntningar.

Den tydligaste förklaringen finns i Zenith Blueprint Zenith Blueprint, i fasen Controls in Action, Step 23:

”Molnleverantörer säkrar infrastrukturen, men ni är fortfarande ansvarsskyldiga för era data, era konfigurationer, era åtkomstpolicyer och er beredskap för incidenthantering.”

Samma steg förklarar att användning av molntjänster måste behandlas som en del av ISMS, inklusive klassificering av molntjänster, förståelse för data som behandlas eller lagras, leverantörsutvärdering, avtalsklausuler och hantering av tjänsteförändringar. Det omvandlar delat ansvar från ett koncept till en spårbar kontrollstruktur.

Zenith Controls Zenith Controls behandlar kontroller i ISO/IEC 27001:2022 bilaga A och vägledningen i ISO/IEC 27002:2022, 5.20, 5.21 och 5.23, som centrala ankare:

• 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.

Detta är inte isolerade punkter i en checklista. De utgör matrisens ryggrad.

Stödjande standarder kan stärka matrisen. ISO/IEC 27017 hjälper med molnspecifik säkerhetspraxis. ISO/IEC 27018 och ISO/IEC 27701 stödjer styrning av PII och integritet. ISO/IEC 27005 stödjer riskbedömning. ISO 22301 stödjer kontinuitet och resiliens. ISO/IEC 27035 stödjer incidenthantering. ISO/IEC 20000-1 kan vara till hjälp när molntjänster ingår i hanterad tjänsteleverans.

Den minsta gångbara matrisen för delat ansvar

En mogen matris börjar inte med 200 rader. Den börjar med de molntjänster som är viktigast.

För SaaS, fintech eller reglerade små och medelstora företag börjar Clarysec normalt med:

1. Kundvänd produktionsmiljö i molnet.
2. Identitetsleverantör.
3. Hanterad databas eller lagringstjänst.
4. Plattform för loggning, övervakning och SIEM.
5. SaaS för betalning, KYC, analys eller kundsupport.
6. Tjänst för säkerhetskopiering och katastrofåterställning.
7. Hanterad tjänsteleverantör eller hanterad säkerhetstjänsteleverantör.
8. Underbiträden som får åtkomst till, lagrar eller behandlar kunddata.

Den första matrisen bör innehålla följande kolumner.

En praktisk loggningsrad kan se ut så här.

Den raden är inte bara dokumentation. Den talar om för säkerhet vad som ska konfigureras, för inköp vilket avtalsspråk som ska kontrolleras, för dataskydd vilket dataflöde som ska registreras och för revisorer vilket underlag de ska begära.

Policygrund: att göra matrisen till ett bindande krav

En matris för delat ansvar i molnmiljö utan policystöd är bara ett kalkylblad. Clarysecs policyer gör den verkställbar.

För små och medelstora företag kräver Policy för användning av molntjänster – SME Policy för användning av molntjänster – SME, avsnittet ”Styrningskrav”, klausul 5.3:

”Ett register över molntjänster ska underhållas av IT-leverantören eller vd. Det ska registrera:”

Samma SME-policy, klausul 5.2.3, kopplar molnstyrning till integritets- och platsrisk:

”Datalagringsplats och integritetspraxis uppfyller tillämpliga rättsliga krav (t.ex. GDPR)”

För företagsmiljöer anger Policy för användning av molntjänster Policy för användning av molntjänster, avsnittet ”Styrningskrav”, klausul 5.1:

”Organisationen ska upprätthålla ett centraliserat register över molntjänster, ägt av informationssäkerhetschefen, som innehåller:”

Klausul 5.4 gör därefter ansvar i molnmiljö avtalsmässigt bindande:

”Alla avtal med molntjänstleverantörer (CSP) ska innehålla verkställbara avtalsvillkor för:”

Leverantörsstyrning utvidgar matrisen bortom den direkta leverantören. Policy för leverantörssäkerhet och tredjepartssäkerhet – SME Policy för leverantörssäkerhet och tredjepartssäkerhet – SME, avsnittet ”Styrningskrav”, klausul 5.3.5 kräver:

”Begränsningar av vidare underleverantörer utan godkännande”

Samma SME-policy för leverantörssäkerhet, avsnittet ”Krav för genomförande av policyn”, klausul 6.3.1 lägger till periodisk granskning:

”Kritiska leverantörer eller leverantörer med hög risk ska granskas minst årligen. Granskningen ska verifiera:”

På företagsnivå anger Policy för leverantörssäkerhet och tredjepartssäkerhet Policy för leverantörssäkerhet och tredjepartssäkerhet, avsnittet ”Styrningskrav”, klausul 5.3:

”Avtal med leverantörer ska innehålla:”

För personuppgifter kräver Policy för dataskydd och integritet Policy för dataskydd och integritet, avsnittet ”Efterlevnad och tillämpning”, klausul 8.5.1:

”Avtal med personuppgiftsbiträden ska innehålla:”

För synlighet i beroenden kräver Policy för hantering av risker kopplade till leverantörsberoenden Policy för hantering av risker kopplade till leverantörsberoenden, klausul 6.5.4:

”Använd leverantörsrelationen för att få uppdateringar om underleverantörer eller beroenden i leveranskedjan ett led nedströms där de kan påverka oss (till exempel om en kritisk programvaruleverantör är starkt beroende av ett tredjepartsbibliotek ska detta registreras).”

För loggar tillhandahåller Loggnings- och övervakningspolicy – SME Loggnings- och övervakningspolicy – SME, avsnittet ”Styrningskrav”, klausul 5.5.1.3 ett konkret avtalskrav:

”Avtal ska kräva att leverantörer bevarar loggar i minst 12 månader och tillhandahåller åtkomst på begäran”

Tillsammans gör dessa policyer matrisen till en obligatorisk styrningspost som stödjer leverantörsgodkännande, införande av molntjänster, ansvarsskyldighet för integritet, årlig granskning och revisionsbevis.

Mappning av matrisen över ISO/IEC 27001:2022, NIS2, DORA och GDPR

Det klassiska misstaget är att skapa fyra separata arbetsböcker för regelefterlevnad. En kontroll kan uppfylla flera skyldigheter om ansvar och underlag är spårbara.

ISO/IEC 27001:2022 tillhandahåller ISMS-motorn: sammanhang, intressenter, omfattning, ledarskap, riskbehandling, mål, operativ styrning, prestationsutvärdering och förbättring. Bilaga A tillhandahåller den praktiska kontrollstrukturen.

NIS2 Article 21 mappar naturligt till samma matris genom säkerhet i leveranskedjan, incidenthantering, kontinuitet, åtkomstkontroll, policy för tillgångshantering och säker anskaffning. Article 20 gör matrisen relevant för styrelsen eftersom ledningsorganen ska godkänna och övervaka åtgärder för hantering av cybersäkerhetsrisk.

DORA gör matrisen till ett verktyg för IKT-tredjepartsrisk. Articles 5, 6 and 8 kräver styrning, dokumenterad IKT-riskhantering och identifiering av tillgångar, funktioner och beroenden. Articles 17 to 19 kräver incidentdetektering, klassificering, eskalering, kommunikation och rapportering. Articles 28 to 30 kräver tredjepartsriskhantering, analys av koncentrationsrisk, avtalsklausuler, kontroller för underleverantörer, revisionsrätt, rätt att säga upp avtalet och exitstrategier.

GDPR tillför personuppgiftsperspektivet. Varje rad för en molntjänst bör identifiera om personuppgifter behandlas, om leverantören är ett personuppgiftsbiträde eller underbiträde, om datalagringsplats är relevant och vilket avtals- eller personuppgiftsbiträdesunderlag som finns.

NIST CSF 2.0 hjälper till att kommunicera samma matris på resultatnivå. Funktionen GOVERN omfattar organisatoriskt sammanhang, rättsliga och regulatoriska krav, beroenden, riskhantering, roller, policyer och tillsyn. GV.SC-resultat är särskilt användbara för cyberrisk hos leverantörer, inklusive leverantörsroller, kritikalitet, avtalskrav, leverantörsgranskning, övervakning, incidentsamordning och planering för uppsägning.

COBIT 2019 tillför ett säkerhetsförsäkrings- och styrningsperspektiv. Det frågar om ansvarsskyldighet, ledningspraxis, ägarskap, övervakning och åtgärdande av avvikelser är repeterbara och styrkta med underlag.

Bygg matrisen från register till bevis

Föreställ dig ett SaaS-företag som använder en hyperskalig IaaS-plattform, en hanterad databas, en extern identitetsleverantör, en SaaS-plattform för kundsupport och en extern SIEM. Genomförandeflödet är tydligt.

Steg 1: Börja med registret över molntjänster

Använd Policy för användning av molntjänster eller Policy för användning av molntjänster – SME som utlösare. Registrera varje molntjänst, ägare, syfte, datakategorier, plats, verksamhetsfunktion, leverantörsnivå, avtalsägare och granskningsdatum.

Om tjänsten lagrar kundregister, autentiseringsloggar eller supportärenden ska den markeras som integritetsrelevant. Om den stödjer produktionstillgänglighet ska den markeras som operativt kritisk. Om den stödjer en finansiell kunds kritiska eller viktiga funktion ska den markeras som DORA-relevant.

Steg 2: Lägg till domäner för delat ansvar

Definiera ansvar för varje tjänst inom centrala domäner.

Steg 3: Koppla kontroller till risk och tillämpbarhetsförklaring

Zenith Blueprint, fasen Risk Management, Step 13, förklarar kravet på spårbarhet:

”Korsreferera regelverk: Om vissa kontroller genomförs specifikt för att uppfylla GDPR, NIS2 eller DORA kan du notera detta antingen i riskregistret (som en del av motiveringen för riskkonsekvens) eller i SoA-anteckningarna.”

Exempelvis kan risken ”obehörig åtkomst till kunders produktionsdata genom felkonfiguration i molnet” mappas till åtkomstkontroll, användning av molntjänster, loggning, kryptografi, hantering av sårbarheter och leverantörsavtal. SoA kan referera till ISO/IEC 27001:2022 bilaga A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 och 8.24, med anteckningar för GDPR Article 32, NIS2 Article 21 och DORA:s IKT-riskhantering där det är tillämpligt.

Steg 4: Bifoga underlag före revisionssäsongen

Underlag bör byggas in i matrisen, inte samlas in i panik.

Underlagslistan omvandlar ansvar till bevis. Den hjälper också kommersiella team att snabbare svara på företagskunders leverantörsgranskningar, eftersom de kan visa inte bara certifieringar utan även kontrollägarskap och operativt underlag.

Underbiträden: den blinda fläcken i de flesta matriser

Underbiträden är där delat ansvar blir verklig leveranskedjerisk.

En SaaS-leverantör kan vara ert personuppgiftsbiträde enligt GDPR. Den leverantören kan i sin tur förlita sig på en leverantör av molndrift, CDN, analystjänst, supportplattform, e-postleveranstjänst, hanterad databas, observabilitetsleverantör och betalningsförmedlare. Vissa kan få åtkomst till personuppgifter. Vissa kan stödja kritisk tjänsteleverans utan att direkt se data. Vissa kan finnas utanför EU. Vissa kan ersättas. Andra kan skapa koncentrationsrisk.

DORA Article 29 kräver bedömning av koncentrationsrisk för kritiska eller viktiga IKT-tjänster, inklusive utbytbarhet, flera arrangemang med samma eller närstående leverantörer, underleverantörskedjor, underleverantörer i tredjeland, insolvensrätt, begränsningar för dataåterställning och möjligheten att göra EU:s dataskydd gällande. DORA Article 30 kräver avtalsbestämmelser om villkor för underleverantörer, platser, databehandling och lagring, åtkomst och återställning, incidentstöd, samarbete med myndigheter, revisionsrätt, uppsägning och exit.

NIS2 Article 21 kräver på motsvarande sätt säkerhet i leveranskedjan för direkta leverantörer och tjänsteleverantörer, samt beaktande av leverantörsspecifika sårbarheter, leverantörers cybersäkerhetspraxis och rutiner för säker utveckling.

Därför behandlar Clarysec mappning av underbiträden som en obligatorisk utvidgning av leverantörsstyrningen, inte som enbart en integritetslista. Registret över underbiträden bör visa vilken leverantör som använder underbiträdet, vilken tjänst som är beroende av det, om personuppgifter behandlas, om det stödjer en kritisk funktion, behandlingsregion där det är relevant, vidareförda skyldigheter i avtal, rätt till godkännande eller invändning, tillgänglig säkerhetsförsäkran, övervakningsmetod och exitalternativ.

Zenith Blueprint, fasen Controls in Action, Step 23 anger:

”Identifiera för varje kritisk leverantör om de använder underleverantörer (underbiträden) som kan få åtkomst till era data eller system. Dokumentera hur era informationssäkerhetskrav förs vidare till dessa parter, antingen genom leverantörens avtalsvillkor eller genom era egna direkta klausuler.”

Det är den bevisnivå revisorer förväntar sig när de frågar om ansvar i molnmiljö kontrolleras nedströms.

Hur revisorer testar samma matris

En stark matris för delat ansvar i molnmiljö håller för flera revisionssätt eftersom den är byggd kring ägarskap, möjlighet att göra krav gällande och underlag.

Matrisen är inte slutmålet. Den är kartan som revisorer använder för att testa om styrningssystemet är verkligt.

En ISO-revisor kan välja en molnåtkomstrisk med hög påverkan och spåra den från riskregister till SoA, vidare till åtkomstgranskning, MFA-underlag och övervakningslarm. En DORA-bedömare kan välja en kritisk IKT-leverantör och begära exittest, analys av underleverantörer och avtalsmässig revisionsrätt. En GDPR-granskare kan fokusera på radering, datalagringsplats, incidentanmälan och transparens kring underbiträden.

Vanliga felmönster

De vanligaste bristerna i delat ansvar är inte exotiska.

För det första förlitar sig organisationer på leverantörers försäkransrapporter utan att mappa dem till kundens ansvar. En molnleverantör kan visa fysisk säkerhet, infrastrukturresiliens och plattformskontroller, men inte om er storage bucket var privat, om IAM-roller följde principen om minsta privilegium eller om loggar var aktiverade.

För det andra innehåller avtal generisk säkerhetstext men inga incidenttidslinjer, rätt till åtkomst till loggar, revisionsrätt, begränsningar för underleverantörer, bestämmelser om återlämning av data eller exitstöd. Zenith Blueprint, fasen Controls in Action, Step 23 lyfter typiska områden i leverantörsavtal såsom konfidentialitet, åtkomstkontroll, tekniska och organisatoriska åtgärder, incidenttidslinjer, revisionsrätt, kontroller av underleverantörer och bestämmelser vid avtalsslut.

För det tredje listas underbiträden för integritetsändamål men kopplas inte till säkerhet, kontinuitet eller koncentrationsrisk. En nedströms observabilitets- eller supportleverantör kanske aldrig förekommer i riskregistret trots att dess avbrott eller incident kan påverka leveransen av kundtjänster.

För det fjärde säger SoA att en kontroll är tillämplig, men ingen kan ta fram operativt underlag. Molnloggning kan vara markerad som genomförd, men organisationen kan inte visa inställningar för bevarande, åtkomstgranskning, larmhantering eller leverantörens åtaganden om åtkomst till loggar.

För det femte speglar incidenthanteringsplaner inte leverantörsberoenden. Om leverantören aviserar en plattformsincident, vem bedömer kundpåverkan? Vem avgör om avisering enligt NIS2, DORA eller GDPR krävs? Vem kontaktar berörda kunder? Vad händer om rotorsaken ligger hos ett underbiträde?

Ledningens ansvarsskyldighet: varför styrelsen bör bry sig

NIS2 Article 20 kräver att ledningsorgan godkänner åtgärder för hantering av cybersäkerhetsrisk, övervakar genomförandet och får utbildning. DORA Article 5 kräver att ledningsorganet definierar, godkänner, övervakar och ansvarar för arrangemang för IKT-riskhantering, inklusive IKT-tredjepartspolicyer, kontinuitets- och återställningsplaner, revisionsplaner, utbildning och rapporteringskanaler.

Det förändrar matrisens syfte. Den är inte längre bara ett säkerhetskalkylblad. Den blir underlag för att ledningen vet:

• Vilka molntjänster som stödjer kritiska operationer.
• Vilka tredje parter och underbiträden som är väsentliga.
• Vilka skyldigheter som gäller enligt kundavtal, GDPR, NIS2 och DORA.
• Vilka ansvar som behålls av organisationen.
• Vilka leverantörsåtaganden som kan göras gällande avtalsmässigt.
• Vilka luckor som kräver finansiering, avhjälpande åtgärder eller riskacceptans.

För små och medelstora företag är proportionalitet viktigt. En mindre entitet behöver inte en tung byråkrati, men den behöver fortfarande dokumentation, övervakning, resilienta system, detektering av källor till IKT-risk, identifiering av viktiga tredjepartsberoenden, kontinuitetsåtgärder, testning, erfarenhetsåterföring och periodisk granskning där det omfattas.

Matrisen är ett av de mest effektiva proportionerliga verktygen eftersom den konsoliderar skyldigheter i stället för att multiplicera dem.

En 30-dagars sprint för att göra er molnmodell revisionsklar

Om ni inte kan svara på vem som äger varje molnkontroll, vilket underlag som visar den och vilket underbiträde som kan påverka den, är er modell för delat ansvar fortfarande ett diagram, inte en styrningsartefakt.

En praktisk 30-dagars sprint ser ut så här:

1. Skapa eller uppdatera registret över molntjänster med hjälp av Policy för användning av molntjänster eller Policy för användning av molntjänster – SME.
2. Identifiera kritiska tjänster, behandling av personuppgifter, kundvända system och relevans för DORA eller NIS2.
3. Bygg den första matrisen kring ISO/IEC 27001:2022 bilaga A-kontrollerna 5.20, 5.21 och 5.23 med hjälp av Zenith Controls.
4. Koppla varje rad till riskregister och tillämpbarhetsförklaring med hjälp av Step 13 i Zenith Blueprint.
5. Validera leverantörs- och personuppgiftsbiträdesklausuler med hjälp av Policy för leverantörssäkerhet och tredjepartssäkerhet, Policy för leverantörssäkerhet och tredjepartssäkerhet – SME och Policy för dataskydd och integritet.
6. Lägg till underlag för logglagring, incidenteskalering, godkännande av underbiträden, revisionsrätt och exit.
7. Granska kritiska leverantörer årligen samt efter större ändringar, incidenter, nya underbiträden eller revisionsiakttagelser.

Målet är enkelt. När kunden, revisorn, tillsynsmyndigheten eller styrelsen frågar ”vem äger den här kontrollen?” ska ni inte söka i avtal, ärenden och mappar. Ni öppnar matrisen, visar ägaren, visar klausulen, visar underlaget och visar spåret nedströms.

Clarysec kan hjälpa er att omvandla försäkranspaket från molnleverantörer till en integrerad matris för delat ansvar för ISO/IEC 27001:2022-revisioner, NIS2-beredskap, DORA IKT-tredjepartsrisk, ansvarsskyldighet enligt GDPR och leverantörsgranskningar från företagskunder.

Börja med registret. Bygg matrisen. Bifoga underlaget. Använd den sedan som ert styrelseklara bevis på att molnrisk inte outsourcas – den styrs.