Sådan forbliver MSP'er ISO 27001-kompatible ved hjælp af offentlige cloudplatforme

Multi-cloud, multi-tenant hovedpine for ISO 27001 MSP'er

Multi-cloud, multi-tenant public cloud gør det vanskeligere at overholde ISO 27001, fordi delte lag og virtuelle grænser øger risikoen for fejl. Du kører kundearbejdsbelastninger på tværs af AWS, Azure og Google Cloud, mens du genbruger teams, værktøjer og administrationsplaner, så én fejl kan påvirke mange tenants på én gang. For at forblive kompatibel skal dit ISMS beskrive denne virkelighed, behandle delte lag som førsteklasses risici og vise, hvordan du holder kundemiljøer adskilte. Denne forventning er i overensstemmelse med ISO 27001:2022-kravene om at forstå den organisatoriske kontekst, definere omfang og planlægge risikobehandling og -kontroller på en måde, der afspejler, hvordan du rent faktisk leverer tjenester, som beskrevet i standarden.

Offentlig cloud kan gøre dine tjenester mere skalerbare og rentable, men det ændrer også dit ISO 27001-risikobillede på måder, der er lette at undervurdere. Når du administrerer snesevis af kundemiljøer på tværs af flere platforme, skaber multi-tenancy, delte værktøjer og komplekse dataflows veje til fejlkonfiguration, som den ældre, on-prem-version af dit ISMS måske aldrig har overvejet. Hvis dit styringssystem stadig antager fysisk adskillelse og skræddersyede stakke pr. kunde, vil det have svært ved at beskrive, hvordan du rent faktisk fungerer i dag.

Næsten alle respondenter i 2025 ISMS.online-undersøgelsen angiver opnåelse eller opretholdelse af sikkerhedscertificeringer såsom ISO 27001 eller SOC 2 som en topprioritet.

For en managed service provider (MSP) er "multi-tenant" ikke blot et softwareudtryk. Det beskriver hele din driftsmodel: mange kunder deler de samme underliggende cloudplatforme, supportteams, overvågningsstakke og ofte det samme administrationsplan. ISO 27001:2022 forventer, at du forstår disse delte lag, behandler de tilhørende risici eksplicit og viser, hvordan du forhindrer, at én kundes problemer smitter af på en andens. Dette følger direkte af standardens vægtning af at identificere informationssikkerhedsrisici, der opstår som følge af din kontekst og behandlingsaktiviteter, og at vælge og anvende kontroller til at behandle disse risici på en påviselig måde i overensstemmelse med standarden.

Stærk cloud-sikkerhed starter, når du beskriver virkeligheden, som den er, ikke som du ønsker, den var.

Hvorfor flerboligforhold ændrer din risikoprofil

Multi-tenancy ændrer din risikoprofil, fordi isolation nu er logisk snarere end fysisk, og delte komponenter kan skabe fejl med stor eksplosionsradius. I stedet for at stole på separat hardware pr. kunde, er du afhængig af konfigurationer, identiteter og centrale platforme, så en enkelt fejl kan ødelægge dine antagelser om lejerseparation. ISO 27001 forventer, at denne ændring tydeligt fremgår af dine risikovurderinger, kontroller og dokumentation. Det er i overensstemmelse med ISO 27001:2022's risikobaserede tilgang, som kræver, at du analyserer, hvordan ændringer i teknologi og servicelevering påvirker risici, og derefter dokumenterer de resulterende kontroller og understøttende dokumentation i din risikohåndteringsplan og erklæring om anvendelighed.

I en on-prem verden havde man typisk separat hardware, netværk og sommetider separate værktøjsstakke pr. kunde. Isolation var primært fysisk. I public cloud er isolation logisk og afhænger i høj grad af konfiguration og identitets- og adgangsstyring (IAM). Det medfører tre store ændringer for ISO 27001:

Lejergrænser er for det meste virtuelle.
En forkert konfigureret rolle, sikkerhedsgruppe eller lagerpolitik kan pludselig omfatte flere kunder. ISO 27001 forventer, at du analyserer dette i din risikovurdering og designer kontroller, der holder det usandsynligt og detekterbart.
Delte komponenter bliver aktiver med stor effekt.
Logføringspipelines, backupmål, administrationsnetværk, overvågningsværktøjer og identitetsudbydere betjener nu flere kunder. Hvis én kompromitteres, kan konsekvenserne være omfattende, så disse aktiver skal fremgå af din inventarliste, risikoregister og erklæring om anvendelighed.
Ansvaret er delt på tre måder.
For hver kontrol skal du beslutte, hvad der håndteres af cloududbyderen, hvad der ejes af dig som MSP, og hvad din kunde skal gøre. Hvis denne opdeling er uklar, er dit risikobillede ufuldstændigt, og din dokumentation vil blive udfordret af revisorer. Branchevejledning om modeller for delt ansvar i cloudmiljøet, herunder fællesskabsressourcer såsom OWASP-dokumentationen for delt ansvar i cloudmiljøet, understreger behovet for at tildele og dokumentere ejerskab for hver aktivitet på tværs af udbyder, MSP og kunde, så der ikke er huller.

Hvis du ikke genkender disse ændringer i dit ISMS, kan du stadig bestå en revision en eller to gange, men du vil finde det sværere at retfærdiggøre beslutninger, hvis noget går galt i et delt miljø.

Typiske svage punkter, som MSP'er overser

Typiske svagheder i public-cloud MSP-miljøer inkluderer overdreven afhængighed af udbydercertificeringer, at glemme delte platforme i aktivlisten og at lade kritisk viden ligge i folks hoveder i stedet for i jeres ISMS. Disse huller underminerer ellers stærke ISO 27001-historier og viser sig ofte først under revisionspres eller under hændelser.

Flere mønstre dukker op igen og igen, når MSP'er flytter tjenester til public cloud og forsøger at overholde ISO 27001:

Forudsat at skyen er certificeret, så er vi okay.:

Cloud-certificeringer dækker udbyderen; du skal stadig konfigurere og drive hvert kundemiljø sikkert.

Ikke listet delte platforme som aktiver.:

At behandle central logging, administration eller bastionplatforme som generisk infrastruktur efterlader risici og kontroller for flere lejere udokumenterede.

Inkonsekvente lejerisolationsmønstre:

At blande dedikerede og samlede modeller uden standardmønstre eller -begrundelser gør det vanskeligt at forklare og forsvare isolationsbeslutninger.

Udokumenteret helteviden.:

At stole på et par ledende ingeniører i stedet for dokumenterede roller, processer og diagrammer adskiller ISMS fra virkeligheden.

Du behøver ikke at løse alt dette på én gang. Et praktisk mål for første kvartal er at anerkende risici forbundet med flere lejere i din risikovurdering, identificere delte platforme som kritiske aktiver og dokumentere de primære lejermønstre, du bruger i dag.

Book en demo

Omformulering af cloud-løsninger som en udvidelse af dit ISMS-område

At behandle cloud som en udvidelse af dit ISMS-område betyder, at du holder op med at se AWS, Azure og Google Cloud som generiske leverandører og begynder at behandle dem som centrale dele af dit miljø. ISO 27001:2022-klausuler om kontekst, omfang, risiko og interesserede parter gør det naturligt at behandle store cloudplatforme som om de befinder sig inden for dit systems grænser, ikke bare på kanten af dem. Når dit omfang afspejler denne virkelighed, bliver alt andet lettere at forklare og forsvare.

Hvis dit ISMS stadig lyder som om, du driver et eller to datacentre med et par SaaS-værktøjer, er det sandsynligvis ude af trit med din nuværende public-cloud-virkelighed. Et klart, cloud-bevidst omfang sætter forventninger til revisorer, kunder og interne teams, og det forhindrer senere diskussioner om, hvorvidt en bestemt tjeneste, region eller konto er "inden for omfanget". Uden denne klarhed risikerer du skjulte huller, hvor kundernes arbejdsbyrder eller supportplatforme ligger uden for dit dokumenterede system.

