A.5.23 Cloudsikkerhed: Delt ansvar for MSP'er i henhold til ISO 27001

Hvorfor MSP Cloud Security brød sammen natten over

MSP-cloudsikkerhed "brød sammen", da cloudplatforme holdt op med at være simple leverandører og blev miljøer med delt ansvar, som du aktivt skal styre. ISO 27001 A.5.23 gør dette skift eksplicit ved at forvente, at du kontrollerer, hvordan du vælger, bruger og afslutter cloudtjenester i overensstemmelse med dit ISMS, i stedet for udelukkende at stole på udbydercertifikater. Denne forventning afspejler ordlyden i ISO 27001:2022 A.5.23 og mainstream cloudsikkerhedsvejledning, som understreger definerede processer for erhvervelse, brug, administration og afslutning af cloudtjenester i stedet for udelukkende at stole på udbydergarantier, som fremhævet i kommentarerne til ISO 27001 A.5.23-vejledningen.

Cloud-tjenester lader din MSP vokse hurtigt, men de har også afsløret huller i ejerskab, styring og beviser, som den gamle leverandørmodel aldrig behøvede at løse. Når kunder og revisorer nu spørger, hvem der er ansvarlig for hvad i skyen, er "udbyderen gør det" ikke længere nok. A.5.23 krystalliserer denne spænding ved at forvente en kontrolleret, dokumenteret tilgang til cloud-brug i stedet for ad hoc platformvalg.

Cloud bliver kun en fordel for MSP'er, når ansvaret deles bevidst og ikke påtages.

Cloud er vokset fra din gamle "leverandør"-tankegang

Cloud-løsninger er vokset fra ideen om, at man kan underskrive en kontrakt, stole på et certifikat og antage, at sikkerhedsstop er i udbyderens grænseområde. For MSP'er tvinger A.5.23 jer til at erkende, at identiteter, konfigurationer og daglig drift på hver platform nu ligger solidt inden for jeres ansvarsområder.

Mange MSP'er behandler stadig cloud-udbydere som traditionelle leverandører, og det er præcis her, A.5.23 begynder at fejle. I årevis kunne man underskrive en kontrakt, have tillidscertificeringer, tilføje noget overvågning oveni og bare fortsætte. Det fungerede, da cloud-løsninger bare var e-mail-hosting eller et par virtuelle maskiner.

I dag kører komplette servicekataloger på hyperscale-platforme, hvor dine ingeniører har kraftfulde administratorroller og automatiseringsværktøjer, der berører snesevis af brugere på én gang. I det miljø holder "leverandøren administrerer sikkerheden" op med at være sandt. Cloududbyderen sikrer sin infrastruktur og kernetjenester, men du bestemmer identiteter, konfigurationer, integrationer og en stor del af den operationelle robusthed. Kunderne forstår i stigende grad dette og forventer, at du viser, hvordan delt ansvar defineres, og hvordan dit team udfører disse kontroller i det daglige.

A.5.23 er det punkt, hvor standarden eksplicit påpeger dette skift. Den forventer, at du går fra generisk leverandørsikring til aktiv styring af, hvordan cloudplatforme understøtter dine tjenester og dine kunder.

Den skjulte kompleksitet i din nuværende cloud-stak

Den skjulte kompleksitet i din cloud-stak bliver først tydelig, når du skriver den ned. En kort, fokuseret opgørelse afslører normalt langt flere tjenester, dataflows og administratorroller, end du forventede, hvilket er præcis, hvad A.5.23 ønsker, at du skal se og derefter administrere bevidst.

De fleste MSP'er opdager, at de driver langt flere tjenester på langt flere måder, end nogen var klar over:

Interne SaaS-værktøjer til samarbejde, ticketing, CRM og økonomi.
Offentlige cloudplatforme, der driver administreret infrastruktur, backup, overvågning og sikkerhedstjenester.
Niche-cloudværktøjer valgt af individuelle teams eller ingeniører til at løse specifikke problemer.

Samlet set skaber disse tjenester et netværk af dataplaceringer, administratorroller, logfiler og fejltilstande. Uden et centralt overblik ophobes risici stille og roligt: én tekniker har global administration på tværs af flere lejere, et "midlertidigt" SaaS-værktøj bliver forretningskritisk, og en backuptjeneste er aldrig blevet testet til reelle gendannelsesscenarier. En ISMS-platform som ISMS.online kan hjælpe dig med at opretholde det centrale overblik, så kompleksiteten ikke forbliver skjult.

For at gøre skiftet konkret, er det nyttigt at sammenligne den gamle leverandørtankegang med den cloud governance, som A.5.23 forventer.

En kort sammenligning viser, hvordan din tilgang skal ændres:

Aspect	Gammel leverandørmodel	A.5.23 cloud governance for MSP'er
Udbyderens synsvinkel	"Pålidelig leverandør håndterer sikkerhed."	"Partner i en defineret model for delt ansvar."
Kontrolomfang	Kontrakt plus grundlæggende overvågning	Fuld livscyklus: valg, brug, ændring, afslutning
Beviser du har	Certifikater og kontrakter	Registre, risikoregistreringer, matricer, livscyklusartefakter
Ejerskab inden for MSP	Implicit, personafhængig	Eksplicitte roller, runbooks og ISMS-integration

Når du ser din situation gennem denne linse, bliver det lettere at beslutte, hvor du har brug for struktur i stedet for flere ad hoc-løsninger.

Hvor kunder og revisorer afslører revnerne

Kunder og revisorer afdækker revnerne i din cloudløsning ved at stille klare spørgsmål om tjenester, data og ansvar. Deres spørgsmål fremhæver ofte huller i ejerskab, livscyklus og bevismateriale længe før et brud eller et nedbrud sker. Håndtering af tredjepartsrisiko og sporing af leverandørers compliance blev nævnt som en af de største udfordringer af 41 % af organisationerne i ISMS.online-undersøgelsen i 2025.

Typiske spørgsmål omfatter:

Hvilke cloud-tjenester bruger I på vores vegne, og hvor opbevares vores data?
Hvem er ansvarlig for backup, identitet, logning og konfiguration på hver platform?
Hvordan gransker, overvåger og om nødvendigt forlader du cloud-udbydere?
Hvordan vil I støtte os, hvis vi ønsker at opgive en given tjeneste?

Disse spørgsmål afslører, hvor jeres nuværende tilgang er vag. Hvis jeres svar afhænger af, hvem der er i mødet, eller kræver, at nogen går hen og tjekker, er A.5.23 allerede et problem. Kontrollen forventer, at I har processer til at erhverve, bruge, administrere og afslutte cloud-tjenester i overensstemmelse med definerede sikkerhedskrav. For en MSP betyder det at gå fra en improviseret cloud-story til en struktureret, som revisorer og kunder kan teste.

Det er her, at det bliver essentielt snarere end rart at have et live-register over cloud-tjenester, knyttet til risici, ansvar og livscyklusregistreringer.

Book en demo

Hvad ISO 27001 A.5.23 virkelig kræver af dig

ISO 27001 A.5.23 beder dig om at behandle cloud-tjenester som et styret servicelandskab med klare regler, ansvarsområder og dokumentation, ikke som en løs samling af værktøjer og udbydere. I praksis betyder det at være i stand til at vise, hvordan cloud-tjenester udvælges, kontrolleres og udfases i overensstemmelse med dine informationssikkerhedskrav.

Rapporten om informationssikkerhedens tilstand fra 2025 bemærker, at kunderne oftest forventer, at leverandører overholder formelle rammer som ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 og nye AI-standarder.

I 2022-udgaven angiver A.5.23, at I skal etablere og implementere processer for erhvervelse, brug, administration og afvikling af cloudtjenester i overensstemmelse med jeres informationssikkerhedskrav. Denne formulering er i overensstemmelse med den offentliggjorte kontroltekst i ISO 27001:2022 A.5.23 og med understøttende cloud-vejledninger såsom ISO 27017 og ISO 27018, som alle understreger end-to-end-styring af cloudtjenester snarere end engangs leverandørkontroller. En central ISMS-platform som ISMS.online kan gøre dette arbejde håndterbart ved at holde politikker, risici, ansvar og optegnelser samlet ét sted.

Revisorer leder typisk efter en klar linje fra kontrolteksten til faktiske politikker, procedurer og optegnelser. Hvis du med dine egne ord kan forklare, hvad A.5.23 betyder for din virksomhed, er du allerede foran mange MSP'er, der udelukkende er afhængige af den formelle formulering.

