Matrix for delt ansvar i cloud for ISO, NIS2 og DORA

En COO i en fintech-virksomhed ringer til CISO’en kl. 07:15 en mandag.

En europæisk bankkunde beder om dokumentation for, at virksomhedens SaaS-platform kan opfylde DORA-kravene til IKT-tredjepartsrisiko. Salgsteamet har allerede sendt den velkendte leverandørsikkerhedspakke: ISO-certifikat, ledelsesresumé fra penetrationstest, cyberforsikringscertifikat, privatlivsmeddelelse og en assurance-rapport fra cloududbyderen.

Banken vender tilbage med et mere præcist spørgsmål:

“Vis os, hvem der ejer hver kontrol i jeres cloudmiljø. Jer, jeres cloududbyder, jeres udbyder af administrerede databaser, jeres identitetsudbyder, jeres logningsleverandør og eventuelle underdatabehandlere. Vis derefter bevismaterialet.”

Senere samme formiddag har CISO’en et bestyrelsesmøde. CEO’en vil stille det samme spørgsmål i forretningsmæssigt sprog: “Er vi sikre på, at denne platform er sikker, og hvem har ansvaret, hvis noget går galt?”

Det er her, mange cloud-complianceprogrammer går i stå.

Organisationen kan have en stærk cloududbyder, gode værktøjer, fornuftige politikker og et risikoregister. Men når den bliver bedt om at dokumentere ansvarsgrænser, er bevismaterialet spredt. Indkøb har kontrakterne. Jura har databehandleraftalen. Engineering har arkitekturdiagrammerne. Sikkerhed har logfiler og cloudkonfigurationer. Privacy-funktionen har listen over underdatabehandlere. Compliance har anvendelighedserklæringen. Ingen har ét kontrolleret artefakt, der kontrol for kontrol angiver, hvad udbyderen gør, hvad kunden skal konfigurere, hvilken underdatabehandler der er involveret, hvilken klausul der gør forpligtelsen bindende, og hvilket bevismateriale en revisor bør forvente.

Dette artefakt er matrixen for delt ansvar i cloud.

Ikke den generiske hyperscaler-slide, der siger, at udbyderen sikrer cloudmiljøet, og kunden sikrer det, der ligger i cloudmiljøet. En reel matrix for delt ansvar i cloud for ISO/IEC 27001:2022, NIS2, DORA og GDPR er en styringsregistrering. Den kan modstå kunders due diligence, en ISO-revision, en DORA-gennemgang, en GDPR-ansvarlighedsvurdering og en hændelsesundersøgelse.

Hvorfor delt ansvar i cloud bliver et revisionsproblem

Modellen for delt ansvar beskrives normalt som en teknisk grænse. I IaaS administrerer udbyderen fysiske faciliteter, hardware, virtualisering og kerneinfrastruktur. Kunden administrerer identiteter, data, workloads, netværksregler, valg af kryptering og konfigurationer. I SaaS påtager udbyderen sig et større driftsansvar, men kunden ejer stadig brugeradgang, datagovernance, behandlingsgrundlag, konfiguration, forventninger til overvågning og eskalering af hændelser.

Den forklaring er nyttig, men utilstrækkelig.

Revisorer, tilsynsmyndigheder og erhvervskunder spørger om mere end “hvem driver kontrollen?” De vil vide:

• Hvem er ansvarlig for risikoen?
• Hvilken kontraktklausul gør denne ansvarlighed bindende?
• Hvilken politik kræver kontrollen?
• Hvilken cloudtjeneste, SaaS-platform eller underdatabehandler er omfattet?
• Hvilket bevismateriale dokumenterer, at kontrollen fungerede i gennemgangsperioden?
• Hvilket krav i rammeværket opfylder bevismaterialet?
• Hvad sker der, hvis udbyderen ændrer sin tjeneste, lokation, underleverandør eller kontroltilstand?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 gør dette til et spørgsmål om ledelsessystemet. Klausul 4.1 til 4.4 kræver, at organisationen forstår interne og eksterne forhold, interessenter, retlige og kontraktlige forpligtelser, ISMS-omfang, grænseflader og afhængigheder. Klausul 6.1.1 til 6.1.3 kræver risikovurdering, risikobehandling, godkendelse fra risikoejer, accept af restrisiko og en anvendelighedserklæring. Klausul 8.1 kræver operationel planlægning og styring, herunder styring af eksternt leverede processer, produkter og tjenester, der er relevante for ISMS.