Når du behandler public cloud som inden for dine grænser, bliver hver konto, abonnement eller projekt, der hoster administrerede arbejdsbelastninger, endnu en facilitet, du skal forstå, dokumentere og kontrollere. Dette skift lyder måske administrativt, men det har meget praktiske konsekvenser for, hvordan du skriver politikker, sporer aktiver, administrerer leverandører og forklarer din garantihistorie til kunderne.

Opdatering af din omfangserklæring for offentlig cloud

At opdatere din scope statement for public cloud betyder at give et klart svar på, hvilke tjenester, miljøer og parter der er dækket af dit ISMS. I stedet for kun at liste datacentre, skal du navngive cloud-konti og beskrive, hvordan nye miljøer bliver omfattet. Dette giver revisorer og kunder et klart billede af, hvor dine ansvarsområder starter og slutter.

Din omfangsbeskrivelse skal besvare tre spørgsmål:

Hvilke tjenester er dækket?:

For en MSP inkluderer det typisk administreret hosting, overvågning, backup, sikkerhedsoperationer, servicedesk og alle kundeportaler, du hoster eller driver.

Hvilke miljøer er dækket?:

I stedet for kun navngivne datacentre bør du henvise til cloud-konti, abonnementer og projekter. Beskriv, hvor det er muligt, hvordan nye miljøer som standard bliver omfattet, når de opfylder bestemte kriterier, f.eks. hosting af produktionskunddata.

Hvilke partier og steder er relevante?:

Dette omfatter din egen organisation, kundemiljøer under din ledelse, nøgleleverandører (store cloududbydere, centrale SaaS-værktøjer) og, hvor det er nødvendigt, geografiske overvejelser som dataopbevaring.

En simpel måde at opdatere dit omfang på er at behandle hver cloudkonto, abonnement eller projekt, der hoster administrerede kundearbejdsbelastninger, som en "informationsbehandlingsfacilitet" i henhold til ISO 27001. Denne formulering hjælper med at tilpasse omfanget til standarden og gør det lettere at retfærdiggøre, hvorfor bestemte kontroller gælder.

Tilpasning af risikostyring, aktiver og leverandører

Tilpasning af risikostyring, aktiver og leverandører til cloud-løsninger betyder, at dine eksisterende ISO 27001-processer skal tale sproget for regnskaber, regioner og administrerede tjenester. I stedet for at skjule cloud-løsninger under generiske outsourcingrisici, giver du det eksplicitte poster i din metode, lagerbeholdning og leverandørniveauer, så klausul 4, 5 og 6 forbliver forankret i, hvordan du rent faktisk arbejder.

Et stort flertal af organisationerne i ISMS.online-undersøgelsen om informationssikkerhedstilstanden i 2025 siger, at hastigheden og omfanget af lovgivningsmæssige ændringer gør det sværere at opretholde overholdelse af regler.

Når cloud eksplicit er en del af ISMS'en, skal flere understøttende dele opdateres:

Risikometode.:

Cloudspecifikke risici såsom regionale afbrydelser, ændringer i administrerede tjenester, problemer med identitetsføderation og koncentrationsrisiko på en enkelt udbyder bør vises som navngivne elementer, ikke generiske outsourcingrisici.

Beholdning af aktiver:

Cloudtjenester, delte administrationsplaner, landingszoner og konfigurationsbaselines bør angives som aktiver med ejere, klassificering og livscyklustilstande.

Leverandørstyring.:

Store cloud-udbydere hører hjemme i et højkritisk niveau med dybere due diligence og løbende overvågning, mens SaaS-værktøjer med lavere risiko befinder sig i lettere niveauer.

Erklæring om anvendelighed:

Kontroller, der har en cloud-dimension, herunder bilag A 5.23 om brugen af cloud-tjenester, kræver eksplicitte noter om, hvordan de gælder for cloud-tjenester og -konfigurationer. Organisationer, der offentliggør mappings mellem bilag A-kontroller og cloud-platformkonfigurationer, såsom tekniske dokumenter om cloud-kontrol-kortlægning fra uafhængige organer som MITRE, fremhæver værdien af at præcisere, hvordan mål som A.5.23 opfyldes i specifikke tjenester og indstillinger i ressourcer såsom cloud-kontrol-kortlægningsdokumenter. Præcise mappings vil altid afhænge af dine arkitekturer, så behandl eksempler som mønstre snarere end faste forskrifter.

I næste kvartal skal du sigte mod at opdatere din scope erklæring, risikometode, aktivbeholdning og leverandørniveauer, så de eksplicit afspejler de cloudplatforme, du er afhængig af.

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

Design af ISO 27001-tilpassede multi-tenant-arkitekturer (AWS, Azure, GCP)

Design af ISO 27001-tilpassede multi-tenant-arkitekturer betyder at vælge et lille sæt mønstre, der balancerer sikkerhed, omkostninger og kompleksitet, og derefter anvende dem konsekvent. I stedet for at lade hvert team opfinde sin egen tenant-model, standardiserer I på pooled, siloed og hybride tilgange, som I kan forklare i ISO-termer, dokumentere dem og forbinde dem tilbage til risici og kontroller i jeres ISMS.

Når omfang og risiko er afklaret, er næste skridt at beslutte sig for et lille antal mønstre for flere brugere, som du kan forsvare teknisk og over for en revisor. At forsøge at understøtte alle mulige strukturer fører til undtagelser, teknisk gæld og revisionsfriktion. Hvis du kan pege på en kort liste over mønstre, forklare, hvornår du bruger hvert enkelt, og vise, hvordan de relaterer sig til dine risikovurderinger, bliver dine cloudarkitekturer meget lettere at retfærdiggøre.

I public cloud er multi-tenant design normalt et valg mellem tre overordnede modeller: pooled, siloed og hybrid. Standarden foreskriver ikke et mønster, men den forventer, at du træffer bevidste valg, dokumenterer dem og styrer de resterende risici. Dette er i overensstemmelse med ISO 27001:2022, der er teknologiuafhængig, samtidig med at det kræver, at du vælger og retfærdiggør kontroller og behandlinger baseret på dokumenterede risici og din valgte driftsmodel, som beskrevet i standarden.

Sammenligning af poolede, siloerede og hybride modeller

Sammenligning af poolede, siloerede og hybride modeller hjælper dig med at beslutte, hvilke mønstre der passer til hvilke tjenester og risikoniveauer. Poolede designs favoriserer effektivitet og logisk isolation, siloerede designs favoriserer klarere grænser, og hybride designs blander delte værktøjer med segregerede dataplaner. ISO 27001 kræver ikke en model, men den forventer, at du begrunder dit valg og håndterer de tilhørende risici.

Her er en forenklet visning af de kompromiser, du står over for:

Model	Sikkerhed og forsikring	Omkostninger og driftsindsats
Samlet	Afhænger i høj grad af logisk isolation og testning; sværere at retfærdiggøre for data med høj risiko.	Effektiv udnyttelse af ressourcer; enklere at operere i mindre skalaer.
Siloet	Tydeligere isolationsgrænser; ofte lettere at forklare for revisorer og tilsynsmyndigheder.	Højere omkostninger pr. lejer; flere miljøer at administrere.
Hybrid	Balancerer isolering af kritiske elementer med delte komponenter for effektivitet.	Design- og styringskompleksiteten øges; der er behov for stærke mønstre.

Samlet model.:

Mange kunder deler den samme infrastruktur, applikation og database, med adskillelse via lejer-ID'er, sikkerhed på rækkeniveau, skemaer eller navneområder. Du skal vise, hvordan adgangskontrol, test og overvågning reducerer risikoen for eksponering på tværs af lejere.

Silo-model:

Hver kunde har sin egen konto, sit eget abonnement eller sit eget projekt, ofte med sin egen database og nogle gange sin egen instans af kernetjenester. Dette er attraktivt for sektorer med højere risiko, fordi isolationen er lettere at forstå. Du skal stadig vise, hvordan du håndhæver ensartede baselines og undgår konfigurationsforskydning.