Fra én sætning til praktiske mål

At omdanne A.5.23 til praktiske mål betyder at opdele den formelle formulering i et lille sæt konkrete, testbare forventninger, som du kan designe kontroller og evidens omkring. Disse mål giver dig en ramme for at forklare kontrollen til dit team og til revisorer. Fortolkninger fra cloud-fokuserede ISO 27001-praktikere grupperer almindeligvis A.5.23-krav i temaer som cloudpolitik, risiko og krav, delt ansvar, livscyklus og evidens, hvilket er den tilgang, der afspejles her.

I praksis forventer A.5.23, at du gør fem ting konsekvent og er i stand til at bevise dem. En nyttig måde at fortolke kontrollen på er at opdele den i fem praktiske mål:

Cloudpolitik og -omfang – definere hvad "cloud" betyder for din organisation, hvilke tjenester og data der er omfattet, og hvem der kan implementere nye tjenester.
Risiko og krav – identificere cloudspecifikke risici såsom multitenancy, dataplacering og -forbindelse og fastsætte minimumskrav til sikkerhed og privatliv.
Fælles ansvar – dokumentere, hvem der er ansvarlig for nøglekontroller på tværs af udbyder, MSP og kunde for hver større platform og tjeneste.
Livscyklusstyring – indbygge sikkerhed i udvælgelse, onboarding, ændringer, overvågning og afslutning af cloudtjenester, ikke kun i kontrakter.
Beviser og forbedringer – føre optegnelser, der viser, at disse processer fungerer, og gennemgå dem, efterhånden som platforme, kunder og regler ændrer sig.

Sammen forvandler disse målsætninger A.5.23 fra en enkelt sætning til et sæt vaner. De giver dig også en struktur til at kortlægge kontrollen i din anvendelighedserklæring og dit bredere ISMS. Registrering af målsætninger, ejere og understøttende dokumentation i et system som ISMS.online hjælper dig med at holde dem konsistente, efterhånden som tjenester og standarder udvikler sig.

Hvordan A.5.23 udvider den ældre leverandørmodel

A.5.23 udvider den ældre leverandørmodel ved at anerkende, at cloud er et teknisk fundament, ikke blot endnu en outsourcingkontrakt. Når dine tjenester afhænger af delte platforme, påvirker dine konfigurations-, adgangs- og driftsvalg sikkerhedsresultaterne kraftigt, selvom den underliggende infrastruktur tilhører en anden.

Sammenlignet med generiske leverandørkontroller inden for områder som leverandørstyring og driftssikkerhed, A.5.23:

Lægger vægt på cloud-tjenestens livscyklus, ikke kun leverandørvalg.
Forventer eksplicit overvejelse af delt ansvar og flerlejemål.
Fokuserer på, hvordan du vil afslutte eller erstatte cloud-tjenester uden at miste kontrollen over data.

Disse vægtninger afspejles i specialiserede A.5.23-kommentarer og cloud-kontrolkortlægninger, som fremhæver livscyklus, delt ansvar og exitplanlægning som forskel fra traditionel leverandørtilsyn. For MSP'er fungerer A.5.23 også sammen med adgangskontrol, aktivstyring, hændelsesstyring og andre kontroller i bilag A. Målet er ikke at duplikere arbejde, men at sikre, at jeres eksisterende kontroller fuldt ud tager højde for cloud-løsninger og den måde, I leverer tjenester på.

Ved tydeligt at forbinde denne kontrol med dit ISMS hjælper du revisorer med at se, at cloud-governance er integreret og ikke behandles som et separat spor.

Dokumenttyper, som revisorer forventer at se

Dokumenttyper, som revisorer forventer at se for A.5.23, er dem, der beviser, at dine cloud-politikker, -processer og -ansvar er reelle, konsistente og anvendte. De vil se efter et lille, sammenhængende sæt af artefakter snarere end en stor mængde løst relaterede dokumenter. Implementeringsvejledninger til cloud governance for A.5.23 peger ofte på en kombination af politikker, serviceregistre, risikovurderinger og livscyklusregistre som det centrale bevissæt, som revisorer forventer.

Under en revision vil du sandsynligvis blive bedt om at fremlægge dokumentation såsom:

En politik for cloudbrug eller cloudsikkerhed.
Et register over cloud-tjenester, der anvendes internt og på vegne af kunder.
Cloud-specifikke risikovurderinger og behandlingsplaner.
Due diligence-registre for vigtige cloud-udbydere og underdatabehandlere.
Matricer for delt ansvar eller tilsvarende rolledefinitioner.
Procedurer eller håndbøger for onboarding og exit af tjenester.
Eksempler på logfiler, anmeldelser eller supportsager, der viser, at disse processer fungerer.

Hvis du hurtigt kan finde disse, og de fortæller en ensartet historie, vil A.5.23 føles kontrolleret og proportionelt. Hvis de kun findes i spredte dokumenter eller folks hoveder, bliver kontrollen en kilde til fund og ekstra arbejde. Brug af en ISMS-platform som ISMS.online til at opbevare disse artefakter ét sted gør det langt nemmere at vise, hvordan cloud håndteres i praksis.

ISMS.online giver dig et forspring på 81% fra det øjeblik, du logger på

ISO 27001 gjort nemt

Vi har gjort det hårde arbejde for dig, hvilket giver dig en 81% forspring fra det øjeblik, du logger på. Alt du skal gøre er at udfylde de tomme felter.

Kom i gang

MSP'ens dobbeltliv: Cloudkunde og -udbyder

Din MSP har et dobbeltliv under A.5.23: Du er både en krævende cloudkunde hos upstream-udbydere og en ansvarlig cloududbyder over for dine egne kunder. Kontrollen forventer, at du forstår, dokumenterer og styrer begge roller, herunder hvordan de interagerer på tværs af den delte ansvarskæde.

Som cloudkunde er du afhængig af hyperscale-platforme og SaaS-værktøjer til at drive din egen forretning og levere tjenester. Som cloududbyder ser dine kunder dig som den part, der er ansvarlig for sikkerhed, kontinuitet og support, selv når den underliggende teknologi tilhører en anden. A.5.23 bringer disse to perspektiver sammen og beder dig om at håndtere dem sammenhængende.

Forståelse af dine upstream- og downstream-roller

At forstå dine upstream- og downstream-roller betyder at erkende, at du forbruger cloud-tjenester som intern kunde, samtidig med at du sælger cloud-baserede tjenester som udbyder til dine egne kunder. A.5.23 forventer, at du har begge perspektiver i tankerne og sikrer, at de understøtter snarere end modsiger hinanden.

Som en cloud-kunde, du forbruger tjenester såsom produktivitetspakker, ticketing, overvågningsplatforme og public cloud-infrastruktur. Du er ansvarlig for, hvordan disse tjenester er konfigureret, hvem der har adgang, og hvordan de overvåges. Når der opstår hændelser, eller tilsynsmyndigheder stiller spørgsmål, afhænger din evne til at vise kontrol af, hvor godt du styrer dette forbrug, og hvor tydeligt det er knyttet til dine ISMS-processer, såsom risikovurdering og ændringsstyring.

Som en cloududbyder eller -administrator, du designer, leverer og supporterer tjenester, der kører på disse platforme. Du sælger muligvis administreret infrastruktur, backup, SOC, applikationshosting eller sikkerhedstjenester. Dine kunder ser dig som den ansvarlige part, selv når du bygger på en tredjeparts cloud. De skelner ikke mellem din tjeneste og den hyperscaler, den kører på; de antager, at du har taget dig af detaljerne.

En almindelig fejljustering opstår, når du forpligter dig til kunder om logopbevaring eller backuphistorik, men et upstream-værktøj stadig kører på sin standardindstilling, en meget kortere indstilling. I så fald har din downstream-forpligtelse overgået din upstream-konfiguration, og A.5.23 vil afsløre dette hul.

Opbygning af et dobbeltrolleansvarsperspektiv

At opbygge et dobbeltrolle-ansvarsperspektiv betyder at kortlægge ansvar på tværs af udbydere, dine MSP-teams og kunder i en enkelt, sammenhængende model. Dette giver din CISO, chef for servicelevering og account managers et fælles billede af, hvem der ejer hvad på tværs af hele kæden.