Sagt enkelt: Hvis en cloududbyder, SaaS-leverandør eller underdatabehandler understøtter en forretningsproces inden for omfanget, kan den ikke placeres uden for ISMS. Den skal være synlig i omfang, risiko, behandling, kontraktlig kontrol og bevismateriale.

NIS2 skærper kravene. Article 21 kræver, at væsentlige og vigtige enheder implementerer passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, håndtering af hændelser, kontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, sikker udvikling, håndtering af sårbarheder, vurdering af effektivitet, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver og multifaktorgodkendelse eller løbende autentifikation, hvor det er relevant. Article 20 placerer styringsansvaret hos ledelsesorganerne.

DORA er endnu mere eksplicit for finansielle enheder. Den finder anvendelse fra 17. januar 2025 og kræver, at finansielle enheder styrer IKT-risiko, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed og IKT-tredjepartsrisiko. Article 28 til 30 kræver styring af IKT-tredjepartsrisiko, forudgående vurdering af koncentrationsrisiko, kontraktlige sikkerhedsforanstaltninger, revisions- og adgangsrettigheder, synlighed over underleverandører, opsigelsesrettigheder og exitstrategier.

GDPR tilføjer ansvarlighedstesten. Article 5 kræver, at personoplysninger behandles med integritet og fortrolighed, og Article 5(2) kræver, at den dataansvarlige skal kunne dokumentere efterlevelse. Article 28 regulerer databehandleraftaler og underdatabehandlere. Article 32 kræver behandlingssikkerhed. Article 33 og 34 kræver anmeldelse og underretning ved brud på persondatasikkerheden, hvor det er relevant.

Matrixen for delt ansvar i cloud bliver forbindelsen mellem disse forpligtelser.

Clarysecs definition: et styringsartefakt, ikke et diagram

I Clarysec-opgaver er en matrix for delt ansvar i cloud en kontrolleret ISMS-registrering, der kobler cloudtjenester, leverandører, underdatabehandlere, kontroller, politikker, kontraktlige forpligtelser, bevismateriale og revisionsforventninger.

Den tydeligste forklaring findes i Zenith Blueprint Zenith Blueprint, i fasen Controls in Action, trin 23:

“Cloududbydere sikrer infrastrukturen, men I er fortsat ansvarlige for jeres data, jeres konfigurationer, jeres adgangspolitikker og jeres beredskab til hændelseshåndtering.”

Det samme trin forklarer, at brug af cloud skal behandles som en del af ISMS, herunder klassificering af cloudtjenester, forståelse af data, der behandles eller opbevares, udbydervurdering, kontraktlige klausuler og styring af serviceændringer. Det omdanner delt ansvar fra et begreb til en sporbar kontrolstruktur.

Zenith Controls Zenith Controls behandler ISO/IEC 27001:2022 Annex A-kontroller og ISO/IEC 27002:2022-vejledning 5.20, 5.21 og 5.23 som centrale ankre:

• 5.20, Håndtering af informationssikkerhed i leverandøraftaler.
• 5.21, Styring af informationssikkerhed i IKT-forsyningskæden.
• 5.23, Informationssikkerhed ved brug af cloudtjenester.

Dette er ikke isolerede tjeklistepunkter. De definerer matrixens rygrad.

Supplerende standarder kan styrke matrixen. ISO/IEC 27017 understøtter cloudspecifik sikkerhedspraksis. ISO/IEC 27018 og ISO/IEC 27701 understøtter PII og privatlivsstyring. ISO/IEC 27005 understøtter risikovurdering. ISO 22301 understøtter forretningskontinuitet og robusthed. ISO/IEC 27035 understøtter hændelsesstyring. ISO/IEC 20000-1 kan hjælpe, hvor cloudtjenester er en del af administreret servicelevering.

Den mindst mulige brugbare matrix for delt ansvar

En moden matrix starter ikke med 200 rækker. Den starter med de cloudtjenester, der har størst betydning.

For en SaaS-virksomhed, fintech-virksomhed eller reguleret SMV begynder Clarysec normalt med:

1. Kundevendt cloudmiljø til produktion.
2. Identitetsudbyder.
3. Administreret database- eller lagringstjeneste.
4. Lognings-, overvågnings- og SIEM-platform.
5. Betalings-, KYC-, analyse- eller kundesupport-SaaS.
6. Tjeneste til backup og katastrofeberedskab.
7. Managed service provider eller managed security service provider.
8. Underdatabehandlere, der tilgår, opbevarer eller behandler kundedata.