Hybridmodel.:

Delte kontrolplaner og værktøjer overføres til adskilte dataplaner, såsom konti pr. lejer, netværk eller databaser. Du skal vise, hvordan du beskytter og overvåger delte komponenter og begrænser eksplosionsradius fra delte fejl.

De fleste MSP'er ender med at bruge en blanding: flere samlede modeller til lavrisiko-tjenester med høj volumen og silo-modeller eller hybride modeller til tilbud med høj sikkerhed. Det vigtige for ISO 27001 er, at du definerer, hvilke tjenester der bruger hvilket mønster, og hvorfor, dokumenterer risiciene og kontrollerne for hver enkelt, og anvender mønstre konsekvent.

Brug af cloud-byggesten på en ISO-venlig måde

Brug af cloud-byggesten på en ISO-venlig måde betyder at tilpasse AWS-, Azure- og Google Cloud-konstruktioner til Annex A-kontroltemaer såsom adgangskontrol, segregering, logføring og leverandørstyring. Hvis du kan forklare konti, abonnementer, projekter og administrationsgrupper på det sprog, forvandler du potentielt forvirrende cloudterminologi til en sammenhængende sikkerhedsløsning.

Hver større cloud har sin egen terminologi og sine egne funktioner, men de ISO-tilpassede principper er ens:

On AWS, flere konti under en organisation med centrale beskyttelsesrækværk giver dig lejerisolation, mens delte værktøjer findes i separate administrationskonti.

On AzureEntras lejere, administrationsgrupper og abonnementer giver et hierarki; mange MSP'er bruger et abonnement pr. kunde-mønster med delte administrationstjenester.

On Google Cloud, organisationer, mapper og projekter opretter lag; en projekt-per-lejer-model med central logføring og delt netværk er almindelig.

I alle tilfælde bør du kodificere dine valgte mønstre i arkitekturdokumenter, diagrammer og skabeloner til infrastruktur som kode. På den måde kan du vise revisorer, at dine designs var bevidste, gennemgået, knyttet tilbage til risikovurderinger og implementeret konsekvent.

Integrering af sikkerhed i pipelines og dokumentation

Integrering af sikkerhed i pipelines og dokumentation forvandler dine multi-tenant-mønstre til gentagelig og auditerbar praksis. I stedet for at stole på engangskonfigurationer håndhæver du isolation, logføring og tagging i kode og efterlader en klar historik over, hvem der ændrede hvad og hvorfor. Dette understøtter direkte ISO 27001-forventningerne omkring ændringskontrol, driftsplanlægning og præstationsevaluering.

Trin 1 – Indbyg autoværn i infrastrukturkoden

Brug skabeloner, politikker og konfigurationsregler til at håndhæve baselines for isolation, kryptering, logføring og tagging, når du opretter et nyt miljø.

Trin 2 – Integrer sikkerhedskontroller i CI/CD

Scan automatisk infrastrukturkode og cloudkonfigurationer for problemer, der kan underminere lejeradskillelse eller andre vigtige kontroller, før ændringerne når produktionsniveau.

Trin 3 – Registrer beslutninger og trusler i dokumentation

Registrer hvorfor du valgte hvert mønster, hvilke trusler du overvejede, og hvilke kontroller du stoler på, ved hjælp af præcise beslutningsregistre og trusselsmodeller.

Som et realistisk mål for det næste kvartal, standardiser på to eller tre lejermønstre, indfang dem i kode og diagrammer, og link dem tilbage til dine risikovurderinger og bilag A-kontroller.

Kortlægning af ISO 27001:2022 Anneks A til cloudtjenester og -mønstre

Kortlægning af ISO 27001:2022 Anneks A til cloudtjenester og -mønstre giver dig et fælles sprog mellem revisorer og ingeniører. I stedet for at diskutere, om en kontrol "gælder", peger du på en simpel matrix, der viser, hvilke AWS-, Azure- og Google Cloud-tjenester, baselines og rapporter, der opfylder hvert mål. Dette reducerer revisionsfriktion og gør ændringsstyring mere forudsigelig.

ISO 27001:2022 fortæller dig ikke, hvilken cloudtjeneste du skal bruge, eller hvordan du konfigurerer en firewallregel. Den definerer kontrolmål og lader dig vælge de tekniske midler. Det er designet: ISO 27001:2022 fokuserer på "hvad" inden for informationssikkerhed (risikostyring, kontrolmål og løbende forbedringer) og forbliver teknologineutral, så du kan bestemme, "hvordan" du vil implementere disse mål på dine valgte platforme, som afspejlet i standarden. I et komplekst MSP-miljø er den eneste praktiske måde at holde dette overskueligt på at opbygge et simpelt kontrol-til-tjeneste-kort, som ingeniører har tillid til, og som revisorer kan følge.