En praktisk måde at gøre dette på er at oprette en ansvarsmatrix med to roller. På tværs af centrale kontrolområder – identitets- og adgangsstyring, konfiguration, logføring, backup, hændelsesrespons, ændringskontrol, databeskyttelse – angiver du:

Hvad dine upstream-udbydere forpligter sig til.
Hvad du som MSP forpligter dig til opstrøms (for eksempel aktivering af bestemte funktioner, håndtering af bestemte risici).
Hvad I forpligter jer til downstream i jeres kundekontrakter og SLA'er.
Hvad du forventer, at kunderne selv gør.

Denne øvelse afslører ofte uoverensstemmelser: forpligtelser over for kunder, der ikke har upstream-support, eller antagelser om udbydere, der ikke er dækket af deres kontrakter. Den tydeliggør også, hvor der er behov for stærkere kontroller, klarere formuleringer eller forskellige servicedesigns. Når du indbygger dette synspunkt i en ISMS-platform som ISMS.online, giver du teams en enkelt kilde til sandhed om delt ansvar.

At omsætte ansvarskort til daglig praksis

At gøre ansvarskort til daglig praksis betyder, at man skal sørge for, at alle, der berører cloudtjenester, forstår de dele, der gælder for dem, og hurtigt kan handle ud fra dem. Kortene skal forme adfærd inden for salg, teknik, support og kundestyring.

At gøre ansvarskort til virkelighed betyder:

Brug dem til at briefe salgs- og accountteams, så de ikke lover for meget eller improviserer forpligtelser.
Afstem runbooks og playbooks med de ansvarsområder, du har defineret, så tekniske teams handler ensartet.
Uddannelse af ingeniører i, hvordan og hvornår de skal udøve deres rettigheder i forhold til kundernes lejere, herunder tidsbestemte forhøjelser og godkendelser.
Aftale om, hvordan hændelser, der involverer udbydere, skal kommunikeres og håndteres med kunderne, herunder eskaleringsprocesser.

Når din dobbeltrolleopfattelse er integreret på denne måde, holder A.5.23 op med at være et abstrakt krav og bliver et naturligt perspektiv på, hvordan din MSP fungerer i skyen. Det giver dig også en klar fortælling til bestyrelser og kunder, der ønsker at forstå din plads i den delte ansvarskæde.

En praktisk model for delt ansvar til MSP-cloudplatforme

En praktisk model for delt ansvar for MSP-cloudplatforme er et sæt klare matricer, der viser, hvem der gør hvad på tværs af udbyder, MSP og kunde for hver tjeneste. I henhold til A.5.23 forvandler disse matricer ideen om delt ansvar til noget, du kan køre, undervise i og revidere.

De fleste public cloud-udbydere beskriver en simpel opdeling: de sikrer infrastrukturen; du sikrer det, du bygger på den. Dette mønster er dokumenteret i forklaringer af model for delt ansvar fra store udbydere som AWS, Azure og Google Cloud, og det er blevet en fælles basislinje for design af cloud-kontrol. For MSP'er er det kun udgangspunktet. Du har brug for modeller, der afspejler de specifikke platforme, du bruger, de tjenester, du tilbyder, og den måde, dine teams rent faktisk fungerer på.

At bevæge sig ud over det generiske "fælles ansvar"

At bevæge sig ud over generiske "fælles ansvar"-betegnelser betyder at erstatte vage udsagn med specifikke, navngivne opgaver, som enkeltpersoner og teams forstår. A.5.23 belønner denne klarhed, fordi revisorer og kunder kan se, hvem der er ansvarlig for reelle handlinger, ikke kun abstrakte koncepter.

Generiske "fælles ansvar"-mærkater skjuler reelle risici. For at komme videre fra dem skal du overveje:

De specifikke platforme, du bruger (f.eks. infrastruktur som en service, software som en service, administrerede sikkerhedsværktøjer).
De specifikke tjenester, du tilbyder (f.eks. administreret backup, administreret SOC, administreret moderne arbejdsplads).
Den måde dit team rent faktisk fungerer på (f.eks. brug af automatisering, centraliseret overvågning, vedligeholdelsesvinduer).

For hver kombination af platform og tjeneste bør en ansvarsmatrix definere ansvarsområderne tilstrækkeligt detaljeret til, at folk kan handle. Det betyder at udpege, hvem der muliggør logføring, hvem der tester gendannelser, hvem der håndterer anmodninger om adgang til data, og hvem der leder hændelseskommunikationen, i stedet for blot at angive "delt".

Dette ekstra trin understøtter også relaterede kontroller, såsom hændelsesstyring og driftssikkerhed, fordi alle kan se, hvor deres rolle starter og slutter.

Strukturering af dine ansvarsmatricer

At strukturere dine ansvarsmatricer godt betyder at bruge et ensartet layout, der afspejler, hvordan dine ingeniører og servicechefer tænker, samtidig med at det stadig er detaljeret nok til at vejlede handling. En simpel struktur, der gentages på tværs af tjenester, gør træning og gennemgang meget nemmere.

En praktisk matrix for hver tjeneste kan dække områder som:

Identitets- og adgangsstyring: – hvem opretter og tilbagekalder konti, administrerer roller og gennemgår adgang.
Konfiguration og hærdning: – hvem der anvender baselines, håndterer sikkerhedsopdateringer og gennemgår konfigurationsafvigelser.
Logføring og overvågning: – hvem aktiverer logfiler, gemmer dem, gennemgår advarsler og reagerer på hændelser.
Sikkerhedskopiering og gendannelse: – hvem konfigurerer sikkerhedskopier, tester gendannelser og verificerer gendannelsesmål.
Databeskyttelse og privatliv: – hvem der klassificerer data, anvender opbevaringsregler og administrerer de registreredes rettigheder.
Kontinuitet og exit: – hvem der er ansvarlig for robusthedsmønstre, failover og dataeksport eller -sletning ved kontraktens udløb.

For hver række skal matrixen tydeligt markere ansvarsområderne: udbyder, MSP, kunde eller delt med specifikke tildelte opgaver. Du bør også sikre, at hver matrix er versionskontrolleret og gennemgået, når tjenester, platforme eller kontrakter ændres, så den forbliver nøjagtig over tid.

Et forenklet eksempel på administreret backup på en offentlig cloudplatform kan se sådan ud:

Domæne	Udbyder / MSP / Kundens ansvar
Backupkonfiguration	Udbyder tilbyder funktion; MSP konfigurerer politikker; omfang af kundeanmeldelser
Gendan test	MSP udfører periodiske testgendannelser; kunden validerer dataenes fuldstændighed
Opbevaringsindstillinger	Udbyder håndhæver grænser; MSP fastsætter opbevaring; kunden godkender politik

Du kan derefter genbruge disse matricer på tværs af kunder, der bruger det samme servicemønster, og kun justere, hvor det virkelig er nødvendigt.

Forbind modellen med dit ISMS og dine kunder

Ved at forbinde den delte ansvarsmodel med dit ISMS og dine kunder sikrer du, at den påvirker beslutninger fra præ-salg til offboarding i stedet for at stå isoleret. Jo mere du forbinder den, desto mere nyttig og troværdig bliver den.

Når du har defineret disse modeller, skal du forbinde dem:

Internt ved at henvise til dem i politikker, procedurer, runbooks og træning.
Kommercielt ved at afstemme dine servicebeskrivelser, tilbud og SLA'er med de ansvarsområder, du har fastsat.
Med kunderne, ved at dele forenklede visninger eller diagrammer under onboarding, så forventningerne er klare fra dag ét.

Når en revisor spørger, hvordan I håndterer delt ansvar i henhold til A.5.23, kan I pege på disse matricer, deres links til jeres ISMS og eksempler på, hvordan de har vejledt reelle beslutninger. Når en kunde, såsom en CISO eller IT-chef, spørger "hvem ejer denne kontrol?", har I et svar, der er ensartet på tværs af virksomheden. En central platform som ISMS.online kan indeholde disse matricer sammen med risici, kontroller og kontrakter, så de er nemme at vedligeholde og dokumentere.

Integrer, udvid og skaler din compliance uden besvær. IO giver dig robustheden og selvtilliden til at vokse sikkert.

Book din demo

Design af cloud-servicelivcyklusprocesser for A.5.23

Livscyklusprocesser i cloud-tjenester er måden, hvorpå du beviser, at A.5.23 er mere end en politikerklæring: de viser, at du vælger, kører og udfaser cloud-tjenester på en kontrolleret og gentagelig måde. For en MSP er målet at væve cloud-livscyklustrin ind i dine eksisterende ISMS-processer, ikke at skabe et separat bureaukrati.