Den første matrix skal indeholde følgende kolonner.

En praktisk logningsrække kan se sådan ud.

Denne række er ikke kun dokumentation. Den fortæller sikkerhedsteamet, hvad der skal konfigureres, indkøb hvad der skal kontrolleres i kontrakten, privacy-funktionen hvilket dataflow der skal registreres, og revisorer hvilket bevismateriale de skal anmode om.

Politikgrundlag: at gøre matrixen til et bindende krav

En matrix for delt ansvar i cloud uden politisk forankring er blot et regneark. Clarysecs politikker gør den bindende.

For SMV’er kræver Politik for brug af cloudtjenester - SMV Politik for brug af cloudtjenester - SMV, afsnittet “Styringskrav”, klausul 5.3:

“Et register over cloudtjenester skal vedligeholdes af IT-leverandøren eller den daglige leder. Det skal registrere:”

Den samme SMV-politik, klausul 5.2.3, kobler cloudstyring til databeskyttelse og lokationsrisiko:

“Dataresidens og privatlivspraksis skal overholde gældende retlige krav (f.eks. GDPR)”

For enterprise-miljøer angiver Politik for brug af cloudtjenester Politik for brug af cloudtjenester, afsnittet “Styringskrav”, klausul 5.1:

“Organisationen skal vedligeholde et centralt register over cloudtjenester, ejet af CISO’en, der indeholder:”

Klausul 5.4 gør derefter cloudansvar kontraktligt bindende:

“Alle kontrakter med cloudleverandører (CSP’er) skal indeholde bindende bestemmelser om:”

Leverandørstyring udvider matrixen ud over den direkte udbyder. Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV, afsnittet “Styringskrav”, klausul 5.3.5 kræver:

“Begrænsninger for yderligere underleverandører uden godkendelse”

Den samme SMV-leverandørpolitik, afsnittet “Krav til implementering af politikken”, klausul 6.3.1 tilføjer periodisk gennemgang:

“Kritiske leverandører eller højrisikoleverandører skal gennemgås mindst årligt. Gennemgangen skal verificere:”

På enterprise-niveau angiver Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed, afsnittet “Styringskrav”, klausul 5.3:

“Kontrakter med leverandører skal omfatte:”

For personoplysninger kræver Databeskyttelses- og privatlivspolitik Databeskyttelses- og privatlivspolitik, afsnittet “Håndhævelse og efterlevelse”, klausul 8.5.1:

“Kontrakter med databehandlere skal indeholde:”

For synlighed over afhængigheder kræver Politik for risikostyring af leverandørafhængigheder Politik for risikostyring af leverandørafhængigheder, klausul 6.5.4:

“Brug af leverandørrelationen til at indhente opdateringer om underleverandører eller forsyningskædeafhængigheder ét niveau nedstrøms, hvor de kan påvirke os (hvis en kritisk softwareleverandør f.eks. er stærkt afhængig af et tredjepartsbibliotek, skal dette registreres).”

For logfiler giver Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV, afsnittet “Styringskrav”, klausul 5.5.1.3 et konkret kontraktligt krav:

“Kontrakter skal kræve, at udbydere opbevarer logfiler i mindst 12 måneder og giver adgang efter anmodning”

Tilsammen gør disse politikker matrixen til en påkrævet styringsregistrering, der understøtter leverandørgodkendelse, onboarding af cloudtjenester, ansvarlighed vedrørende databeskyttelse, årlig gennemgang og revisionsbevismateriale.

Kortlægning af matrixen på tværs af ISO/IEC 27001:2022, NIS2, DORA og GDPR

Den klassiske fejl er at oprette fire separate compliancearbejdsbøger. Én kontrol kan opfylde flere forpligtelser, hvis ansvar og bevismateriale er sporbare.

ISO/IEC 27001:2022 leverer ISMS-motoren: kontekst, interessenter, omfang, lederskab, risikobehandling, målsætninger, operationel styring, evaluering af performance og forbedring. Annex A leverer den praktiske kontrolstruktur.

NIS2 Article 21 kan naturligt kortlægges til den samme matrix gennem sikkerhed i forsyningskæden, håndtering af hændelser, kontinuitet, adgangsstyring, politik for styring af aktiver og sikker anskaffelse. Article 20 gør matrixen relevant for bestyrelsen, fordi ledelsesorganer skal godkende og føre tilsyn med foranstaltninger til styring af cybersikkerhedsrisici.