Dette kort fungerer som din bro mellem det sprog, som revisorer bruger (kontroller i bilag A) og det sprog, dine ingeniører bruger (cloudtjenester, API'er, konfigurationsgrundlinjer). Når du vedligeholder det, får du også et forspring i forbindelse med kortlægning til andre rammer, såsom SOC 2 eller sektorspecifikke standarder.

Opbygning af en kontrol-til-service-matrix

Opbygning af en kontrol-til-tjeneste-matrix betyder at identificere, hvilke Annex A-kontroller der har en stærk cloud-dimension, og derefter liste de tjenester, konfigurationer og processer, du er afhængig af for at opfylde dem. Når du gør dette én gang og vedligeholder det, reducerer du indsatsen ved enhver fremtidig revision og rammekortlægning.

Et nyttigt udgangspunkt er at fokusere på de temaer i bilag A, der ændrer sig mest, når du skifter til public cloud, såsom:

Adgangskontrol og identitet.:

Kontrolelementer omkring brugeradgang, privilegeret adgang og godkendelse knyttes til identitetsudbydere, rollebaseret adgangskontrol, multifaktorgodkendelse og adgangsgennemgange på dine cloudplatforme.

Logføring og overvågning.:

Kontrolelementer vedrørende hændelseslogning, overvågning og anomalidetektering, der knytter sig til cloud-logningstjenester, central SIEM, alarmering og runbooks til håndtering af hændelser.

Backup, gendannelse og sletning af information:

Kontrol af backup, gendannelsestest, opbevaring og sikker sletning er knyttet til snapshot-politikker, backupværktøjer, livscyklusregler og datarensningsprocedurer.

Leverandør- og cloudbrug:

Kontroller vedrørende brug af cloudtjenester, herunder bilag A 5.23, er knyttet til jeres proces til udvælgelse af cloudtjenester, vurdering af delt ansvar og overvågning af udbydersikkerhed.

For hver kontrol angiver du derefter de cloudtjenester og konfigurationer, du er afhængig af.

Trin 1 – Vælg de cloud-tunge kontroltemaer

Identificér kontroltemaer i bilag A, der ændrer sig mest i skyen, såsom adgangskontrol, logning, backup og cloudbrug, og prioritér dem i din matrix.

Trin 2 – Forbind hver kontrol med konkrete tjenester

For hver prioriteret kontrol skal du registrere identiteten, logføringen, backup- eller administrationstjenesterne samt nøglekonfigurationerne, der gør den effektiv i AWS, Azure eller Google Cloud.

Trin 3 – Bestem, hvad der tæller som bevis

Definer de skærmbilleder, konfigurationseksporter, logfiler, rapporter eller ISMS-poster, du vil bruge til at bevise, at hver kontrol er implementeret og fungerer. Nøjagtige mappinger vil variere fra MSP til MSP, så brug dette som en vejledning, og tilpas det til dine arkitekturer.

Målet er ikke at lave et kæmpe regneark. Det er at gøre forholdet mellem kontroller og cloud-virkelighed eksplicit, så du kan finde huller og forklare designet til revisorer.

Tilpasning af basislinjer, rammer og evidens

Ved at tilpasse baselines, frameworks og evidens omkring din matrix bliver den til et hverdagsværktøj snarere end en engangsøvelse. Når du ændrer en standardopbygning, indfører en ny framework eller forbereder dig til intern revision og ledelsesgennemgang, bruger du det samme kort i stedet for at starte forfra.

Når du har en grundlæggende matrix, følger der tre praktiske fordele:

Tekniske basislinjer bliver lettere at retfærdiggøre.
Når du opdaterer et standardbuild – for eksempel for at kræve kryptering overalt – kan du hurtigt se, hvilke kontroller der er berørt, og opdatere din dokumentation i overensstemmelse hermed.
Eksterne rammer overlapper hinanden mere tydeligt.
Ved at kortlægge ISO-kontroller til cloud-baselines kan ét sæt tekniske standarder opfylde flere frameworks, hvilket reducerer dobbeltarbejde.
Beviser bliver forudsigelige.
For hver kontrol i matricen kan du definere, hvilken dokumentation du vil bruge: konfigurationseksporter, skærmbilleder, logfiler, politikdokumenter, rapporter fra overvågningsværktøjer eller output fra din ISMS-platform.

En dedikeret ISMS-platform som ISMS.online kan hjælpe her ved at give dig ét enkelt sted at forbinde kontroller, cloud-aktiver og bevismateriale i stedet for at sprede dette på tværs af regneark, diagrammer og problemsporingssystemer. I løbet af de kommende måneder skal du sigte mod at opbygge en first-pass-matrix for dine vigtigste tjenester og forfine den, efterhånden som dine arkitekturer udvikler sig.

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

Book din demo

Operationalisering af modellen for delt ansvar på tværs af cloud-systemer

At operationalisere modellen med delt ansvar på tværs af clouds betyder, at udbyderdiagrammer omdannes til konkret ejerskab for dig og dine kunder. I stedet for vage udsagn om "sikring af skyen" opretholder du klare matricer, der viser, hvem der gør hvad for hver tjeneste, og holder dine kontrakter, procedurer og risikovurderinger i overensstemmelse med disse opdelinger.

Alle større cloududbydere udgiver en model for delt ansvar. Store udbydere som AWS, Microsoft Azure og Google Cloud udgiver alle deres egne modeller for delt ansvar, og branchegrupper som Cloud Security Alliance diskuterer, hvordan man kommunikerer og implementerer dem i praksis, i ressourcer som f.eks. deres blog om kommunikation af delt ansvar i cloudmiljøet. På et overordnet niveau siger de alle det samme: udbyderen sikrer skyen, du sikrer det, du lægger i skyen. Når du tilføjer MSP-tjenester og kundeforpligtelser til det billede, bliver opdelingen mere kompliceret – og vigtigere for ISO 27001.

ISO 27017, udvidelsen af ISO 27001 inden for cloudsikkerhed, eksisterer i høj grad for at præcisere disse opdelinger. Vejledning i cloudsikkerhed og referencer til delt ansvar, herunder fællesskabsarbejde som f.eks. OWASP-materialet om delt ansvar i cloudtjenester, understreger ISO 27017's rolle i at præcisere udbyder-kundens ansvar for cloudtjenester og hjælpe organisationer med at anvende ISO 27001-principper i hostede miljøer. Selv hvis du ikke er formelt certificeret til det, er koncepterne nyttige til dit ISMS og kan hjælpe dig med at forklare din model mere tydeligt for revisorer, kunder og juridiske eller privatlivsmæssige interessenter, der er interesserede i forsvarlig ansvarlighed.

At omdanne diagrammer over delt ansvar til konkret ejerskab betyder, at man for hver administreret service registrerer, hvilke opgaver der ejes af udbyderen, hvilke der ejes af dig, og hvilke der ejes af kunden. Når disse allokeringer er nedskrevet og holdes synkroniseret med jeres ISMS, bliver det meget nemmere at besvare revisorers spørgsmål om, hvem der er ansvarlig for hver kontrol.

Omkring 41 % af organisationerne i ISMS.online-undersøgelsen fra 2025 sagde, at håndtering af tredjepartsrisici og sporing af leverandøroverholdelse er en af deres største udfordringer inden for informationssikkerhed.

For hver større tjeneste, du tilbyder – administreret hosting, sikkerhedsovervågning, backup, identitet, endpoint-administration – bør du kunne besvare tre spørgsmål:

Hvad er cloud-udbyderen ansvarlig for?
Hvad er du som MSP ansvarlig for?
Hvad er kunden ansvarlig for?

Den mest praktiske måde at registrere dette på er en simpel ansvarsmatrix (ofte kaldet en RACI: ansvarlig, ansvarlig, konsulteret, informeret) for hver tjeneste eller tjenestekategori. Denne matrix bør stemme overens med:

Dine kontrakter og servicebeskrivelser.
Dine interne politikker og procedurer.
Dine risikovurderinger og behandlingsplaner.
Din kontrolkortlægning og evidensmodel.

Når revisorer ser et klart og ensartet sæt af matricer, der matcher dine faktiske operationer og dokumenter, får de tillid til, at du forstår og håndterer fælles ansvar.

Integrering af fælles ansvar i kontrakter og det daglige arbejde

Integrering af delt ansvar i kontrakter og det daglige arbejde gør RACI-diagrammer meningsfulde. I stedet for at leve i et isoleret regneark, dukker opdelingerne op i juridiske dokumenter, operationelle håndbøger og træningsindhold, så folk handler i overensstemmelse med det, du har lovet kunder og revisorer.

Det fælles ansvar skal være synligt to steder:

Kundevendte forpligtelser.
Kontrakter, arbejdsbeskrivelser, servicebeskrivelser og informationssikkerhedsbilag bør afspejle, hvem der gør hvad, og under hvilke betingelser.
Interne håndbøger og træning.
Runbooks, hændelsesprocedurer, onboardingmaterialer og teambriefinger skal referere til de samme opdelinger, så teknikere og supportteams ved, hvilke handlinger der er deres, og hvilke der skal eskaleres.

Dit ISMS er limen, der holder disse to synspunkter på linje. Når ansvarsmodellen ændrer sig – for eksempel hvis du begynder at administrere mere af kundens sikkerhedskonfiguration – bør dit omfang, dine risici, dine procedurer og dine kontrakter ændre sig med den.

I løbet af det næste kvartal er et realistisk mål at opbygge RACI'er (Revenue Control & Control) for jeres tre største cloudtjenester, opdatere de matchende kontraktklausuler og orientere jeres teams, så de forstår de nye opdelinger. For privatlivs- og juridiske medarbejdere styrker denne tilpasning også jeres position, hvis en tilsynsmyndighed senere undersøger, hvem der var ansvarlig for en bestemt kontrol.

Løbende compliance: styring, overvågning og evidens

Kontinuerlig compliance i public cloud betyder at indbygge ISO 27001-styring i den samme overvågning, rapportering og automatisering, som du allerede bruger til at køre dine tjenester. I stedet for at forberede dig til revisioner én gang om året, designer du dine dashboards, advarsler og evalueringer, så de også demonstrerer kontroleffektivitet, understøtter interne revisioner og gennemgang af feedstyring.

Offentlige cloud-miljøer ændrer sig konstant. Nye tjenester dukker op, eksisterende får funktioner, kundernes arbejdsbyrder ændrer sig, og regler udvikler sig. Et ISO 27001-program, der kun kommer til live før en revision, kan ikke følge med i dette tempo. For MSP'er er svaret at integrere ISO 27001-styring i den samme overvågning, rapportering og automatisering, der bruges til at køre tjenester, så sikring bliver et rutinemæssigt biprodukt af god drift.

Kontinuerlig overholdelse af regler er nemmere, når den er baseret på de systemer, du allerede har tillid til i driften.

Design af overvågning, der også fungerer som bevismateriale

At designe overvågning, der også fungerer som bevis, betyder at planlægge dine målinger og advarsler, så de demonstrerer kontrolfunktioner samt holder tjenesterne sunde. Hvis dine dashboards allerede viser, om sikkerhedskopier blev kørt, om adgang blev gennemgået, og om hændelser blev håndteret planmæssigt, har du mindre ekstra arbejde at gøre med ISO 27001-ydeevneevalueringen.

De fleste organisationer i ISMS.online-undersøgelsen om informationssikkerhed i 2025 siger, at de allerede er blevet påvirket af mindst én tredjeparts- eller leverandørrelateret sikkerhedshændelse i det seneste år.

Når du definerer overvågningskrav, skal du sigte mod at opfylde både operationelle og ISO-mål:

Kortadvarsler til kontrolpunkter.:

For hver nøglekontrol skal du sørge for, at der er en tilsvarende metrik eller advarsel; hyppige advarsler kan betyde, at kontrollen ikke er effektiv.

Centraliser omhyggeligt synlighed på tværs af lejere:

Brug central logføring og overvågning til at se aktivitet på tværs af kunder, men begræns adgang efter rolle for at respektere isolation og privatliv.

Indfang kontekst med begivenheder.:

Berig logfiler med oplysninger, der er vigtige for revisioner, f.eks. hvilken politik der udløste en afhjælpning, eller hvilken ændringsanmodning der godkendte en konfigurationsændring.

Trin 1 – Beslut hvilke kontroller der skal overvåges direkte

Identificer adgangs-, ændrings-, backup- og hændelsesrelaterede kontroller, hvor metrikker eller advarsler bedst demonstrerer effektiviteten over tid.

Trin 2 – Design dashboards og advarsler omkring disse kontroller

Konfigurer dashboards og advarsler, så de viser kontrolstatus, tendenser og afvigelser i et sprog, som dine ledere og revisorer forstår.

Trin 3 – Genbrug af overvågningsresultater i intern revision og gennemgang

Inkluder overvågningsrapporter i interne revisioner og ledelsesevalueringer, så præstationsevalueringen i henhold til paragraf 9 er forankret i livedata og ikke i meninger.

Hvis du kan vise en revisor, at dine dashboards og rapporter allerede besvarer deres spørgsmål om kontroldrift, bliver grænsen mellem drift og compliance behageligt tynd.

Automatisering, rapportering og udløsere for forandring

Automatisering, rapportering og udløsere for forandring er det, der sikrer kontinuerlig compliance på tværs af mange lejere. I stedet for manuelt at kontrollere hvert miljø, håndhæver du baselines i kode, opsummerer kontrolstatus for ledelsen og definerer klare betingelser for at genoverveje risici og kontroller.

For at sikre, at mange lejere lever op til dine ISO 27001-forpligtelser, er manuel kontrol ikke nok. Du skal bruge:

Automatisering til at håndhæve baselines.:

Værktøjer til politik-som-kode, konfigurationsstyring og afhjælpning holder miljøerne i overensstemmelse med dine standarder og registrerer, når de korrigerer afvigelser.

Regelmæssige ledelsesrapporter:

Dashboards og opsummeringer for ledelsen omfatter kontrolstatus, undtagelser, tendenser og udestående risikobehandlinger, opdatering af klausul 9 og ledelsens gennemgang.

Ryd udløsere for at gense kontroller.:

Nye cloudtjenester, større ændringer i arkitekturen, tilbagevendende advarsler eller ændringer i lovgivningen bør alle udløse en gennemgang af dine risikovurderinger og kontroller.

En platform som ISMS.online kan hjælpe dig med at forbinde disse operationelle signaler til selve ISMS'et – ved at forbinde risici, kontroller, handlinger og evidens – så ledelsessystemet virkelig afspejler, hvad der sker i skyen. I de kommende måneder skal du sigte mod at identificere en håndfuld kontroller med stor indflydelse, integrere dem i din overvågning og automatisering og sikre, at de resulterende rapporter integreres i dine interne revisions- og ledelsesgennemgangscyklusser. For IT- og sikkerhedseksperter reducerer dette smertefulde manuelle kontroller og forvandler godt ingeniørarbejde til synlige compliance-resultater.

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

Book din demo

At gøre "ISO i skyen" til en kommerciel fordel

At gøre "ISO i skyen" til en kommerciel fordel betyder, at du behandler dine cloud-bevidste ISMS som en del af dit tilbud, ikke blot et compliance-mærke. I stedet for at skjule dine praksisser bag et certifikat, pakker du isolationsmuligheder, sikkerhedsartefakter og responsiv styring som funktioner, der reducerer kundens indsats og opbygger tillid.

Mange MSP'er behandler ISO 27001 som et nødvendigt badge for udbud. I en moderne public cloud-praksis kan det være mere end det: det kan blive en måde at differentiere dine tjenester, reducere salgsfriktion og opbygge langsigtet tillid. Branchemateriale om brugen af ISO 27001 og cloud-sikkerhed i RFP'er og marketing, herunder vejledning fra store leverandører som IBM om positioneringscertificeringer i virksomheders indkøbscyklusser, antager ofte denne "badge til udbud"-basislinje og viser derefter, hvordan man går videre end den, som i ressourcer som IBMs vejledning om sikkerhedsattestationer i RFP'er. Når dit ISMS beskriver multi-tenant-virkeligheden tydeligt, kan du genbruge dette arbejde til at besvare spørgsmål fra potentielle kunder hurtigere og med større troværdighed.

Kunder, især i regulerede sektorer, ønsker i stigende grad at vide, hvordan I sikrer deres arbejdsbelastninger i skyen, ikke kun om I har et certifikat. Dette stemmer overens med, hvad mange cloud-sikkerheds- og marketingvejledninger rapporterer: Købere, især i regulerede brancher, forventer i stigende grad detaljerede forklaringer på, hvordan arbejdsbelastninger sikres, ikke kun en liste over certifikater, som det afspejles i leverandørvejledninger om bedste praksis inden for cloud-sikkerhedsmarkedsføring fra udbydere som f.eks. Oracles bedste praksis inden for cloud-sikkerhedsmarkedsføring. Hvis I kan omdanne jeres ISO-tilpassede cloud-praksisser til klare servicemuligheder og genanvendelig dokumentation, gør I det lettere for dem at vælge jer og retfærdiggøre dette valg internt.

Emballagesikring som funktioner, ikke kun certifikater

Emballagesikring som funktioner betyder at forklare hvordan Du sikrer arbejdsbelastninger i skyen, ikke kun fordi du har ISO 27001. Når du præsenterer isolationsniveauer, evidenspakker og klare ansvarsfordelinger som en del af dine tjenester, gør du dine salgs- og kundesuccesteams' arbejde lettere.

ISMS.online-undersøgelsen fra 2025 viser, at kunderne i stigende grad forventer, at leverandører overholder formelle rammer som ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 og nye AI-standarder.

Du kan bruge dine ISO-tilpassede cloudpraksis til at:

Tilbyd klare serviceniveauer, der knytter lejerisolation og sikkerhedsniveauer til dokumenterede ISO-tilpassede kontroller.

Tilbyd standardiserede bevispakker, som kunderne kan genbruge i deres egne revisioner, herunder matricer, kortlægninger, logfiler og opsummerende risikovisninger.

Forkort indkøbscyklusserne ved at præsentere en sammenhængende, præfabrikeret historie om, hvordan jeres ISMS dækker public cloud på sprog, som sikkerhedsteams genkender.

For grundlæggere og kommercielle ledere forvandler disse elementer sikkerhed fra en indvending til en grund til at købe. For IT-chefer og databeskyttelsesansvarlige på kundesiden giver de tilstrækkelig dybde til at stole på jeres tilgange uden at skulle reverse engineere dem. For jeres egne praktikere validerer de den tekniske indsats, der er lagt i jeres arkitekturer og kontroller.

Det arbejde, du har udført for at dokumentere omfang, mønstre, kontroltilknytninger og overvågning, kan selektivt genbruges i salgsmateriale og kundekommunikation, så længe du holder det nøjagtigt og fokuseret på at hjælpe kunderne med at opfylde deres egne revisionsforpligtelser.

Måling og kommunikation af den kommercielle effekt

Måling og kommunikation af den kommercielle effekt af din ISO-tilpassede cloudpraksis hjælper med at positionere compliance som en indtægtskilde. Når du kan pege på hurtigere spørgeskemaer, højere succesrater og fornyelser med sikkerhed som en grund til at blive, er din investering i ISMS meget lettere at forsvare.

Hvis du ønsker, at ISO 27001 skal ses som en indtægtskilde snarere end en omkostning, er det nyttigt at spore et par enkle målinger:

Sejrsrate i regulerede eller sikkerhedsfølsomme sektorer.

Tid fra sikkerhedsspørgeskema til kontraktunderskrift.

Tabte aftaler af sikkerheds- eller compliance-årsager.

Fastholdelse, hvor sikkerhed og compliance er centrale årsager til fornyelse.

Trin 1 – Vælg et lille sæt kommercielle sikkerheds-KPI'er

Vælg to eller tre målinger, såsom ekspeditionstid for spørgeskemaer eller succesrate i regulerede sektorer, der er tydeligt påvirket af din sikkerhedshistorie.

Trin 2 – Registrer og gennemgå disse målinger regelmæssigt

Opbyg simple rapporter, der viser tendenser over tid, og diskuter dem i kommercielle og ledelsesmæssige møder sammen med traditionelle salgsmålinger.

Trin 3 – Giv indsigt tilbage til dine ISMS og tilbud

Hvis du ser bedre resultater, når du tilbyder mere omfattende sikkerhedspakker eller stærkere isolationsmuligheder, så afspejl det i dine tjenester og i din ISMS-dokumentation.

Du kan også coache dine account- og kundesuccesteams til at tale om løbende sikkerhedsværdi: regelmæssige kontrolgennemgange, evidenspakker, briefinger om køreplaner og reaktioner på nye trusler eller lovgivningsmæssige ændringer. Det holder ISO 27001 til stede i fornyelsessamtaler uden at gøre dem til revisionsmøder.

Book en demo med ISMS.online i dag

ISMS.online hjælper dig med at køre et enkelt, cloud-bevidst ISO 27001-styringssystem, der holder trit med, hvordan din MSP rent faktisk bruger AWS, Azure og Google Cloud. I stedet for at jonglere med regneark, diagrammer og ad hoc-dokumentmapper kan du samle risici, kontroller, delte ansvarsmatricer og cloud-specifik dokumentation på ét sted og forbinde dem med det daglige arbejde, dine teams allerede udfører.

For MSP-grundlæggere og -ledere betyder det et klarere overblik over, hvordan jeres AWS-, Azure- og Google Cloud-praksis relaterer sig til ISO 27001:2022, og mere tillid til, at jeres certificering afspejler, hvad der rent faktisk sker i jeres miljøer. For compliance-chefer giver det struktureret support til opdatering af omfang, risikovurderinger, Annex A-kortlægninger og dokumentation, efterhånden som jeres cloud-fodaftryk vokser, herunder cloud-fokuserede kontroller, såsom dem, der dækker brugen af cloud-tjenester. For serviceledere, arkitekter og sikkerhedseksperter tilbyder det praktiske måder at linke referencearkitekturer, ændre arbejdsgange og overvåge output tilbage i ISMS'et uden at oprette et separat lag af papirarbejde.

Hvis du er seriøs omkring at bruge offentlige cloudplatforme, samtidig med at du forbliver ISO 27001-kompatibel – og omdanne denne funktion til en håndgribelig fordel for dine kunder – er det et simpelt næste skridt at booke en kort demonstration af ISMS.online. Du vil se, hvordan dine eksisterende cloudarkitekturer og -processer kan omsættes til et levende, revisionsklart ISMS, der skalerer med din managed services-forretning og reducerer belastningen på dit team.

Disse oplysninger er af generel karakter og udgør ikke juridisk rådgivning, certificeringsrådgivning eller revisionsrådgivning. Du bør altid konsultere en kvalificeret fagperson eller et certificeringsorgan for beslutninger, der påvirker dine forpligtelser.

Ofte stillede spørgsmål

Hvordan ændrer det virkelig jeres ISO 27001-overholdelse af reglerne ved at flytte MSP-kunder til en offentlig cloud?

At flytte kunder til AWS, Azure eller Google Cloud ændrer jeres ISO 27001-overholdelse, fordi jeres omfang, risici og kontroller skifter fra fysisk udstyr til cloudplatforme, konti og automatisering, og jeres ISMS skal fange dette skift, ellers holder det op med at afspejle, hvordan I rent faktisk driver tjenester.

Hvilke ISMS-elementer bør du opdatere først til public cloud?

Der er tre steder, hvor de fleste ISO 27001-certificerede MSP'er bør besøge før noget andet:

Omfang og kontekst:

Din omfangserklæring bør eksplicit navngive cloududbydere, kernekonti/abonnementer, regioner og delte administrationsplaner (f.eks. central logging, sikkerhedsværktøjer, CI/CD, identitet). Det fortæller en revisor præcis, hvor dine ISO 27001-grænser nu ligger, og hvilke platforme der understøtter dine administrerede tjenester.

Opgørelse og klassificering af aktiver:

Fysiske servere bliver til cloud-konti, projekter, tjenester, pipelines og konfigurationerLandingszoner, lejerbaselines, administrationsabonnementer, delte overvågningsstakke og automatisering bør behandles som informationsaktiver, og de data, de behandler, skal være tydeligt klassificeret. Dette hjælper dig med at vise præcis, hvor kundeoplysninger befinder sig i AWS, Azure eller Google Cloud.

Risikovurdering og behandling:

Fysiske trusler falder i relevans; cloud-centrerede risici stiger. Fejlkonfiguration, for brede roller, eksponerede administrationsgrænseflader, svage API-kontroller, usikker automatisering og nedbrud i udbyderregioner bør være synlige i dit risikoregister, med behandlinger knyttet til Annex A-kontroller såsom A.5.23 (brug af cloudtjenester) og netværkskontrollerne i A.8.20–A.8.22.

Hvis dit ISMS stadig lyder som en on-premises operation, mens dine kunder befinder sig i den offentlige cloud, vil en revisor sætte spørgsmålstegn ved, om dit risikobillede og kontrolsæt stadig er gyldige.

Hvordan ændrer public cloud, hvordan "kontrol" ser ud i praksis?

I public cloud udtrykkes en stor del af kontrollen gennem mønstre og automatisering, ikke kun dokumenter:

Adgangskontrol vises i identitetsudbydere, roller, politikker, arbejdsgange med betinget adgang og privilegeret adgang.
Netværkssegregering vises i VPC'er/VNet'er, sikkerhedsgrupper, NSG'er, firewalls, private endpoints og peering-regler.
Backup, overvågning og håndtering af hændelser er afhængige af native tjenester, der er forbundet via infrastruktur som kode, serverløse funktioner og runbooks.

For en ISO 27001-certificeret MSP er testen, om disse løftestænger er:

Standardiseret: i mønstre og basislinjer, snarere end unikke pr. projekt.
Ejet: gennem klare ansvarsfordelinger mellem udbyderen, dig og kunden.
Styret: af jeres ISMS (ændring, test, gennemgang), ikke efterladt som "hvad cloud-teamet foretrækker".

Når disse cloud-realiteter afspejles i en struktureret ISMS-platform som ISMS.online – med opdateret omfang, risici, kontroller og evidens – kan du forsikre revisorer om, at din certificering stadig matcher den måde, du rent faktisk arbejder på.

Hvordan bør en MSP designe multi-tenant cloud-arkitekturer, der stadig fungerer under ISO 27001?

Du holder ISO 27001 på din side ved at begrænse dig selv til en et lille antal mønstre for flere lejere, ved at knytte hver enkelt til risici og bilag A-kontroller og anvende dem konsekvent i stedet for at opfinde et skræddersyet design til hver ny kunde eller arbejdsbyrde.

Hvilke multi-tenant-mønstre fungerer typisk godt for ISO 27001 i AWS, Azure og Google Cloud?

De fleste MSP'er konvergerer omkring to eller tre standardmodeller og behandler alt andet som en undtagelse, der kræver stærkere begrundelse:

Samlet lejemål for tjenester med lavere risiko:

Flere kunder deler underliggende infrastruktur (f.eks. delte Kubernetes-klynger eller multi-tenant SaaS), hvor isolation håndhæves af ID'er, skemaer, navneområder og autorisation. For at holde dette ISO-venligt bør du præcisere:

Hvordan lejerdata adskilles (netværkssegmentering, databasekontroller, nøgler pr. lejer).
Hvordan isolation testes og overvåges (automatiserede kontroller, simulerede angreb, logning).
Hvordan du inddæmmer en støjende eller kompromitteret lejer (takstgrænser, begrænsning, sikker suspendering).

Dedikeret konto/abonnement/projekt pr. lejer til tjenester med højere sikkerhed:

Hver kunde har sin egen konto, sit eget abonnement eller sit eget projekt, der er forbundet til delte landingszoner og administrationsværktøjer. Dette stemmer naturligt overens med forventningerne til adskillelse i bilag A, men øger antallet af miljøer, du skal holde i overensstemmelse med dine baselines.

Delt kontrolplan med segregerede dataplaner:

Et centralt kontrolplan (CI/CD, logging, sikkerhedsværktøjer) tjener separate dataplaner hvor kundernes arbejdsbyrder og data befinder sig. Dette kan give dig driftsmæssig effektivitet, samtidig med at du bevarer klare grænser for dataisolering.

Det vigtigste er, at du kan vise:

A dokumenteret referencearkitektur for hvert mønster, med diagrammer og eksempler på infrastruktur som kode.
Et spor fra hvert mønster ind i dit risikoregister og Bilag A kontrollerer (for eksempel A.8.20–A.8.22 for netværkssikkerhed og -adskillelse).
Ændr og test processer, der sikrer, at alle nye lejere følger et kendt mønster i stedet for "hvad en ingeniør end gjorde under pres".

Når disse arkitekturer og kontroller findes i jeres ISMS, og jeres teams arbejder ud fra de samme designs, kan I forklare multi-tenancy til revisorer og indkøbere uden at skulle dele skærmbilleder af rå cloud-konsoller.

Hvordan forklarer I jeres model med flere lejere, så revisorer og kunder har tillid til den?

Begge målgrupper ønsker at se en ren rute fra risiko → design → konfiguration → beviserEn simpel fortælling fungerer godt:

Risiko: "Dataadgang på tværs af lejere på en delt platform."
Design: "Mønster af samlet klynge med navnerum, netværkspolitikker og krypteringsnøgler for hver lejer."
Konfiguration: "Basisskabeloner og beskyttelsesrækværk, vi anvender via Terraform eller implementeringspipelines."
Beviser: "Testresultater, isolationstjek, logfiler og hændelser, der viser, at kontrollerne fungerer over tid."

Ved at integrere den kæde i dit ISMS, med understøttende diagrammer og baselines, kan du guide en revisor eller prospekt gennem din model på en rolig og gentagelig måde. ISMS.online hjælper dig med at holde disse risici, arkitekturer og kontroller samlet ét sted, så hvert nyt miljø styrker din etage i stedet for at skabe forvirring.

Hvordan kan en MSP knytte ISO 27001:2022 Annex A-kontroller til AWS-, Azure- og Google Cloud-tjenester?

Du gør Anneks A brugbart i AWS, Azure og Google Cloud ved at oversætte hvert kontroltema til specifikke tjenester, baselinekonfigurationer og understøttende processer, og registrere det i en kontrol-til-service-kortlægning, som både dine ingeniører og revisorer kan følge.

Hvordan ser en praktisk kontrol-til-tjeneste-kortlægning ud?

En simpel, udvidelig matrix kunne se sådan ud:

Bilag A fokusområde	Cloud-tjenester omfattet	Basiskonfiguration og -processer
Adgangskontrol (A.5, A.8.x-familie)	IAM, Azure AD, Cloud IAM, PIM/PAM	Standardroller, MFA, just-in-time forhøjelse
Logføring og overvågning (A.8.15–A.8.16)	CloudTrail, Defender, Cloud-logging, SIEM	Centralisering, alarmrouting, vagttjenester
Sikkerhedskopiering og gendannelse (A.8.13–A.8.14)	Øjebliksbilleder, backup-bokse, kopier på tværs af regioner	Planlægning, opbevaring, gendannelse af test
Brug af cloud-tjenester (A.5.23)	Udbyderkataloger, onboarding-flow for tjenester	Leverandørgennemgang, risikogodkendelse, exitplanlægning

For hver række definerer du:

Hvilke tjenester: du bruger til det tema på hver platform.
grundlæggende indstillinger du forventer (kryptering, opbevaring, privat adgang, logføring, MFA).
bevismateriale du kan producere (IaC, rapporter, tickets, logs, screenshots hvis nødvendigt).

Derefter knytter du hver række tilbage til specifikke kontroller i bilag A og markerer, om en kontrol er:

Håndteret af udbyderen: (datacenterets fysiske sikkerhed, kerneinfrastruktur).
Implementeret og overvåget af dig: (konfiguration, overvågning, respons).
Afhængig af kunden: (sikkerhed på applikationslaget, nogle beslutninger om datahåndtering).

Den kortlægning bliver en fælles reference mellem sikkerheds-, teknik- og revisionsteams og et fundament, du kan bygge videre på, efterhånden som dit cloud-fodaftryk vokser.

Hvorfor er denne kortlægning nyttig ud over ISO 27001-certificering?

Når du har en god kontrol-til-tjeneste-kortlægning, kan du genbruge den på flere måder:

Udvid den til at dække SOC 2, NIS 2, DORA eller ISO 27701i stedet for at designe nye matricer fra bunden.
Få hurtigere svar på sikkerhedsspørgeskemaer og udbudsanmodninger, fordi du allerede ved, hvilke mønstre og tjenester der opfylder almindelige krav.
Giv dine hold en enkelt kilde til sandhed for hvordan AWS, Azure og Google Cloud skal konfigureres og drives for at forblive inden for jeres ISMS.

Ved at holde denne kortlægning i en integreret ISMS-platform som ISMS.online – sammen med risici, politikker, SoA'er og interne revisioner – overføres enhver ændring af cloud-tjenester eller -mønstre automatisk til din sikkerhedslogo i stedet for at forsvinde i et glemt regneark.

Hvad betyder delt ansvar egentlig for en ISO 27001-certificeret MSP i public cloud?

For en ISO 27001-certificeret MSP betyder delt ansvar i public cloud, at du har eksplicit besluttet, dokumenteret og aftalt hvem der gør hvad for hvert større kontrolområde, og at billedet er ensartet på tværs af dine ISMS, kontrakter, servicebeskrivelser og runbooks.

Hvordan kan man forvandle delt ansvar fra et slide til noget, der kan revideres?

En enkel måde er at opretholde en ansvarsmatrix pr. tjeneste, normalt ved hjælp af RACI:

Ansvarlig: hvem der udfører arbejdet (for eksempel konfiguration af lejere, kørsel af sikkerhedskopier, justering af advarsler).
Ansvarlig: hvem ejer risikoen og resultatet (dig, kunden eller nogle gange begge dele).
Konsulteret: hvem der leverer input (kundesikkerhed, juridisk, dataejere).
informeret: hvem har brug for opdateringer (account managers, kundeinteressenter).

Anvend denne matrix på tværs af kontroltemaer såsom:

Lejer-, platform- og netværkssikkerhed.
Identitets- og adgangsstyring.
Test af backup, gendannelse og robusthed.
Logføring, overvågning og alarmhåndtering.
Compliance-rapportering og kundevendt sikring.

Hver matrix skal stemme overens med:

Kontrakter og arbejdsbeskrivelser: , så omfang og antagelser er eksplicitte.
Intern Runbooks og diagrammer, så ingeniører følger den samme arbejdsfordeling.
Risici og kontroller: i dit ISMS, herunder hvor du er afhængig af kundernes handlinger.

Når du justerer en tjeneste – for eksempel hvis du påtager dig mere sikkerhed på applikationslaget, eller hvis kunden overtager mere operationel kontrol – så skal du opdatere matrixen, revidere din dokumentation og implementere den ændring i interne revisioner. Den historik giver dig en forsvarlig position i tilfælde af en hændelse eller tvist.

Hvordan kan ISO 27017 styrke jeres model for delt ansvar?

ISO 27017 tilbyder cloudspecifik sikkerhedsvejledning, der kan supplere ISO 27001 og ISO 27002. Hvis du bruger den til at forme din model for delt ansvar, kan du:

Vis revisorer og kunder, at jeres opgavefordeling følger offentliggjort god praksis, ikke bare et husudsigt.
Afklar gråzoner, såsom hvem der konfigurerer virtuelle firewalls, hvem der administrerer krypteringsnøgler, og hvem der hærder virtuelle maskiner, containere eller serverløse funktioner.
Reducer friktion ved onboarding ved at præsentere en standardiseret ansvarsmodel som er i overensstemmelse med ISO-vejledningen.

Ved at henvise til ISO 27017 i dit ISMS og kundevendte materiale forvandles delt ansvar fra et marketingdiagram til noget, der holder i ISO 27001-revisioner og samtaler med regulatorer. ISMS.online hjælper dig med at holde disse ansvarsmodeller, risikoregistre og kontrolkortlægninger synkroniseret, efterhånden som dine cloudtjenester udvikler sig.

Hvordan kan MSP'er generere overbevisende ISO 27001-revisionsbeviser, når arbejdsbelastninger kører i den offentlige cloud?

Du genererer overbevisende ISO 27001-dokumentation i den offentlige cloud ved at vise, at din styringssystem integrerer fuldt ud cloud og at din cloudplatforme drives konsekvent med det system på tværs af lejere, regioner og tjenester.

Hvilke ISMS-artefakter skal tydeligt vise din brug af AWS, Azure og Google Cloud?

På ledelsessystemets side vil revisorer se efter, at cloud-teknologi eksplicit optræder i:

Din omfangserklæring og kontekst, herunder afhængighed af specifikke udbydere og delte administrationsplatforme.
Risikovurderinger: og behandlingsplaner, der fremhæver cloudspecifikke problemer såsom fejlkonfiguration, identitetsspredning, regionale fejl og afhængigheder i forsyningskæden.
Anvendelseserklæring, især hvor kontroller implementeres af udbydere eller deles med kunder.
Interne revisionsplaner og rapporter: der dækker cloud-governance-aktiviteter som gennemgang af landingszoner, adgangsgennemgange og konfigurationsdriftstjek.
Input og output fra ledelsens gennemgang: hvor cloud-hændelser, ændringer og præstationsmålinger diskuteres, og beslutninger registreres.

Disse artefakter viser, at cloud-løsninger er en del af din normale Plan-Do-Check-Act-cyklus, og ikke noget, der håndteres uformelt uden for ISMS'et.

Hvilke cloud-niveau beviser har tendens til at berolige ISO 27001-revisorer?

På den tekniske side ønsker revisorer normalt en blanding af konfigurations-, overvågnings- og driftsregistreringer, der er knyttet til dine kontroller, for eksempel:

Adgang til gennemgangsoptegnelser: for landingszoner, lejermiljøer og administrationsværktøjer, herunder hvordan privilegeret adgang godkendes og fjernes.
Konfigurationsgrundlinjer og driftrapporter: (for eksempel IaC-skabeloner, politikpakker, dashboards for konfigurationscompliance), der viser, hvordan du registrerer og retter fejlkonfigurationer.
Bevis for backup og gendannelse: såsom backupplaner, jobrapporter, logfiler for gendannelsestest og hvordan mislykkede job blev håndteret.
Logførings- og overvågningsoutput: , herunder SIEM-dashboards, eksempelalarmer, justeringsregistreringer og eksempler på tidslinjer for hændelser.
Ændrings- og hændelsessedler: der viser, hvordan virkelige hændelser bevægede sig gennem dine arbejdsgange for ændringskontrol og hændelsesstyring.

At trække dette materiale ind i et struktureret miljø – i stedet for at jagte skærmbilleder på tværs af forskellige konsoller – sparer tid og gør din historie mere ensartet. ISMS.online hjælper dig med at forbinde hvert bevismateriale til den relevante risiko, kontrol og service, så du kan genbruge det til både revisioner og kundesikringspakker uden at skulle genopbygge alt fra bunden.

Hvordan kan en MSP forvandle cloud-bevidst ISO 27001-overholdelse til en kommerciel fordel?

Du forvandler cloud-bevidst ISO 27001-overholdelse til en kommerciel fordel ved at designe og beskrive dine administrerede tjenester, så kunderne kan føle, at du sænke deres arbejdsbyrde inden for sikkerhed og compliance i den offentlige cloud, i stedet for at lade dem stykke alt sammen.

Hvordan kan I pakke public cloud-tjenester, så jeres ISO 27001-styrker er tydelige?

En praktisk tilgang er at definere et par navngivne serviceniveauer der binder arkitektur, sikkerhed og pris sammen:

Hvert niveau kobler en lejerisolationsmodel (pooled, hybrid, dedikeret) med:

Defineret overvågnings- og rapporteringsdybde.
Aftalt hyppighed af adgangsgennemgange og gendannelsestests.
Tydelige forpligtelser og kommunikationsmønstre for hændelsesrespons.

Derefter bakker du op om hvert niveau med:

En standard ansvarsmatrix for det niveau, så kunderne kan se præcis, hvad du dækker, og hvad der forbliver hos dem.
En matchende kontrol- og bevispakke, der angiver hvilke Annex A-temaer I håndterer, og hvilke artefakter kunder kan forvente under due diligence.
Genanvendelig Udbudsmateriale og spørgeskemaindhold, så dine teams ikke omskriver sikkerhedssvar for alle potentielle kunder.

Derfra kan du spore:

Vinderrater, hvor købere eksplicit spurgte om ISO 27001 eller public-cloud-sikkerhed.
Tid fra første sikkerhedsspørgeskema til kontraktunderskrift.
Årsager til fornyelse og udvidelse, der nævner sikkerhed, compliance eller ro i sindet.

Disse datapunkter hjælper dig med at bevise internt, at et cloud-bevidst ISMS ikke blot er en omkostning ved at drive forretning; det understøtter aktivt vækst med de rigtige kunder.

Hvordan kan en ISMS-platform gøre den kommercielle etage lettere at se?

Når risici, kontroller, ansvar og beviser er spredt på tværs af teams og værktøjer, er det svært at besvare simple køberspørgsmål som "Hvordan holder I mine data sikre i AWS eller Azure?" med sikkerhed. En dedikeret ISMS-platform som ISMS.online hjælper dig med at:

Saml jeres ISO 27001-kontroller, multi-cloud-arkitekturer og forventninger i henhold til Annex A 5.23 i ét struktureret system, der afspejler, hvordan I rent faktisk arbejder.
Hold matricer for delt ansvar, risikobehandlinger og kontroltilknytninger opdaterede, efterhånden som dine tjenester, regioner og cloudfunktioner ændrer sig.
Generer ensartede, revisorvenlige output – omfangserklæringer, anvendelighedserklæringer, revisionsrapporter og kundesikringspakker – uden at genopbygge dem, hver gang en ny mulighed opstår.

Hvis du ønsker, at potentielle og eksisterende kunder skal opleve dig som den MSP, der tager deres skuldre af compliance med public cloud, er det værd at undersøge, hvordan en integreret ISMS-platform kan forbinde dine AWS-, Azure- og Google Cloud-designs med dine ISO 27001-forpligtelser og de garantier, som købere nu forventer som standard.

Hvordan MSPS kan bruge offentlige cloudplatforme, samtidig med at de overholder ISO 27001