A.5.23 forventer, at du demonstrerer, at cloudtjenester følger definerede trin fra idé til afslutning, med sikkerhed og delt ansvar i betragtning i hvert trin. Dette stemmer nøje overens med kontrollens egen formulering omkring "anskaffelse, brug, administration og afslutning" af cloudtjenester i overensstemmelse med informationssikkerhedskrav og med almindelige livscyklusmodeller, der anvendes i ISO 27001 og cloudstandardvejledninger såsom ISO 27001 A.5.23-kommentarer. Dette stemmer naturligt overens med ISO 27001-klausuler om risikohåndtering, driftsplanlægning, ændringsstyring og leverandørstyring.

Definering af en cloud-servicelivscyklus, som folk kan følge

At definere en cloud-servicelivscyklus, som folk kan følge, betyder at omdanne A.5.23 til et lille sæt gentagelige faser, der passer til dine eksisterende arbejdsmetoder. Livscyklussen bør være enkel nok til, at produktejere, ingeniører og indkøbsteams kan anvende den uden specialviden. To tredjedele af organisationerne i 2025 ISMS.online State of Information Security-undersøgelsen siger, at hastigheden og omfanget af lovgivningsmæssige ændringer gør det sværere at opretholde overholdelse af regler.

En typisk livscyklus for betydelige cloudtjenester kan omfatte faser som:

Idé og vurdering – nogen foreslår en ny cloudtjeneste eller en ny måde at bruge en eksisterende på. Du screener den for forretningsværdi, sikkerhed og overholdelse af regler.
Udvælgelse og due diligence – du tjekker certificeringer, dataplaceringer, kontraktvilkår og supportmuligheder og sammenligner muligheder.
Design og onboarding – du bestemmer, hvordan tjenesten skal konfigureres, integreres og overvåges, og hvem der skal eje den.
Drift og ændring – du driver tjenesten, gennemgår logfiler og metrikker, håndterer ændringer og hændelser og sørger for, at konfigurationen er i overensstemmelse med dine standarder.
Gennemgang og fornyelse – du gennemgår med jævne mellemrum, om tjenesten stadig opfylder behovene, om risiciene er acceptable, og om der er behov for forbedringer.
Udgang eller udskiftning – hvis du slukker eller erstatter tjenesten, håndterer du dataeksport, sletning og kundekommunikation.

Disse faser gør beslutninger om cloudtjenester gentagelige i stedet for ad hoc. For hver enkelt skal du definere de minimumshandlinger, godkendelser og registreringer, du forventer. Det kan omfatte risikovurderinger, due diligence-tjeklister, konfigurationsgrundlinjer, ændringsregistreringer og exit-bekræftelser, alt sammen i overensstemmelse med dit centrale ISMS.

For at gøre dette endnu mere brugbart kan du udtrykke livscyklussen som et simpelt sæt trin, som teams skal følge.

Trin 1: Indfang og screen idéen

Registrer og screen hver cloud-tjenesteidé, før nogen tilmelder sig eller integrerer den, så du kan afveje værdi, risiko og sammenhæng med dit ISMS.

Registrer den foreslåede cloudtjeneste, dens formål og indledende risici, før nogen tilmelder sig eller integrerer den.

Trin 2: Færdiggør due diligence og design

Fuldstændig due diligence og design, før en cloudtjeneste tages i brug, så konfiguration, overvågning og ansvar defineres i stedet for improviseres.

Kontrollér sikring, kontrakter og datahåndtering, og definer derefter konfiguration, overvågning og delt ansvar.

Trin 3: Ombordstigning, drift og planlægning af udgang

Onboard, betjen og planlæg afgang på en struktureret måde, så du kan bevise, hvordan tjenesten styres gennem hele dens levetid.

Implementer tjenesten i henhold til dine baselines, overvåg den og registrer, hvordan du afslutter eller erstatter den sikkert.

Integrering af livscykluskontroller i din arbejdsmetode

Integrering af livscykluskontroller i din arbejdsmetode betyder, at de integreres i processer og værktøjer, som dine teams allerede bruger. Når livscyklussen er standardstien, bliver det meget nemmere at opretholde overholdelse af A.5.23.

Overveje:

Tilpasning til indkøbsarbejdsgange, så kontrakter ikke kan underskrives, før sikkerheds-, privatlivs- og driftskravene er kontrolleret.
Ved at forbinde det med din serviceintroduktionsproces, så nye tilbud eller større ændringer går gennem cloud-livscyklusgatene.
Integrering af livscyklusopgaver i dine ticket- og ændringssystemer, ikke kun i separate cloud-dokumenter.

Ved at forbinde livscyklustrin til etablerede processer som f.eks. forandringsledelse og leverandørstyring, reducerer du friktion og forbedrer implementeringen. Folk følger livscyklussen, fordi det er den mindste modstands vej, ikke fordi de er blevet bedt om at læse en anden politik.

Klargøring til revision af livscyklusbeviser

At gøre livscyklusbeviser klar til revision betyder at kunne vise et par komplette eksempler, der demonstrerer den samme logik anvendt på forskellige tjenester. Revisorer ønsker at se mønstre, ikke engangssucceser.

For hvert eksempel skal du forsøge at demonstrere:

Hvorfor tjenesten blev valgt, baseret på risiko og krav.
Hvordan ansvar blev defineret ved hjælp af jeres model for delt ansvar.
Hvilke kontroller blev implementeret ved onboarding, herunder basislinjer og adgangsmønstre.
Hvordan tjenesten overvåges og evalueres, med eksempler på ændringer eller forbedringer.
Hvordan data og adgang ville blive håndteret ved exit, selvom denne exit endnu ikke har fundet sted.

Hvis du kan fremlægge denne dokumentation uden større besvær, vil A.5.23 føles indlejret snarere end skruet på. Et system som ISMS.online kan hjælpe ved at forbinde tjenester, risici, ansvar, ændringer og exit-registreringer ét sted, så du ikke behøver at samle billedet fra bunden, hver gang nogen spørger.

Tekniske kontroller for flere lejere: Implementering af ensartede sikkerhedsforanstaltninger

Tekniske kontroller med flere lejere er det praktiske udtryk for dine A.5.23-cloudstyringsbeslutninger i det daglige tekniske arbejde. De omsætter modeller for delt ansvar og livscyklusprocesser til konkrete basislinjer, der beskytter mange kunder på én gang.

Når du administrerer flere lejere på fælles platforme, forventer A.5.23, at du har en proaktiv, standardiseret tilgang til identitet, konfiguration, logføring, backup og isolation. På den måde kan du vise, at dine tekniske sikkerhedsforanstaltninger stemmer overens med det ansvar, du har accepteret, og de forpligtelser, du giver over for kunderne.

Hvorfor basislinjer for flere lejere er vigtige

Basislinjer for flere lejere er vigtige, fordi små svagheder kan have store konsekvenser for mange kunder på én gang. En enkelt overpermissiv rolle, en manglende opdatering eller en utestet backup kan underminere din samlede cloud-sikkerhedsniveau. Cloud-sikkerhedsrammer og nationale retningslinjer, såsom risikodiskussioner for flere lejere i kontrolkataloger og cloud-sikkerhedssamlinger fra nationale cybersikkerhedscentre, fremhæver konsekvent identitetsstyring, patching og backup som systemiske risikoområder, der hurtigt kan skaleres på tværs af lejere, når de fejler. Et flertal af organisationerne i 2025 ISMS.online-undersøgelsen rapporterede at være blevet påvirket af mindst én tredjeparts- eller leverandørrelateret sikkerhedshændelse i det seneste år.

I et MSP-miljø kan én overprivilegeret administratorkonto, en ulogget kritisk handling eller en utestet backupproces påvirke snesevis af kunder i én hændelse. A.5.23 forventer, at du styrer disse risici systematisk, ikke reaktivt, og at du kan vise, hvordan dine kontroller gælder på tværs af de cloud-tjenester, du bruger og leverer. Konsistente basislinjer definerer de minimumskontroller, der er på plads for enhver kunde, der bruger en given platform eller tjeneste, og giver revisorer og kunder tillid til, at du ikke genopfinder sikkerheden hver gang.