DORA gør matrixen til et værktøj til IKT-tredjepartsrisiko. Article 5, 6 og 8 kræver styring, dokumenteret styring af IKT-risiko og identifikation af aktiver, funktioner og afhængigheder. Article 17 til 19 kræver hændelsesdetektion, klassificering, eskalering, kommunikation og rapportering. Article 28 til 30 kræver styring af tredjepartsrisiko, analyse af koncentrationsrisiko, kontraktlige klausuler, kontroller for underleverandører, revisionsrettigheder, opsigelsesrettigheder og exitstrategier.

GDPR bidrager med perspektivet for personoplysninger. Hver række for en cloudtjeneste bør angive, om der behandles personoplysninger, om udbyderen er databehandler eller underdatabehandler, om datalokation er relevant, og hvilket kontraktligt bevismateriale eller hvilken databehandleraftale der findes.

NIST CSF 2.0 hjælper med at kommunikere den samme matrix i resultatsprog. GOVERN-funktionen adresserer organisatorisk kontekst, retlige og regulatoriske krav, afhængigheder, risikostyring, roller, politikker og tilsyn. GV.SC-resultater er særligt nyttige for leverandørers cyberrisiko, herunder leverandørroller, kritikalitet, kontraktlige krav, due diligence, overvågning, koordinering af hændelser og planlægning af afslutning.

COBIT 2019 tilføjer et assurance- og styringsperspektiv. Det spørger, om ansvarlighed, ledelsespraksis, ejerskab, overvågning og afhjælpning af forhold er gentagelige og dokumenterede.

Opbygning af matrixen fra register til bevismateriale

Forestil dig en SaaS-virksomhed, der bruger en hyperscale IaaS-platform, en administreret database, en tredjepartsidentitetsudbyder, en kundesupport-SaaS-platform og en ekstern SIEM. Implementeringsforløbet er ligetil.

Trin 1: Start med registeret over cloudtjenester

Brug Politik for brug af cloudtjenester eller Politik for brug af cloudtjenester - SMV som udløser. Registrér hver cloudtjeneste, ejer, formål, datakategorier, lokation, forretningsfunktion, leverandørniveau, kontraktejer og gennemgangsdato.

Hvis tjenesten opbevarer kunderegistre, autentifikationslogfiler eller supportsager, markeres den som relevant for databeskyttelse. Hvis den understøtter tilgængelighed i produktion, markeres den som driftskritisk. Hvis den understøtter en finansiel kundes kritiske eller vigtige funktion, markeres den som DORA-relevant.

Trin 2: Tilføj domæner for delt ansvar

For hver tjeneste defineres ansvaret på tværs af kernedomæner.

Trin 3: Kobl kontroller til risiko og anvendelighedserklæringen

Zenith Blueprint, fasen Risk Management, trin 13, forklarer kravet om sporbarhed:

“Krydshenvis til reguleringer: Hvis visse kontroller implementeres specifikt for at efterleve GDPR, NIS2 eller DORA, kan du notere det enten i risikoregisteret (som del af begrundelsen for risikokonsekvens) eller i SoA-noterne.”

For eksempel kan risikoen “uautoriseret adgang til kunders produktionsdata gennem fejlkonfiguration i cloud” kortlægges til adgangsstyring, brug af cloud, logning, kryptografi, sårbarhedsstyring og leverandøraftaler. SoA kan henvise til ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 og 8.24 med noter for GDPR Article 32, NIS2 Article 21 og DORA-styring af IKT-risiko, hvor det er relevant.

Trin 4: Tilknyt bevismateriale før revisionssæsonen

Bevismateriale skal indbygges i matrixen, ikke indsamles i panik.

Listen over bevismateriale omsætter ansvar til dokumentation. Den hjælper også kommercielle teams med hurtigere at besvare erhvervskunders due diligence, fordi de ikke kun kan vise certificeringer, men også kontrolejerskab og operationelt bevismateriale.

Underdatabehandlere: blindvinklen i de fleste matricer

Underdatabehandlere er dér, hvor delt ansvar bliver reel forsyningskæderisiko.

En SaaS-udbyder kan være jeres databehandler efter GDPR. Denne udbyder kan være afhængig af en cloududbyder, CDN, analysetjeneste, supportplatform, e-mailleveringstjeneste, administreret database, observability-udbyder og betalingsbehandler. Nogle kan tilgå personoplysninger. Nogle kan understøtte kritisk levering af tjenesten uden direkte at se data. Nogle kan befinde sig uden for EU. Nogle kan erstattes. Andre kan skabe koncentrationsrisiko.

DORA Article 29 kræver vurdering af koncentrationsrisiko for kritiske eller vigtige IKT-tjenester, herunder substitutionsmulighed, flere aftaler med samme eller forbundne udbydere, underleverandørkæder, underleverandører i tredjelande, insolvensret, begrænsninger for datagendannelse og håndhævelighed af Unionens databeskyttelsesregler. DORA Article 30 kræver kontraktlige bestemmelser om betingelser for underleverandører, lokationer, databehandling og -opbevaring, adgang og genopretning, hændelsesassistance, samarbejde med myndigheder, revisionsrettigheder, opsigelse og exit.

NIS2 Article 21 kræver tilsvarende sikkerhed i forsyningskæden for direkte leverandører og tjenesteudbydere samt hensyntagen til leverandørspecifikke sårbarheder, leverandørers cybersikkerhedspraksis og procedurer for sikker udvikling.

Derfor behandler Clarysec kortlægning af underdatabehandlere som en påkrævet udvidelse af leverandørstyring, ikke som en liste kun til brug for databeskyttelse. Underdatabehandlerregisteret bør vise, hvilken leverandør der bruger underdatabehandleren, hvilken tjeneste der afhænger af den, om der behandles personoplysninger, om den understøtter en kritisk funktion, behandlingsregion hvor relevant, kontraktlige krav om videreførelse, godkendelses- eller indsigelsesrettigheder, tilgængelig assurance, overvågningsmetode og exitmulighed.

Zenith Blueprint, fasen Controls in Action, trin 23 angiver:

“For hver kritisk leverandør skal det identificeres, om de anvender underleverandører (underdatabehandlere), som kan tilgå jeres data eller systemer. Dokumentér, hvordan jeres informationssikkerhedskrav videreføres til disse parter, enten gennem leverandørens kontraktvilkår eller jeres egne direkte klausuler.”

Det er det bevisniveau, revisorer forventer, når de spørger, om cloudansvar er kontrolleret nedstrøms.

Hvordan revisorer tester den samme matrix

En stærk matrix for delt ansvar i cloud kan modstå flere revisionsstile, fordi den er opbygget omkring ejerskab, bindende forpligtelser og bevismateriale.

Matrixen er ikke slutmålet. Den er kortet, som revisorer bruger til at teste, om styringssystemet er reelt.

En ISO-revisor kan vælge en cloudadgangsrisiko med højt konsekvensniveau og spore den fra risikoregister til SoA og videre til gennemgang af adgangsrettigheder, MFA-bevismateriale og overvågningsalarmer. En DORA-vurderingspart kan vælge en kritisk IKT-udbyder og bede om exittesten, analysen af underleverandører og kontraktlige revisionsrettigheder. En GDPR-gennemgang kan fokusere på sletning, dataresidens, underretning ved brud og gennemsigtighed om underdatabehandlere.

Almindelige fejlmønstre

De hyppigste fejl i delt ansvar er ikke eksotiske.

For det første baserer organisationer sig på udbyderens assurance-rapporter uden at kortlægge dem til kundens ansvar. En cloududbyder kan dokumentere fysisk sikring, infrastrukturens robusthed og platformskontroller, men ikke om jeres storage bucket var privat, IAM-roller fulgte mindst privilegieprincip, eller logfiler var aktiveret.

For det andet indeholder kontrakter generisk sikkerhedssprog, men ingen hændelsesfrister, rettigheder til adgang til logfiler, revisionsrettigheder, begrænsninger for underleverandører, bestemmelser om tilbagelevering af data eller støtte ved exit. Zenith Blueprint, fasen Controls in Action, trin 23 fremhæver typiske områder i leverandøraftaler såsom fortrolighed, adgangsstyring, tekniske og organisatoriske foranstaltninger, hændelsesfrister, revisionsret, kontroller for underleverandører og bestemmelser ved kontraktophør.

For det tredje er underdatabehandlere opført af hensyn til databeskyttelse, men ikke koblet til sikkerhed, kontinuitet eller koncentrationsrisiko. En nedstrøms observability- eller supportudbyder fremgår måske aldrig af risikoregisteret, selv om dens nedbrud eller brud kan påvirke leveringen af kundeservice.

For det fjerde siger SoA, at en kontrol er anvendelig, men ingen kan fremlægge operationelt bevismateriale. Cloudlogning kan være markeret som implementeret, men organisationen kan ikke dokumentere opbevaringsindstillinger, gennemgang af adgangsrettigheder, håndtering af alarmer eller udbyderens kontraktlige forpligtelser til adgang til logfiler.