Fra et ledelsesperspektiv giver disse basislinjer også en sikkerhedsplatform: Du kan vise bestyrelser og kunder, at de tekniske sikkerhedsforanstaltninger stemmer overens med de ledelses- og kontraktbeslutninger, du allerede har truffet.

Kernetekniske temaer, der skal standardiseres

Kernetekniske temaer, der skal standardiseres, er de områder, hvor ensartede sikkerhedsforanstaltninger reducerer sandsynligheden for problemer på tværs af brugere og giver ingeniører et klart udgangspunkt på alle platforme.

Selvom detaljerne varierer fra platform til platform, drager de fleste MSP'er fordel af at standardisere mindst følgende temaer. Dette gør det lettere for din sikkerhedschef, driftsleder og ingeniørteams at trække i samme retning.

Identitets- og adgangsstyring: – rollebaseret adgang, færrest privilegier, adskillelse af opgaver, tidsbegrænset forfremmelse af rettigheder til højrisikohandlinger og robust offboarding.
Konfiguration og hærdning: – basisskabeloner til netværkssegmentering, kryptering, endpoint-beskyttelse, patching-politikker og navngivning af ressourcer.
Logføring og overvågning: – ensartede logkonfigurationer, central logsamling, definerede alarmregler og dokumenterede handlingsplaner for respons.
Sikkerhedskopiering og gendannelse: – standard backupplaner, opbevaring, kryptering, testrutiner for gendannelse og dokumentation af klientens gendannelsesmål.
Isolation og lejemål: – mønstre til adskillelse af lejere på netværket, identitets- og datalag, og kontroller for at verificere, at isolationen holder.

Hver baseline skal tydeligt angive, hvad udbyderen leverer, hvad du konfigurerer og vedligeholder, og hvad du forventer, at kunderne gør. Samlet set bliver disse temaer den tekniske rygrad i din A.5.23-implementering.

Når du har defineret disse temaer, er næste skridt at integrere dem, hvor ingeniørerne befinder sig: skabeloner, scripts, infrastruktur som kode, centrale administrationsværktøjer og dokumenterede playbooks.

Tilslutning af tekniske kontroller til A.5.23 og videre

Ved at forbinde tekniske kontroller med A.5.23 og relaterede kontroller sikres det, at jeres styring, juridiske forpligtelser og tekniske praksisser understøtter hinanden i stedet for at blive adskilt. Denne tilpasning gør det nemmere at forklare og forsvare jeres samlede system.

Det betyder:

Kortlæg hvert basiselement til jeres matricer for delt ansvar, så de tekniske kontroller matcher det ansvar, I har tildelt.
Sørg for, at baselines er en del af din cloud-services livscyklus, så de anvendes ved onboarding og gennemgås igen under gennemgange.
Forbinder temaer som adgang, logning og backup med bilag A-kontroller om adgangskontrol, driftssikkerhed, hændelsesstyring og forretningskontinuitet.

Denne tilpasning gør dit overordnede kontrolsystem sammenhængende. Det betyder også, at når A.5.23 diskuteres under revisioner eller kundeanmeldelser, er du klar til at vise ikke blot politikker, men også fungerende tekniske sikkerhedsforanstaltninger, der matcher din governance-etage. Hvis du administrerer disse baselines i et centralt system som ISMS.online, kan du demonstrere forbindelsen fra en cloud-tjeneste til dens risikovurdering og dens tekniske kontroller med et par klik.

ISMS.online understøtter over 100 standarder og regler, hvilket giver dig en enkelt platform til alle dine overholdelsesbehov.

Book din demo

Kontrakter, SLA'er og underdatabehandlerklausuler, der holder i revision

Kontrakter, SLA'er og underdatabehandlerklausuler er der, hvor dine A.5.23-cloud governance-beslutninger bliver juridisk bindende løfter. Kontrollen forventer, at dine aftaler med udbydere, underdatabehandlere og kunder afspejler det fælles ansvar, den livscyklus og de tekniske valg, du har truffet, snarere end at modsige dem.

A.5.23 kræver ikke, at du skriver kontrakter på en bestemt måde, men revisorer og kunder vil teste, om dine juridiske forpligtelser og din tekniske virkelighed stemmer overens. Principbaseret vejledning om A.5.23 og relaterede cloud-kontroller understreger rutinemæssigt vigtigheden af at afstemme kontraktlige løfter med faktiske kontroller og modeller for delt ansvar, fordi mange revisionsresultater og tvister opstår i uoverensstemmelser.

At gøre ansvar og forventninger eksplicitte i kontrakter og SLA'er betyder, at jeres interne ansvarsmatricer oversættes til klare og stabile formuleringer, som alle kan forstå inden for jura, salg og kunder. A.5.23 er meget nemmere at dokumentere, når disse dokumenter stemmer overens med den måde, I rent faktisk arbejder på.

Kontrakter og SLA'er er steder, hvor misforståelser fører til tvister, især når det drejer sig om cloudtjenester. For at understøtte A.5.23 bør dine aftaler:

Beskriv tjenesterne tydeligt, herunder enhver afhængighed af tredjeparts cloudplatforme.
Angiv sikkerheds- og databeskyttelsesforpligtelser tilstrækkeligt detaljeret til at være meningsfulde, uden at love noget, du ikke kan holde.
Forklar hvem der er ansvarlig for hvilke aspekter af hændelsesdetektion, reaktion og kommunikation.
Afklar, hvad der sker ved kontraktens udløb, herunder dataeksport eller -sletning og eventuel overgangsstøtte.

Hvor det er muligt, skal denne formulering afstemmes direkte med domænerne i jeres delte ansvarsmatricer, så der er en klar linje fra model til formulering. Dette er også med til at opfylde relaterede ISO 27001-krav vedrørende juridiske, regulatoriske og kontraktlige forpligtelser.

Når ansvarsområderne er eksplicitte i både matricer og kontrakter, har dine teams mindre plads til modstridende fortolkninger, når der opstår hændelser eller komplekse kundekrav.

Tilpasning af den tekniske virkelighed med juridiske forpligtelser

At tilpasse den tekniske virkelighed til juridiske forpligtelser betyder at kontrollere, at det, du lover i kontrakter, kan opnås med dine nuværende værktøjer, processer og basislinjer. Det reducerer risikoen for, at kunder eller revisorer opdager huller mellem ord og praksis. Kun omkring 29 % af organisationerne i ISMS.online-undersøgelsen i 2025 sagde, at de ikke havde modtaget bøder for databeskyttelsesbrud, hvor størstedelen rapporterede bøder, og nogle stod over for bøder på over £250,000.

Det er nemt for juridiske klausuler at glide væk fra den tekniske virkelighed over tid. Måske lover en skabelon meget hurtig hændelsesnotifikation, men dine overvågnings- og eskaleringsprocesser gør det vanskeligt i praksis. Eller en SLA forpligter sig til gendannelsesmål, der ikke matcher backupdesign.

For at undgå dette, gennemgå jeres kontrakter og SLA'er i fællesskab på tværs af juridisk, sikkerheds-, drifts- og kundestyringsniveauer. Spørg:

Kan vi konsekvent opfylde de forpligtelser, vi giver, givet vores nuværende overvågning, supporttimer og tekniske basislinjer?
Er der områder, hvor vi skal investere i bedre kontroller eller værktøjer for at opfylde dem?
Er der forpligtelser, der i stedet bør ligge hos kunden eller udbyderen, og som bør kommunikeres som sådan?

Når jeres juridiske forpligtelser og tekniske kapaciteter er afstemt, bliver A.5.23 lettere at dokumentere og mindre risikabelt at leve med. I reducerer også sandsynligheden for overraskelser for kunder, tilsynsmyndigheder eller revisorer, der dykker ned i detaljerne bag jeres løfter.

Integrering af governance i dine aftaler

At integrere governance i dine aftaler betyder at bruge kontraktsprog til at forstærke den måde, du ønsker, at leverandører og kunder skal opføre sig på, ikke blot til at dokumentere tjenester og priser. Det kan gøre fælles ansvar og livscyklustænkning til en del af det daglige forhold.

Det kan omfatte:

Rettigheder til at modtage eller gennemgå leverandørgaranti, såsom opdaterede certificeringer eller uafhængige rapporter.
Forventninger omkring deltagelse i fælles hændelses- eller kontinuitetsøvelser.
Forpligtelse til at underrette om væsentlige ændringer i tjenesten eller placeringen.
Krav om at følge aftalte exitprocesser, herunder tidsfrister og samarbejde.