For det femte afspejler hændelseshåndteringsplaner ikke afhængighed af udbydere. Hvis udbyderen varsler en platformshændelse, hvem vurderer så kundepåvirkningen? Hvem afgør, om underretning efter NIS2, DORA eller GDPR er påkrævet? Hvem kontakter berørte kunder? Hvad hvis rodårsagen ligger hos en underdatabehandler?

Ledelsesansvarlighed: hvorfor bestyrelsen bør interessere sig

NIS2 Article 20 kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager uddannelse. DORA Article 5 kræver, at ledelsesorganet definerer, godkender, fører tilsyn med og er ansvarligt for ordninger for styring af IKT-risiko, herunder politikker for IKT-tredjeparter, kontinuitets- og genopretningsplaner, revisionsplaner, træning og rapporteringskanaler.

Det ændrer matrixens formål. Den er ikke længere kun et sikkerhedsarbejdsark. Den bliver bevismateriale for, at ledelsen ved:

• Hvilke cloudtjenester der understøtter kritiske driftsaktiviteter.
• Hvilke tredjeparter og underdatabehandlere der er væsentlige.
• Hvilke forpligtelser der gælder efter kundekontrakter, GDPR, NIS2 og DORA.
• Hvilke ansvarsområder organisationen bevarer.
• Hvilke udbyderforpligtelser der er kontraktligt bindende.
• Hvilke mangler der kræver finansiering, afhjælpning eller risikoaccept.

For SMV’er er proportionalitet afgørende. En mindre enhed har ikke behov for et tungt bureaukrati, men den har stadig behov for dokumentation, overvågning, robuste systemer, detektion af IKT-risikokilder, identifikation af væsentlige tredjepartsafhængigheder, kontinuitetsforanstaltninger, test, erfaringer og periodisk gennemgang, hvor den er omfattet.

Matrixen er et af de mest effektive proportionale værktøjer, fordi den konsoliderer forpligtelser i stedet for at multiplicere dem.

Et 30-dages sprint, der gør jeres cloudmodel revisionsklar

Hvis I ikke kan svare på, hvem der ejer hver cloudkontrol, hvilket bevismateriale der dokumenterer den, og hvilken underdatabehandler der kan påvirke den, er jeres model for delt ansvar stadig et diagram, ikke et styringsartefakt.

Et praktisk 30-dages sprint ser sådan ud:

1. Opret eller opdater registeret over cloudtjenester ved hjælp af Politik for brug af cloudtjenester eller Politik for brug af cloudtjenester - SMV.
2. Identificér kritiske tjenester, behandling af personoplysninger, kundevendte systemer og DORA- eller NIS2-relevans.
3. Opbyg den første matrix omkring ISO/IEC 27001:2022 Annex A-kontrollerne 5.20, 5.21 og 5.23 ved hjælp af Zenith Controls.
4. Kobl hver række til risikoregisteret og anvendelighedserklæringen ved hjælp af trin 13 i Zenith Blueprint.
5. Validér leverandør- og databehandlerklausuler ved hjælp af Politik for tredjeparts- og leverandørsikkerhed, Politik for tredjeparts- og leverandørsikkerhed - SMV og Databeskyttelses- og privatlivspolitik.
6. Tilføj logopbevaring, eskalering af hændelser, godkendelse af underdatabehandlere, revisionsrettigheder og bevismateriale for exit.
7. Gennemgå kritiske leverandører årligt og efter større ændringer, hændelser, nye underdatabehandlere eller revisionskonstateringer.

Målet er enkelt. Når kunden, revisoren, tilsynsmyndigheden eller bestyrelsen spørger “hvem ejer denne kontrol?”, skal I ikke søge på tværs af kontrakter, sager og mapper. I åbner matrixen, viser ejeren, viser klausulen, viser bevismaterialet og viser sporet nedstrøms.

Clarysec kan hjælpe jer med at omsætte cloududbyderes assurance-pakker til en integreret matrix for delt ansvar for ISO/IEC 27001:2022-revisioner, NIS2-parathed, DORA IKT-tredjepartsrisiko, GDPR-ansvarlighed og due diligence fra erhvervskunder.

Start med registeret. Opbyg matrixen. Tilknyt bevismaterialet. Brug den derefter som jeres bestyrelsesklare dokumentation for, at cloudrisiko ikke er outsourcet; den er styret.