Ved at integrere disse i dine kontrakter sikrer du, at styring ikke kun er et internt anliggende. Det bliver en del af den måde, du, dine leverandører og dine kunder arbejder sammen på i løbet af tjenestens levetid. Når revisorer tester A.5.23, kan de se, at livscyklus og delt ansvar afspejles konsekvent i dine aftaler, ikke kun i dine politikker.

Book en demo med ISMS.online i dag

At booke en demo med ISMS.online er en praktisk måde at se, hvordan din MSP kan bringe A.5.23 cloud governance under kontrol uden at tilføje mere kompleksitet til dine teams. På ét sted kan du se, hvordan cloudtjenester, risici, ansvar, livscyklustrin og evidens forbindes, så du er klar til revisioner, kundespørgsmål og bestyrelsesgennemgange.

Du får kontrol over A.5.23 cloud governance, når du erstatter spredte dokumenter og ad hoc-beslutninger med et enkelt, sammenhængende system, der forbinder tjenester, risici, ansvar, livscyklustrin og beviser. For mange MSP'er kan brugen af en specialbygget ISMS-platform som ISMS.online være en praktisk måde at opnå denne konsolidering på uden at tilføje yderligere kompleksitet.

ISMS.online hjælper dig med at omdanne dine A.5.23 cloud governance-ansvar til et enkelt, sammenhængende system, der forbinder cloud-inventarer, modeller for delt ansvar, livscyklus-workflows, kontrakter og dokumentation. I stedet for at jagte dokumenter på tværs af drev, konsoller og indbakker, kan du se, hvordan cloud-tjenester styres, og hvordan ansvar administreres, på ét sted.

For MSP'er betyder det, at du kan vise revisorer, bestyrelser og kunder en klarere og mere sammenhængende fortælling: hvilke cloudtjenester du bruger, hvordan ansvaret deles, hvilke kontroller der er på plads, og hvordan disse ordninger ændrer sig over tid. Observatører af værktøjer til governance, risk and compliance (GRC) bemærker ofte, at centraliserede platforme gør denne type fortælling lettere at sammensætte og holde konsistent, fordi de samler risici, kontroller og beviser i ét miljø. Du bevarer kontrollen over beslutninger; platformen hjælper dig med at bevise denne kontrol konsekvent, i takt med at din virksomhed skaleres, og standarder udvikler sig.

Se din cloud-story i én visning

At se din cloud-story i ét overblik gør det nemmere for din CISO, driftsleder og kundevendte teams at besvare vanskelige spørgsmål uden gnidninger. A.5.23 bliver mindre en compliance-øvelse og mere en simpel måde at beskrive, hvordan du rent faktisk arbejder.

Når du centraliserer din cloud-styring på en ISMS-platform, giver du dig selv og dit team et enkelt referencepunkt for A.5.23. Du kan:

Vedligehold et live register over interne og klientvendte cloud-tjenester.
Forbind hver service til risici, kontroller, ansvarsmatricer og livscyklusfaser.
Vedhæft kontrakter, due diligence, ændringsregistreringer og exit-dokumentation direkte til de tjenester, de vedrører.

Sammen gør disse funktioner det meget nemmere at besvare spørgsmål fra revisorer, kunders sikkerhedsgennemgange og interne beslutningstagere, der ønsker at forstå, hvordan cloud-løsninger administreres. Du er ikke længere afhængig af hukommelse eller forskellige regneark til at fortælle din cloud-story.

Tag det næste skridt med selvtillid

Hvis du genkender din MSP i de udfordringer, der er beskrevet her - slørede ansvarsområder, spredt evidens, voksende pres fra kunder og revisorer - er det et praktisk næste skridt at udforske en platform som ISMS.online i en kort, fokuseret demonstration. Trods voksende pres angiver næsten alle respondenter i 2025 State of Information Security-undersøgelsen at opnå eller opretholde sikkerhedscertificeringer som ISO 27001 eller SOC 2 som en topprioritet.

Du kan se, hvordan det understøtter dine eksisterende værktøjer og arbejdsmetoder, samtidig med at det giver dig den struktur, som A.5.23 forventer.

Vælg ISMS.online, når du ønsker ét sted at opbevare dit register over cloudtjenester, ansvar, risici og dokumentation, så du kan vise, ikke bare påstå, at A.5.23 er under kontrol. Hvis du værdsætter klar styring, mere gnidningsløse revisioner og en stærkere platform for kunder og bestyrelser, er vores team klar til at hjælpe dig med at se, hvordan det ser ud i dit miljø.

Book en demo

Ofte stillede spørgsmål

Hvad forventer ISO 27001:2022 A.5.23 egentlig af en MSP, der bruger cloudtjenester?

ISO 27001:2022 A.5.23 forventer, at din MSP aktivt styre den fulde livscyklus for hver cloud-tjeneste, du er afhængig af, ikke bare indsamle udbydercertifikater og håbe på det bedste. Du skal hurtigt og konsekvent kunne vise, hvad du bruger, hvorfor du bruger det, hvad der kan gå galt, hvem der ejer hvilke kontroller, og hvordan du kan afslutte uden at miste data eller tjenester.

Hvordan ser "god" A.5.23-beviser ud for en MSP?

Revisorer og aktive kunder leder normalt efter en lille, sammenhængende bundt af bevismateriale, ikke et gigantisk arkiv. For en MSP omfatter kernesættet typisk:

En klar cloudbrug / cloudsikkerhedspolitik

Dette definerer, hvad der tæller som "cloud" i din verden (IaaS, SaaS, PaaS, administrerede sikkerhedstjenester), hvem der kan godkende nye tjenester, og dine minimumsforventninger til konfiguration, overvågning og exit.

A register over cloud-tjenester der dækker:
interne værktøjer (RMM, PSA, ticketing, fakturering, CRM, overvågning, sikker filoverførsel); og
Kundevendte tjenester (IaaS-platforme, Microsoft 365 og andre SaaS-pakker, backup/DR, SOC/XDR, administrerede firewalls og WAF'er).

Cloud-specifikke risikovurderinger og behandlinger:

Disse bør fremhæve eksponering for flere lejere, stærke roller på tværs af lejere, dataophold, leverandørlåsning, API-afhængigheder og nøglehåndtering. Risiciene bør være knyttet til reelle kontroller og forbedringstiltag.

Due diligence-optegnelser: for nøgleudbydere og underdatabehandlere

Dette omfatter typisk sikkerhedsresuméer, certificeringer (f.eks. ISO 27001, SOC 2), databeskyttelsesaftaler, oppetidshistorik, historik over brud og kendte begrænsninger eller udelukkelser, der påvirker dine designs.

Matricer for delt ansvar:

For hver større service skal du vise, hvad udbyderen gør, hvad din MSP gør, og hvad kunden skal gøre. Sproget skal være konkret nok til, at en tekniker eller kunde kan se "mine opgaver" uden et andet møde.

Livscyklusposter for cloud-tjenester:

Dokumentation for, at udvælgelse, onboarding, konfiguration, ændring, periodisk gennemgang og afgang håndteres på en kontrolleret og gentagelig måde i stedet for via ad hoc-sager.

Hvis disse elementer er sammenhængende og nemme at navigere i, føles A.5.23 under kontrol og troværdig. Brug af ISMS.online til at opbevare politikker, risikoregistreringer, leverandørregistre, ansvarsmatricer og livscyklusdokumentation i ét ISMS-arbejdsområde betyder, at du ikke behøver at rekonstruere din cloud-story fra indbakkesøgninger og konsolskærmbilleder, hver gang en revisor eller kunde fremsætter klausulen.

Hvordan skal en MSP opbygge en brugbar model for delt ansvar for cloud-løsninger under A.5.23?

Du opfylder intentionen i A.5.23, når "fælles ansvar" bliver en Kort over reelle opgaver, service for service, ikke bare en marketingslide, der siger "både vi og udbyderen bekymrer os om sikkerhed." Enhver, der læser den – ingeniør, sælger, kontraktanmelder eller kunde – bør kunne se præcis, hvad de ejer.

Hvordan forvandler man "fælles ansvar" til noget konkret?

Et praktisk mønster, der fungerer godt for MSP'er, er at:

1. Katalogiser dine cloud-tjenester efter kategori

Start med en kort liste over emner:

Offentlige cloud-arbejdsbelastninger (IaaS/PaaS).
SaaS-produktivitetspakker (Microsoft 365, Google Workspace og lignende).
Administrerede backup- og disaster recovery-tjenester.
Administrerede SOC/XDR- og trusselsdetektionstjenester.
Andre tilbagevendende cloudbaserede værktøjer, du bruger til at drive din virksomhed eller levere tjenester.

Denne liste afspejler normalt posterne i dit cloud-tjenesteregister, hvilket gør det nemmere at holde styr på tingene.

2. Vælg et fælles sæt af sikkerhedsdomæner

Vælg et lille sæt domæner, der gælder for de fleste af dine tjenester, såsom:

Identitets- og adgangsstyring.
Basiskonfiguration og hærdning.
Logføring, overvågning og alarmering.
Backup-, gendannelses- og testrutiner.
Kryptering og nøglehåndtering.
Hændelsesdetektion, triage og respons.
Ændringshåndtering og godkendelser.
Dataopbevaring, -lagring og -bortskaffelse.

At holde sig til et standardsæt gør modellen nemmere at forstå og genbruge på tværs af tjenester.

3. Tildel ejerskab pr. domæne, pr. tjeneste

For hver tjeneste og hvert sikkerhedsdomæne skal du beslutte, hvem der rent faktisk udfører arbejdet i praksis:

Cloud-udbyder: – infrastrukturens robusthed, fysisk sikkerhed, de fleste underliggende platformspatches, nogle muligheder for loglagring.
Din MSP: – basislinjer for lejerkonfiguration, alarmrouting, backupplaner, gendannelsestest, hændelsessortering, kunderapportering.
Kunde: – brugeradfærd, acceptabel brug, dataklassificering, adgangsgodkendelse, beslutninger om indholdslivscyklus.

Hvor ansvaret deles, skriv fordelingen ned som specifikke opgaver, ikke vage "led"-etiketter. For eksempel:

"Kunden godkender opbevaringsperioden; MSP implementerer og gennemgår konfigurationen hvert kvartal."
"MSP gennemgår sikkerhedsadvarsler; udbyderen håndterer hændelsesrespons på platformniveau."

4. Integrer modellen i den daglige drift

En ansvarsmatrix er kun relevant, hvis den dukker op der, hvor folk arbejder. Sørg for at:

Henvis det i Runbooks og playbooks, så ingeniører kan se, hvad de skal gøre under hændelser og ændringer.
Juster standard servicebeskrivelser og SoW'er med det, så salget ikke lover opgaver, du ikke udfører.
Spejl det i kontrakter og SLA'er, så de juridiske forpligtelser stemmer overens med den tekniske virkelighed og upstream-udbydernes muligheder.
Inkluder det i onboarding-pakker, så nye kunder forstår, hvilke handlinger der bliver hos dem, og hvilke der bliver hos dig.

Ved at vedligeholde disse matricer centralt i ISMS.online – knyttet til tjenester i dit cloudregister, risikoposter og leverandørregistre – kan du opdatere en matrix én gang og få ændringen udbredt i runbooks, dokumentation og revisionsbeviser. Det gør det meget nemmere at vise, at A.5.23 fungerer i praksis, ikke kun i et politikdokument.

Hvilke cloudspecifikke risici fremhæver A.5.23 for MSP'er, og hvor har de en tendens til at falde fra hinanden?

For MSP'er handler A.5.23 mindre om generiske historier om "cloud-brud" og mere om forkerte forventninger, konfigurationssvagheder og dårlig livscykluskontrol på tværs af delte miljøer. Problemer opstår ofte, hvor jeres marketingløfter, leverandørens evner og teamets adfærd ikke stemmer overens.

Hvor bliver MSP'er ofte taget på sengen?

Mønstre, der gentagne gange forårsager problemer, omfatter:

Overdreven afhængighed af udbydersikkerhedsantagelser

Det er nemt at tale om "sikkert design", mens man antager, at opgaver som gendannelsestest, loggennemgang, trusselsjagt eller hærdning på lejerniveau er inkluderet i et cloudabonnement. I virkeligheden er mange af disse aktiviteter dit ansvar som MSP, og nogle gange delvist din kundes. Når de ikke er registreret i dine ansvarsmatricer og runbooks, udføres de sjældent konsekvent.

Overdreven, dårligt styret privilegeret adgang

MSP'er har ofte magtfulde roller – globale administratorkonti, partnerportaler, "breakglass"-identiteter – der spænder over mange lejere. Hvis disse rettigheder mangler stærk godkendelse, logføring og gennemgang, kan en enkelt kompromitteret legitimationsoplysninger eller misbrugt konto blive en betydelig hændelse med flere lejere. A.5.23 forventer, at du anerkender denne risiko i dine aktiv- og risikoregistre og indfører klare kontroller omkring den.

Uregistreret eller "skygge" SaaS

Teams implementerer SaaS-værktøjer, der håndterer følsomme data eller kundedata – til support, samarbejde, udvikling, salg eller automatisering – uden nogensinde at tilføje dem til jeres ISMS, leverandørregister eller risikoprocesser. Disse tjenester falder derefter uden for jeres overvågnings-, hændelsesrespons- og exitplaner.

Svage eller uafprøvede exitplaner

Mange MSP'er tænker kun på exit, når en udbyder annoncerer en produktudfasning, en større prisændring eller et nedbrud. Uden en dokumenteret exitplan – inklusive dataeksport, migrering, dokumentation og kundekommunikation – improviserer du på det punkt, hvor du har brug for mest kontrol.

SLA'er, der lover for meget

Kontrakter forpligter dig nogle gange til gendannelsesmål, opbevaringsperioder eller specifikke dataopbevaringskrav, som den underliggende stak ikke kan garantere. Når servicedesignet, cloududbyderens funktioner og kontraktsprog ikke stemmer overens, løber du unødvendig risiko.

A.5.23 giver dig en ramme til systematisk at håndtere disse problemer:

Opgørelse og klassificering af cloudtjenester: så du ved, hvor risikoen koncentrerer sig.
Udfør cloud-specifikke risikovurderinger der adresserer problemer med flere lejere, privilegeret adgang og udbyderfejltilstande.
Vedligehold ansvarsmatricer så opgaver tildeles, ejes og gennemgås.
Beviser livscyklustrin – fra onboarding til exit – så folk kan se, at ændringer, anmeldelser og exits er kontrollerede begivenheder, ikke reaktioner.

Når du kan spore en risiko – for eksempel overdreven adgang til partnerportaler – fra dit register til ansvarsmatricer og derefter til ændring af poster og forbedringstiltag, overholder du ikke blot A.5.23; du præsenterer også en langt stærkere cloud-risikohistorie for revisorer og kunder.

Hvordan kan en MSP dokumentere A.5.23 i sit ISMS uden at redesigne alt?

Du kan normalt dække A.5.23 ved at Integrering af cloudspecifik styring oven på dine eksisterende ISMS, i stedet for at opbygge en parallel struktur. Målet er, at alle, der er bekendt med ISO 27001, lige så nemt kan følge, hvordan du vælger, kontrollerer og udfaser cloudtjenester, som de kan følge traditionelle aktiver eller leverandører.

Hvordan integrerer man cloud governance i det, man allerede har?

Et simpelt, men effektivt mønster er at starte med tre forbundne komponenter og derefter tilslutte dem til dit eksisterende ISMS:

1. Politik for brug af cloud-løsninger / cloud-sikkerhed

Udvid jeres eksisterende informationssikkerhedspolitik med et fokuseret dokument, der:

Definerer, hvad der kvalificerer som en cloudtjeneste i din kontekst.
Angiver godkendelsesgrænser (for eksempel hvem der kan godkende en ny udbyder).
Angiver forventninger til due diligence, konfigurationsgrundlinjer, overvågning, håndtering af hændelser og exit.

Denne politik bliver ankeret for relaterede procedurer og optegnelser.

2. Register over cloudtjenester

Opret et register – ofte en ISMS.online-liste over aktiver eller leverandører – der som minimum registrerer:

Tjenestens navn og udbyder.
Intern ejer.
Forretningsformål.
Håndterede datatyper og dataplaceringer.
Kritisk betydning og virkning af tab.
Links til kontrakter, databeskyttelsesaftaler, certificeringer og ansvarsmatricer.

Du kan integrere dette med din eksisterende beholdning af aktiver, så cloud-tjenester ikke findes i et separat univers.

3. Matricer for delt ansvar

For de tjenester, der betyder mest, skal du opbygge og vedligeholde ansvarsmatricer som beskrevet tidligere. Fokuser først på:

Din primære offentlige cloud-platform.
Din primære SaaS-produktivitets- og samarbejdssuite.
Dit flagskibstilbud inden for administreret backup/DR.
Dine administrerede SOC/XDR eller lignende security-as-a-service-løsninger.

Du kan derefter forbinde disse komponenter til de ISMS-elementer, du allerede bruger:

Risikostyring: – forbinde cloudtjenester til risikoposter og -behandlinger, især hvor der findes scenarier med flere lejere eller udbyderfejl.
Leverandørstyring: – vedhæfte kontrakter, sikkerhedsresuméer, databeskyttelsesaftaler og revisionsrapporter til de relevante udbydere; registrere periodiske gennemgange og beslutninger.
Driftskontrol: – referer til cloudspecifikke onboarding-, ændrings-, gennemgangs- og exit-trin i dine eksisterende ændringsstyrings- og hændelseshåndteringsprocesser.
Bevishåndtering: – link hændelser, resultater af backuptest, adgangsgennemgange og forbedringstiltag tilbage til de relevante cloud-poster og risici.

Ved at bruge eksempler – f.eks. én intern SaaS, én kundeorienteret løsning bygget på public cloud og én nichebaseret, men kritisk platform – kan du vise revisorer, at mønsteret kan gentages uden at skulle dokumentere hver eneste mindre service individuelt. ISMS.online er designet til denne modelleringstype: politikker, registre, risici, leverandører, opgaver og beviser sidder sammen med links, der gør cloud-styringsbilledet let at følge.

Hvilke kontrakter og SLA'er bør en MSP tilpasse for at demonstrere A.5.23 til kunderne?

For at demonstrere A.5.23 overbevisende, skal du bruge både dine upstream- og downstream-aftaler for at matche den måde, du rent faktisk håndterer cloud-risici på. Det betyder, at dine kontrakter og SLA'er med udbydere og underdatabehandlere, og dine vilkår med kunder, alle bør pege på de samme ansvarsfordelinger og kapaciteter, som du dokumenterer i dit ISMS.

Hvad skal du kontrollere i aftaler mellem upstream-udbydere og underdatabehandlere?

Gennemgå de dele af hver aftale, der direkte påvirker dine tjenester og krav:

Sikkerheds- og tilgængelighedsforpligtelser: – sørg for, at RPO/RTO-mål, oppetids-SLA'er og dataholdbarhed stemmer overens med, hvordan du designer tjenester, og løfterne i dine egne SLA'er.
Erklæringer om dataplacering og opholdssted: – du skal kunne svare på spørgsmålet "hvor er vores data?" med sikkerhed, inklusive backupplaceringer og failover-regioner.
Hændelsesmeddelelse og eskalering: – tjek hvordan og hvornår udbydere forpligter sig til at informere dig om hændelser, der kan påvirke dine kunder.
Understøttelse af nøglekontroller: – bekræfte, om funktioner som detaljeret logføring, kundeadministrerede krypteringsnøgler, uforanderlige sikkerhedskopier eller avancerede adgangskontroller, som du stoler på, er eksplicit tilgængelige og understøttede.
Sikringsmekanismer: – identificer certificeringer, revisionsrapporter, resuméer af penetrationstest eller kontraktlige revisionsrettigheder, som du kan bruge som dokumentation i dit eget ISMS og kunderapportering.

Du behøver måske ikke at genforhandle alle kontrakter, men du bør forstå og dokumentere, hvor en udbyders forpligtelser ikke lever op til dine nuværende servicebeskrivelser, og justere dine egne tilbud eller arkitekturer i overensstemmelse hermed.

Hvordan bør kundekontrakter og SLA'er ændres for at afspejle A.5.23?

Nedstrøms, bør dine kundevendte dokumenter:

Identificer tydeligt hvilke tjenester er afhængige af hvilke cloudplatforme, især hvor det påvirker dataplacering, robusthed eller support.
Forklar Hvem er ansvarlig for hvilke kontrolområder – såsom brugeradgangsgodkendelser, acceptabel brug, klassificering, juridiske tilbageholdelser og indholdslivcyklus – i overensstemmelse med jeres delte ansvarsmatricer.
Forpligte sig til gendannelsesmål, opbevaringsperioder og tidsrammer for hændelseskommunikation som dine upstream-aftaler og -designs pålideligt kan levere.
Reference, eller link til, oplysninger om ansvar og afhængighed på en måde, som kunderne kan forstå uden at læse jeres ISMS.

Når upstream-kontrakter, interne ansvarsmatricer og downstream-SLA'er alle fortæller den samme historie, er det meget nemmere at gennemgå, hvordan man håndterer cloud-risici i henhold til A.5.23, med en kunde eller revisor. Administration af disse dokumenter i ISMS.online, sammen med sine politikker og risici, hjælper jer med at holde fortællingen på plads, efterhånden som udbydere opdaterer deres vilkår, regler udvikler sig, og kunderne bliver mere krævende.

Hvordan kan en MSP bruge ISMS.online til at holde A.5.23 under kontrol, når cloudtjenester ændrer sig?

ISMS.online hjælper dig med at holde A.5.23 under kontrol ved at forvandle cloud governance til en løbende opdateret, forbundet system, snarere end et sæt statiske dokumenter, der halter bagefter ændringer i din stak. Når du implementerer, ændrer eller udfaser cloudtjenester, kan din ISMS-visning forblive aktuel, kontrollerbar og forklarlig.

Hvordan ser den daglige A.5.23-styring ud i ISMS.online?

I en typisk opsætning ville dit team bruge ISMS.online til at:

Vedligehold et live register over cloud-tjenester

Registrer hver cloudtjeneste med dens ejer, formål, datatyper, dataplaceringer og kritiske karakter.
Tag-tjenester, der bruges internt, versus dem, der bruges til at levere administrerede tjenester.
Forbind hver post med relevante politikker, risici, leverandører og ansvarsmatricer.

Vedhæft og spor cloudspecifikke risici og behandlinger

Opret risikoposter for eksponering for flere lejere, effektive konti på tværs af lejere, dataopbevaring, udbyderlåsning og API-afhængigheder.
Tildel behandlinger, ejere og evalueringsdatoer.
Brug platformens tilknyttede arbejde og projekter til at spore afhjælpnings- og forbedringstiltag.

Gem kontrakter, certificeringer og due diligence ét sted

Upload leverandørkontrakter, databeskyttelsesaftaler, sikkerhedsresuméer og revisionsrapporter direkte mod leverandørens registre.
Registrer resultater og beslutninger fra evalueringer, så du kan vise, at udbyderens risiko styres over tid.

Centraliser delte ansvarsmatricer

Vedligehold én autoritativ matrix pr. større cloudtjeneste eller tjenestefamilie.
Forbind matricer til politikker, servicebeskrivelser, risikoposter og leverandørregistre.
Brug dem som referencepunkter, når du opdaterer runbooks, SLA'er og onboarding-materialer.

Aktiviteter i evidenslivscyklussen

Logvalg, onboarding, godkendelser af konfigurationsgrundlag, ændringsgennemgange, periodiske revurderinger og afslutningstrin som opgaver eller tilknyttede arbejdspunkter.
Knyt relaterede hændelser, backuptests, adgangsgennemgange og forbedringer til de relevante tjenester og risici.

Når du starter en ny platform, kan du klone en eksisterende post, justere konfiguration og ansvarsområder og forbinde den til risici og leverandører inden for få minutter. Når du trækker en tjeneste tilbage, kan du registrere beslutninger om datamigrering, rensning og dokumentation på samme sted.

Til revisioner, kundespørgeskemaer eller bestyrelsesmøder kan du derefter sammensætte en fokuseret A.5.23-evidenspakke direkte fra ISMS.online: cloudpolitikken, det aktuelle register, eksempler på ansvarsmatricer, centrale cloudrisici og -behandlinger, due diligence for leverandører og en stikprøve på livscyklus- og hændelsesregistre. Denne evne til at fortælle en ensartet, end-to-end-historie er det, der får en MSP til at se ud til at have kontrol over cloud-styring i stedet for konstant at reagere. Hvis du vil have kunder og revisorer til at se dig i den første gruppe, er det et næste skridt med høj gearing at investere i at strukturere A.5.23 korrekt i ISMS.online.

A.5.23 Informationssikkerhed ved brug af cloudtjenester – MSP-cloudplatforme og delt ansvar