A.5.23 Molnsäkerhet: Delat ansvar för MSP:er enligt ISO 27001

Varför MSP Cloud Security kollapsade över en natt

MSP-molnsäkerhet "bröt samman" när molnplattformar slutade vara enkla leverantörer och blev miljöer med delat ansvar som du aktivt måste styra. ISO 27001 A.5.23 gör den förändringen tydlig genom att förvänta dig att du kontrollerar hur du väljer, använder och avslutar molntjänster i linje med ditt ISMS, istället för att enbart förlita dig på leverantörscertifikat. Den förväntan återspeglar formuleringen i ISO 27001:2022 A.5.23 och vanliga riktlinjer för molnsäkerhet, som betonar definierade processer för förvärv, användning, hantering och avslutande av molntjänster snarare än att enbart förlita sig på leverantörsförsäkringar, vilket framhävs i kommentarerna till ISO 27001 A.5.23-riktlinjerna.

Molntjänster låter din MSP växa snabbt, men de avslöjade också luckor i ägarskap, styrning och bevis som den gamla leverantörsmodellen aldrig behövde lösa. När kunder och revisorer nu frågar vem som ansvarar för vad i molnet, räcker det inte längre med att "leverantören gör det". A.5.23 kristalliserar denna spänning genom att förvänta sig en kontrollerad, dokumenterad strategi för molnanvändning istället för ad hoc-plattformsval.

Molnet blir bara en fördel för MSP:er när ansvaret delas medvetet, inte tas över.

Molnet har vuxit ifrån ditt gamla "leverantörs"-tänkesätt

Molnet har vuxit ifrån idén att man kan skriva kontrakt, lita på ett certifikat och anta säkerhetsstopp i leverantörens utkant. För MSP:er tvingar A.5.23 er att inse att identiteter, konfigurationer och daglig drift på varje plattform nu ligger inom ert ansvarsområde.

Många MSP:er behandlar fortfarande molnleverantörer som traditionella leverantörer, och det är precis där A.5.23 börjar misslyckas. I åratal kunde man skriva kontrakt, lita på certifieringar, lägga till lite övervakning och bara fortsätta. Det fungerade när molnet bara var e-posthosting eller ett fåtal virtuella maskiner.

Idag körs hela tjänstekataloger på hyperskaliga plattformar, där dina ingenjörer har kraftfulla administratörsroller och automatiseringsverktyg som berör dussintals hyresgäster samtidigt. I den miljön slutar "leverantören hanterar säkerheten" att vara sant. Molnleverantören säkrar sin infrastruktur och sina kärntjänster, men du bestämmer identiteter, konfigurationer, integrationer och mycket av den operativa motståndskraften. Kunderna förstår alltmer detta och förväntar sig att du visar hur delat ansvar definieras och hur ditt team sköter dessa kontroller dagligen.

A.5.23 är den punkt där standarden uttryckligen påpekar detta skifte. Den förväntar sig att ni går från generisk leverantörssäkring till aktiv styrning av hur molnplattformar stöder era tjänster och era kunder.

Den dolda komplexiteten i din nuvarande molnstack

Den dolda komplexiteten i din molnstack blir bara uppenbar när du skriver ner den. En kort, fokuserad inventering avslöjar vanligtvis betydligt fler tjänster, dataflöden och administratörsroller än du förväntat dig, vilket är precis vad A.5.23 vill att du ska se och sedan hantera medvetet.

De flesta MSP:er upptäcker att de driver betydligt fler tjänster, på betydligt fler sätt, än någon insett:

Interna SaaS-verktyg för samarbete, ärendehantering, CRM och ekonomi.
Publika molnplattformar som driver hanterad infrastruktur, säkerhetskopiering, övervakning och säkerhetstjänster.
Nischade molnverktyg valda av enskilda team eller ingenjörer för att lösa specifika problem.

Tillsammans skapar dessa tjänster ett nätverk av dataplatser, administratörsroller, loggar och fellägen. Utan en central vy ackumuleras riskerna i tysthet: en ingenjör har global administratörsroll över flera hyresgäster, ett "tillfälligt" SaaS-verktyg blir affärskritiskt, en säkerhetskopieringstjänst har aldrig testats för verkliga återställningsscenarier. En ISMS-plattform som ISMS.online kan hjälpa dig att upprätthålla den centrala vyn så att komplexiteten inte förblir dold.

För att konkretisera skiftet är det bra att jämföra det gamla leverantörstankesättet med den molnstyrning som A.5.23 förväntar sig.

En kort jämförelse visar hur ditt tillvägagångssätt måste förändras:

Aspect	Gammal leverantörsmodell	A.5.23 molnstyrning för MSP:er
Leverantörens synvinkel	"Pålitlig leverantör hanterar säkerheten."	"Partnerskap i en definierad modell för delat ansvar."
Kontrollens omfattning	Kontrakt plus grundläggande övervakning	Hela livscykeln: val, användning, ändring, avslutning
Bevis du har	Certifikat och kontrakt	Register, riskregister, matriser, livscykelartefakter
Ägarskap inom MSP	Implicit, personberoende	Explicita roller, runbooks och ISMS-integration

När du väl ser din situation genom den här linsen blir det lättare att avgöra var du behöver struktur snarare än fler ad hoc-åtgärder.

Där kunder och revisorer blottlägger sprickorna

Kunder och revisorer blottlägger sprickorna i er molnlagring genom att ställa tydliga frågor om tjänster, data och ansvar. Deras frågor belyser ofta luckor i ägarskap, livscykel och bevis långt innan ett intrång eller avbrott inträffar. Att hantera tredjepartsrisker och spåra leverantörers efterlevnad nämndes som en största utmaning av 41 % av organisationerna i ISMS.online-undersökningen 2025.

Typiska frågor inkluderar:

Vilka molntjänster använder ni åt oss, och var lagras våra data?
Vem ansvarar för säkerhetskopiering, identitet, loggning och konfiguration på varje plattform?
Hur granskar, övervakar och, om nödvändigt, lämnar ni molnleverantörer?
Hur kommer ni att stödja oss om vi vill gå bort från en viss tjänst?

Dessa frågor avslöjar var er nuvarande strategi är vag. Om era svar beror på vem som är i mötet, eller kräver att någon går och kontrollerar, är A.5.23 redan ett problem. Kontrollen förväntar sig att ni har processer för att förvärva, använda, hantera och avsluta molntjänster i linje med definierade säkerhetskrav. För en MSP innebär det att gå från en improviserad molnlagring till en strukturerad som revisorer och kunder kan testa.

Det är här som det blir viktigt snarare än bra att ha ett aktivt register över molntjänster, kopplat till risker, ansvar och livscykelregister.

Boka demo

Vad ISO 27001 A.5.23 verkligen kräver av dig

ISO 27001 A.5.23 ber er att behandla molnet som ett styrt tjänstelandskap med tydliga regler, ansvarsområden och bevis, inte som en lös samling verktyg och leverantörer. I praktiken innebär det att kunna visa hur molntjänster väljs ut, kontrolleras och tas ur bruk i enlighet med era informationssäkerhetskrav.

I rapporten om informationssäkerhetens tillstånd från 2025 noteras att kunder oftast förväntar sig att leverantörer ska anpassa sig till formella ramverk som ISO 27001, ISO 27701 , GDPR, Cyber Essentials, SOC 2 och framväxande AI-standarder.

I 2022 års utgåva anger A.5.23 att ni bör etablera och implementera processer för förvärv, användning, hantering och avyttring av molntjänster, i enlighet med era informationssäkerhetskrav. Den formuleringen överensstämmer med den publicerade kontrolltexten i ISO 27001:2022 A.5.23 och med stödjande molnriktlinjer som ISO 27017 och ISO 27018, som alla betonar heltäckande styrning av molntjänster snarare än engångskontroller av leverantörer. En central ISMS-plattform som ISMS.online kan göra det arbetet hanterbart genom att samla policyer, risker, ansvar och register på ett ställe.

Revisorer brukar leta efter en tydlig linje från kontrolltexten till faktiska policyer, rutiner och register. Om du med egna ord kan förklara vad A.5.23 innebär för din verksamhet, ligger du redan före många MSP:er som enbart förlitar sig på den formella formuleringen.

Från en mening till praktiska mål

Att omvandla A.5.23 till praktiska mål innebär att dela upp den formella formuleringen i en liten uppsättning konkreta, testbara förväntningar som du kan utforma kontroller och bevis kring. Dessa mål ger dig ett ramverk för att förklara kontrollen för ditt team och för revisorer. Tolkningar från molnfokuserade ISO 27001-utövare grupperar vanligtvis A.5.23-krav i teman som molnpolicy, risk och krav, delat ansvar, livscykel och bevis, vilket är den metod som återspeglas här.

I praktiken förväntar sig A.5.23 att du gör fem saker konsekvent och kan bevisa dem. Ett användbart sätt att tolka kontrollen är att dela upp den i fem praktiska mål:

Molnpolicy och omfattning – definiera vad ”moln” betyder för din organisation, vilka tjänster och data som omfattas och vem som kan använda nya tjänster.
Risk och krav – identifiera molnspecifika risker såsom multitenancy, datalokalisering och anslutning, och fastställa minimikrav på säkerhet och integritet.
Delat ansvar – dokumentera vem som är ansvarig för viktiga kontroller hos leverantör, MSP och kund för varje större plattform och tjänst.
Livscykelhantering – bygga in säkerhet i urval, onboarding, förändring, övervakning och avyttring av molntjänster, inte bara i kontrakt.
Bevis och förbättring – föra register som visar att dessa processer fungerar och granska dem allt eftersom plattformar, kunder och regelverk ändras.

Tillsammans förvandlar dessa mål A.5.23 från en enda mening till en uppsättning vanor. De ger dig också en struktur för att kartlägga kontrollen i din tillämplighetspolicy och ditt bredare ISMS. Att registrera mål, ägare och stödjande bevis i ett system som ISMS.online hjälper dig att hålla dem konsekventa allt eftersom tjänster och standarder utvecklas.

Hur A.5.23 utökar den äldre leverantörsmodellen

A.5.23 utökar den äldre leverantörsmodellen genom att erkänna att molnet är en teknisk grund, inte bara ytterligare ett outsourcingavtal. När dina tjänster är beroende av delade plattformar påverkar dina konfigurations-, åtkomst- och driftsval starkt säkerhetsresultaten, även om den underliggande infrastrukturen tillhör någon annan.

Jämfört med generiska leverantörskontroller inom områden som leverantörshantering och driftssäkerhet, A.5.23:

Betonar molntjänstens livscykel, inte bara leverantörsvalet.
Förväntar sig uttrycklig hänsyn till delat ansvar och flerbostadshushåll.
Fokuserar på hur du kommer att avsluta eller ersätta molntjänster utan att förlora kontrollen över data.

Dessa betoningar återspeglas i specialiserade A.5.23-kommentarer och kartläggningar av molnkontroll, som lyfter fram livscykel, delat ansvar och exitplanering som skiljer sig från traditionell leverantörsövervakning. För MSP:er ingår A.5.23 även tillsammans med åtkomstkontroll, tillgångshantering, incidenthantering och andra kontroller i bilaga A. Målet är inte att duplicera arbete, utan att se till att era befintliga kontroller fullt ut tar hänsyn till molnet och hur ni levererar tjänster.

Att tydligt länka denna kontroll till ert ISMS hjälper revisorer att se att molnstyrning är integrerad och inte behandlas som ett separat spår.

Dokumenttyper som revisorer förväntar sig att se

Dokumenttyper som revisorer förväntar sig att se för A.5.23 är de som bevisar att era molnpolicyer, processer och ansvarsområden är verkliga, konsekventa och tillämpade. De kommer att leta efter en liten, sammanhängande uppsättning artefakter snarare än en stor mängd löst relaterade dokument. Implementeringsguider för molnstyrning för A.5.23 pekar ofta på en kombination av policyer, tjänsteregister, riskbedömningar och livscykelregister som den centrala bevisuppsättning som revisorer förväntar sig.

Under en revision kommer du sannolikt att bli ombedd att lämna ut bevis såsom:

En policy för molnanvändning eller molnsäkerhet.
Ett register över molntjänster som används internt och för kunders räkning.
Molnspecifika riskbedömningar och behandlingsplaner.
Due diligence-register för viktiga molnleverantörer och underleverantörer.
Matriser för delat ansvar eller motsvarande rolldefinitioner.
Rutiner eller handböcker för onboarding och avgång från tjänster.
Exempel på loggar, recensioner eller ärenden som visar att dessa processer fungerar.

Om du kan hitta dessa snabbt, och de berättar en enhetlig berättelse, kommer A.5.23 att kännas kontrollerad och proportionerlig. Om de bara finns i spridda dokument eller i människors huvuden, blir kontrollen en källa till fynd och extra arbete. Att använda en ISMS-plattform som ISMS.online för att samla dessa artefakter på ett ställe gör det mycket enklare att visa hur molnet hanteras i praktiken.

ISMS.online ger dig ett försprång på 81 % från det ögonblick du loggar in

ISO 27001 på ett enkelt sätt

Vi har gjort det hårda arbetet åt dig, vilket ger dig ett försprång på 81 % från det ögonblick du loggar in. Allt du behöver göra är att fylla i tomrummen.

Att börja

MSP:ns dubbla liv: molnkund och leverantör

Din MSP har ett dubbelt liv enligt A.5.23: du är både en krävande molnkund hos uppströmsleverantörer och en ansvarig molnleverantör gentemot dina egna kunder. Kontrollen förväntar sig att du förstår, dokumenterar och styr båda rollerna, inklusive hur de interagerar över den delade ansvarskedjan.

Som molnkund förlitar du dig på hyperskaliga plattformar och SaaS-verktyg för att driva din egen verksamhet och leverera tjänster. Som molnleverantör ser dina kunder dig som den part som ansvarar för säkerhet, kontinuitet och support, även när den underliggande tekniken tillhör någon annan. A.5.23 sammanför dessa två perspektiv och ber dig att hantera dem sammanhängande.

Förstå dina roller uppströms och nedströms

Att förstå dina roller uppströms och nedströms innebär att du inser att du konsumerar molntjänster som en intern kund samtidigt som du säljer molnbaserade tjänster som leverantör till dina egna kunder. A.5.23 förväntar sig att du har båda perspektiven i sikte och säkerställer att de stöder, snarare än motsäger, varandra.

Som en molnkund, du konsumerar tjänster som produktivitetssviter, ärendehantering, övervakningsplattformar och publik molninfrastruktur. Du ansvarar för hur dessa tjänster konfigureras, vem som har åtkomst och hur de övervakas. När incidenter inträffar eller tillsynsmyndigheter ställer frågor beror din förmåga att visa kontroll på hur väl du hanterar den konsumtionen och hur tydligt den är kopplad till dina ISMS-processer, såsom riskbedömning och förändringshantering.

Som en molnleverantör eller -hanterare, du designar, levererar och supporterar tjänster som körs på dessa plattformar. Du kanske säljer hanterad infrastruktur, säkerhetskopiering, SOC, applikationshosting eller säkerhetstjänster. Dina kunder ser dig som den ansvariga parten, även när du bygger på ett tredjepartsmoln. De skiljer inte mellan din tjänst och den hyperskalare den körs på; de antar att du har tagit hand om detaljerna.

En vanlig feljustering uppstår när du gör åtaganden till kunder om logglagring eller säkerhetskopieringshistorik, men ett uppströmsverktyg fortfarande körs med standardinställningen, en mycket kortare inställning. I så fall har ditt nedströmsåtagande överträffat din uppströmskonfiguration, och A.5.23 kommer att avslöja den luckan.

Att bygga en syn på dubbelt ansvar

Att bygga en dubbelrollsansvarssyn innebär att kartlägga ansvarsområden mellan leverantörer, era MSP-team och kunder i en enda, sammanhängande modell. Detta ger er CISO, chef för tjänsteleverans och kundansvariga en gemensam bild av vem som äger vad i hela kedjan.

Ett praktiskt sätt att göra detta är att skapa en ansvarsmatris med dubbla roller. Över viktiga kontrollområden – identitets- och åtkomsthantering, konfiguration, loggning, säkerhetskopiering, incidenthantering, ändringskontroll, dataskydd – listar du:

Vad dina uppströmsleverantörer åtar sig.
Vad du, som MSP, åtar dig att göra uppströms (till exempel att aktivera vissa funktioner, hantera vissa risker).
Vad ni förbinder er till nedströms i era kundkontrakt och SLA:er.
Vad du förväntar dig att kunderna ska göra själva.

Denna övning avslöjar ofta felaktigheter: skyldigheter gentemot kunder som inte har någon uppströms support, eller antaganden om leverantörer som inte backas upp av deras avtal. Den klargör också var det behövs starkare kontroller, tydligare formuleringar eller olika tjänstedesigner. När du bygger in denna syn i en ISMS-plattform som ISMS.online ger du teamen en enda källa till sanning om delat ansvar.

Att omsätta ansvarskartor i daglig praktik

Att omsätta ansvarskartor i daglig praxis innebär att se till att alla som berör molntjänster förstår de delar som gäller för dem och kan agera snabbt utifrån dem. Kartorna bör forma beteenden inom försäljning, teknik, support och kundhantering.

Att göra ansvarskartor verkliga innebär:

Använda dem för att informera sälj- och kundteam, så att de inte lovar för mycket eller improviserar utfästelser.
Anpassa runbooks och playbooks till de ansvarsområden ni har definierat, så att tekniska team agerar konsekvent.
Utbilda ingenjörer i hur och när de ska utöva sina rättigheter hos kundhyresgäster, inklusive tidsbundna upphävanden och godkännanden.
Överenskommelse om hur incidenter som involverar leverantörer ska kommuniceras och hanteras med kunder, inklusive eskaleringsvägar.

När ert dubbla rollperspektiv är integrerat på detta sätt, slutar A.5.23 att vara ett abstrakt krav och blir en naturlig bild av hur er MSP fungerar i molnet. Det ger er också en tydlig berättelse för styrelser och kunder som vill förstå er plats i den delade ansvarskedjan.

En praktisk modell för delat ansvar för MSP-molnplattformar

En praktisk modell för delat ansvar för MSP-molnplattformar är en uppsättning tydliga matriser som visar vem som gör vad för leverantör, MSP och kund för varje tjänst. Enligt A.5.23 förvandlar dessa matriser idén om delat ansvar till något som du kan driva, lära ut och granska.

De flesta leverantörer av publika moln beskriver en enkel uppdelning: de säkrar infrastrukturen; du säkrar det du bygger på den. Det mönstret är dokumenterat i förklaringar av delade ansvarsmodeller från stora leverantörer som AWS, Azure och Google Cloud, och det har blivit en vanlig baslinje för design av molnkontroll. För MSP:er är det bara startpunkten. Du behöver modeller som återspeglar de specifika plattformar du använder, de tjänster du erbjuder och hur dina team faktiskt arbetar.

Att gå bortom det allmänna "gemensamma ansvaret"

Att gå bortom generiska etiketter för "gemensamt ansvar" innebär att vaga påståenden ersätts med specifika, namngivna uppgifter som individer och team förstår. A.5.23 belönar denna tydlighet eftersom revisorer och kunder kan se vem som är ansvarig för verkliga handlingar, inte bara abstrakta koncept.

Generiska etiketter för "gemensamt ansvar" döljer verkliga risker. För att komma förbi dem måste du överväga:

De specifika plattformar du använder (till exempel infrastruktur som en tjänst, programvara som en tjänst, hanterade säkerhetsverktyg).
De specifika tjänster du erbjuder (till exempel hanterad säkerhetskopiering, hanterad SOC, hanterad modern arbetsplats).
Hur ditt team faktiskt arbetar (till exempel användning av automatisering, centraliserad övervakning, underhållsfönster).

För varje kombination av plattform och tjänst bör en ansvarsmatris definiera ansvarsområden tillräckligt detaljerat för att personer ska kunna agera. Det innebär att utse vem som möjliggör loggning, vem som testar återställningar, vem som hanterar begäranden om åtkomst till uppgifter och vem som leder incidentkommunikationen, snarare än att bara ange "delat".

Att ta detta extra steg stöder även relaterade kontroller, såsom incidenthantering och driftsäkerhet, eftersom alla kan se var deras roll börjar och slutar.

Strukturera dina ansvarsmatriser

Att strukturera dina ansvarsmatriser väl innebär att använda en konsekvent layout som speglar hur dina ingenjörer och servicechefer tänker, samtidigt som den är tillräckligt detaljerad för att vägleda åtgärder. En enkel struktur, som upprepas över olika tjänster, gör utbildning och granskning mycket enklare.

En praktisk matris för varje tjänst kan omfatta områden som:

Identitets- och åtkomsthantering: – vem som skapar och återkallar konton, hanterar roller och granskar åtkomst.
Konfiguration och härdning: – vem som tillämpar baslinjer, hanterar säkerhetsuppdateringar och granskar konfigurationsavvikelser.
Loggning och övervakning: – vem som aktiverar loggar, lagrar dem, granskar varningar och reagerar på incidenter.
Säkerhetskopiering och återhämtning: – vem konfigurerar säkerhetskopior, testar återställningar och verifierar återställningsmål.
Dataskydd och integritet: – vem som klassificerar data, tillämpar lagringsregler och hanterar registrerades rättigheter.
Kontinuitet och utgång: – vem som ansvarar för återhämtningsmönster, redundansväxling och dataexport eller radering vid kontraktets slut.

För varje rad bör matrisen tydligt markera ansvarsområden: leverantör, MSP, kund eller delad med specifika tilldelade uppgifter. Du bör också se till att varje matris är versionskontrollerad och granskas när tjänster, plattformar eller kontrakt ändras, så att den förblir korrekt över tid.

Ett förenklat exempel på hanterad säkerhetskopiering på en publik molnplattform kan se ut så här:

Domän	Leverantörens / MSP:ens / Kundens ansvar
Säkerhetskopieringskonfiguration	Leverantören erbjuder funktioner; MSP konfigurerar policyer; omfattning av kundrecensioner
Återställ testning	MSP utför regelbundna tester och återställningar; kunden validerar dataens fullständighet
Inställningar för lagring	Leverantören tillämpar gränser; MSP fastställer lagring; kunden godkänner policyn

Du kan sedan återanvända dessa matriser mellan kunder som använder samma servicemönster och bara justera där det verkligen är nödvändigt.

Koppla modellen till ditt ISMS och dina kunder

Genom att koppla den delade ansvarsmodellen till era ISMS och kunder säkerställer ni att den påverkar beslut från förhandsförsäljning till avstängning snarare än att den står isolerad. Ju mer ni kopplar den, desto mer användbar och trovärdig blir den.

När du har definierat dessa modeller, koppla dem:

Internt, genom att referera till dem i policyer, procedurer, runbooks och utbildning.
Kommersiellt, genom att anpassa era tjänstebeskrivningar, förslag och SLA:er med de ansvarsområden ni har satt.
Med kunder, genom att dela förenklade vyer eller diagram under introduktionen, så att förväntningarna är tydliga från dag ett.

När en revisor frågar hur ni hanterar delat ansvar enligt A.5.23 kan ni peka på dessa matriser, deras kopplingar till ert ISMS och exempel på hur de har väglett verkliga beslut. När en kund, till exempel en CISO eller IT-chef, frågar ”vem äger denna kontroll?”, har ni ett svar som är konsekvent i hela verksamheten. En central plattform som ISMS.online kan innehålla dessa matriser tillsammans med risker, kontroller och kontrakt så att de är enkla att underhålla och dokumentera.

Bädda in, utöka och skala upp er efterlevnad utan krångel. IO ger er motståndskraften och självförtroendet att växa säkert.

Boka din demo

Utforma molntjänstlivscykelprocesser för A.5.23

Livscykelprocesser för molntjänster är hur du bevisar att A.5.23 är mer än ett policyuttalande: de visar att du väljer, kör och tar bort molntjänster på ett kontrollerat och repeterbart sätt. För en MSP är målet att väva in molnlivscykelsteg i dina befintliga ISMS-processer, inte att skapa en separat byråkrati.

A.5.23 förväntar sig att ni visar att molntjänster följer definierade steg från idé till avyttring, med säkerhet och delat ansvar beaktat i varje steg. Detta överensstämmer nära med kontrollmyndighetens eget språk kring "förvärv, användning, hantering och avyttring" av molntjänster i linje med informationssäkerhetskrav, och med vanliga livscykelmodeller som används i ISO 27001 och molnstandardvägledning, såsom kommentarer till ISO 27001 A.5.23. Detta överensstämmer naturligt med ISO 27001-klausuler om riskhantering, operativ planering, förändringshantering och leverantörshantering.

Definiera en molntjänstlivscykel som människor kan följa

Att definiera en livscykel för molntjänster som människor kan följa innebär att omvandla A.5.23 till en liten uppsättning repeterbara steg som passar era befintliga arbetssätt. Livscykeln bör vara tillräckligt enkel för att produktägare, ingenjörer och inköpsteam kan tillämpa den utan specialistkunskaper. Två tredjedelar av organisationerna i 2025 års ISMS.online-undersökning om informationssäkerhetens tillstånd säger att hastigheten och volymen av regelförändringar gör det svårare att upprätthålla efterlevnaden.

En typisk livscykel för betydande molntjänster kan innefatta steg som:

Idé och bedömning – någon föreslår en ny molntjänst eller ett nytt sätt att använda en befintlig. Du granskar den med avseende på affärsvärde, säkerhet och efterlevnad.
Urval och due diligence – du kontrollerar certifieringar, dataplatser, avtalsvillkor och supportmöjligheter och jämför alternativ.
Design och introduktion – du bestämmer hur tjänsten ska konfigureras, integreras och övervakas, och vem som ska äga den.
Drift och förändring – du driver tjänsten, granskar loggar och mätvärden, hanterar ändringar och incidenter och ser till att konfigurationen är i linje med dina standarder.
Granskning och förnyelse – ni granskar regelbundet om tjänsten fortfarande uppfyller behoven, om riskerna är acceptabla och om förbättringar behövs.
Utgång eller ersättning – om du stänger av eller ersätter tjänsten hanterar du dataexport, radering och kundkommunikation.

Dessa steg gör att beslut om molntjänster kan upprepas istället för att fattas ad hoc. För var och en, definiera de lägsta åtgärder, godkännanden och register som du förväntar dig. Det kan inkludera riskbedömningar, checklistor för due diligence, konfigurationsbaslinjer, ändringsregister och bekräftelser på avslut, allt i linje med ditt centrala ISMS.

För att göra detta ännu mer användbart kan du uttrycka livscykeln som en enkel uppsättning steg som teamen ska följa.

Steg 1: Sammanfatta och granska idén

Registrera och granska varje molntjänstidé innan någon registrerar sig eller integrerar den, så att ni kan väga värde, risk och anpassning till era ISMS.

Registrera den föreslagna molntjänsten, dess syfte och initiala risker innan någon registrerar sig eller integrerar den.

Steg 2: Slutför due diligence och design

Fullständig due diligence och design innan en molntjänst implementeras, så att konfiguration, övervakning och ansvar definieras snarare än improviseras.

Kontrollera garantier, kontrakt och datahantering, och definiera sedan konfiguration, övervakning och delat ansvar.

Steg 3: Ombordstigning, manövrering och planering av utfart

Ombordställ, driv och planera avfärd på ett strukturerat sätt, så att du kan bevisa hur tjänsten kontrolleras under hela dess livslängd.

Installera tjänsten enligt era baslinjer, övervaka den och dokumentera hur ni kommer att avsluta eller ersätta den på ett säkert sätt.

Integrera livscykelkontroller i hur du arbetar

Att integrera livscykelkontroller i hur ni arbetar innebär att integrera dem i processer och verktyg som era team redan använder. När livscykeln är standardvägen blir det mycket enklare att upprätthålla efterlevnaden av A.5.23.

Överväga:

Anpassa det till upphandlingsarbetsflöden, så att kontrakt inte kan undertecknas förrän säkerhets-, integritets- och driftskrav har kontrollerats.
Koppla det till din tjänsteintroduktionsprocess, så att nya erbjudanden eller större förändringar går igenom molnlivscykelns grindar.
Integrera livscykeluppgifter i era ärende- och ändringssystem, inte bara i separata molndokument.

Genom att koppla livscykelsteg till etablerade processer som förändringsledning och leverantörshantering minskar du friktionen och förbättrar implementeringen. Människor följer livscykeln eftersom det är minst motstånds väg, inte för att de har blivit tillsagda att läsa en annan policy.

Förbereda livscykelbevisrevisioner

Att göra livscykelbevis redo för revision innebär att kunna visa några kompletta exempel som visar samma logik tillämpad på olika tjänster. Revisorer vill se mönster, inte engångsframgångar.

För varje exempel, försök att visa:

Varför tjänsten valdes, baserat på risk och krav.
Hur ansvar definierades, med hjälp av er modell för delat ansvar.
Vilka kontroller som implementerades vid onboarding, inklusive baslinjer och åtkomstmönster.
Hur tjänsten övervakas och granskas, med exempel på förändringar eller förbättringar.
Hur data och åtkomst skulle hanteras vid avslut, även om avslutet ännu inte har skett.

Om du kan ta fram dessa bevis utan större krångel kommer A.5.23 att kännas inbäddat snarare än påböjt. Ett system som ISMS.online kan hjälpa till genom att länka tjänster, risker, ansvar, ändringar och avgångsregister på ett ställe, så att du inte behöver sätta ihop bilden från grunden varje gång någon frågar.

Tekniska kontroller för flera hyresgäster: Implementering av konsekventa skyddsåtgärder

Tekniska kontroller för flera hyresgäster är det praktiska uttrycket för era A.5.23-molnstyrningsbeslut i det dagliga ingenjörsarbetet. De omsätter modeller för delat ansvar och livscykelprocesser till konkreta baslinjer som skyddar många kunder samtidigt.

När du hanterar flera hyresgäster på gemensamma plattformar förväntar sig A.5.23 att du har en proaktiv, standardiserad strategi för identitet, konfiguration, loggning, säkerhetskopiering och isolering. På så sätt kan du visa att dina tekniska skyddsåtgärder matchar det ansvar du har accepterat och de åtaganden du gör gentemot kunderna.

Varför baslinjer för flera hyresgäster är viktiga

Baslinjer för flera hyresgäster är viktiga eftersom små svagheter kan få stora konsekvenser för många kunder samtidigt. En enda alltför tillåtande roll, missad uppdatering eller otestad säkerhetskopiering kan undergräva er övergripande molnsäkerhetsnivå. Ramverk för molnsäkerhet och nationella riktlinjer, såsom riskdiskussioner för flera hyresgäster i kontrollkataloger och molnsäkerhetssamlingar från nationella cybersäkerhetscenter, belyser konsekvent identitetshantering, patchning och säkerhetskopiering som systemiska riskområden som snabbt kan skalas över hyresgäster när de misslyckas. En majoritet av organisationerna i 2025 års ISMS.online-undersökning rapporterade att de drabbats av minst en säkerhetsincident från tredje part eller leverantör under det senaste året.

I en MSP-miljö kan ett överprivilegierat administratörskonto, en ologgad kritisk åtgärd eller en oprövad säkerhetskopieringsprocess påverka dussintals kunder i en och samma incident. A.5.23 förväntar sig att ni hanterar dessa risker systematiskt, inte reaktivt, och att ni kan visa hur era kontroller tillämpas på de molntjänster ni använder och tillhandahåller. Konsekventa baslinjer definierar de minimikontroller som finns på plats för alla kunder som använder en given plattform eller tjänst och ger revisorer och kunder förtroende för att ni inte uppfinner säkerheten på nytt varje gång.

Ur ett ledarskapsperspektiv ger dessa baslinjer också en trygghetsnivå: ni kan visa styrelser och kunder att tekniska skyddsåtgärder överensstämmer med de styrnings- och avtalsenliga beslut ni redan har fattat.

Kärntekniska teman att standardisera

Kärntekniska teman att standardisera är de områden där konsekventa skyddsåtgärder minskar sannolikheten för problem mellan hyresgäster och ger ingenjörer en tydlig utgångspunkt på varje plattform.

Även om detaljerna varierar beroende på plattform, gynnas de flesta MSP:er av att standardisera åtminstone följande teman. Detta gör det lättare för säkerhetschefen, driftsledaren och teknikteamen att dra åt samma håll.

Identitets- och åtkomsthantering: – rollbaserad åtkomst, lägsta möjliga privilegier, arbetsuppdelning, tidsbunden befordran för högriskåtgärder och robust offboarding.
Konfiguration och härdning: – baslinjemallar för nätverkssegmentering, kryptering, slutpunktsskydd, patchpolicyer och namngivning av resurser.
Loggning och övervakning: – konsekventa loggkonfigurationer, central loggaggregation, definierade varningsregler och dokumenterade svarshandböcker.
Säkerhetskopiering och återhämtning: – standardiserade säkerhetskopieringsscheman, lagring, kryptering, testrutiner för återställning och dokumentation av klientens återställningsmål.
Isolering och hyresrätt: – mönster för att separera hyresgäster i nätverket, identitets- och datalager, och kontroller för att verifiera att isoleringen gäller.

Varje baslinje bör tydligt ange vad leverantören levererar, vad ni konfigurerar och underhåller, och vad ni förväntar er att kunderna ska göra. Tillsammans blir dessa teman den tekniska ryggraden i er A.5.23-implementering.

När du har definierat dessa teman är nästa steg att integrera dem där ingenjörerna arbetar: mallar, skript, infrastruktur som kod, centrala hanteringsverktyg och dokumenterade handböcker.

Anslutning av tekniska kontroller till A.5.23 och senare

Att koppla tekniska kontroller till A.5.23 och relaterade kontroller säkerställer att er styrning, era juridiska åtaganden och era tekniska metoder stöder varandra snarare än att demonteras. Denna samordning gör det lättare att förklara och försvara ert övergripande system.

Det betyder:

Mappa varje baslinjeelement till era matriser för delat ansvar, så att de tekniska kontrollerna matchar det ansvar ni har tilldelat.
Se till att baslinjer är en del av din molntjänsts livscykel, så att de tillämpas vid onboarding och ses över under granskningar.
Koppla teman som åtkomst, loggning och säkerhetskopiering till bilaga A-kontroller för åtkomstkontroll, driftssäkerhet, incidenthantering och affärskontinuitet.

Denna anpassning gör ert övergripande kontrollsystem sammanhängande. Det innebär också att när A.5.23 diskuteras under revisioner eller kundrecensioner är ni redo att visa inte bara policyer, utan även fungerande tekniska skyddsåtgärder som matchar er styrningsnivå. Om ni hanterar dessa baslinjer i ett centralt system som ISMS.online kan ni demonstrera kopplingen från en molntjänst, till dess riskbedömning, till dess tekniska kontroller, med några få klick.

ISMS.online stöder över 100 standarder och föreskrifter, vilket ger dig en enda plattform för alla dina efterlevnadsbehov.

Boka din demo

Kontrakt, SLA:er och klausuler för underbiträden som håller i granskning

Det är i kontrakt, servicenivåavtal och klausuler om underbiträden som era A.5.23-beslut om molnstyrning blir juridiskt bindande löften. Kontrollen förväntar sig att era avtal med leverantörer, underbiträden och kunder återspeglar det delade ansvaret, livscykeln och de tekniska val ni har gjort, snarare än att motsäga dem.

A.5.23 kräver inte att du skriver kontrakt på ett visst sätt, men revisorer och kunder kommer att testa om dina juridiska åtaganden och din tekniska verklighet stämmer överens. Principbaserad vägledning om A.5.23 och relaterade molnkontroller betonar rutinmässigt vikten av att anpassa avtalslöften till faktiska kontroller och modeller för delat ansvar, eftersom det är vid felaktig överensstämmelse som många revisionsresultat och tvister uppstår.

A.5.23 kräver inte att du skriver kontrakt på ett visst sätt, men revisorer och kunder kommer att testa om dina juridiska åtaganden och din tekniska verklighet stämmer överens. Om de inte gör det blir kontrollen en källa till risker och resultat.

Att tydliggöra ansvar och förväntningar i kontrakt och SLA:er innebär att översätta era interna ansvarsmatriser till tydliga och stabila formuleringar som alla inom juridik, försäljning och kunder kan förstå. A.5.23 är mycket lättare att bevisa när dessa dokument matchar hur ni faktiskt arbetar.

Det är i kontrakt och servicenivåavtal som missförstånd leder till tvister, särskilt när det gäller molntjänster. För att stödja A.5.23 bör era avtal:

Beskriv tjänsterna tydligt, inklusive eventuellt beroende av tredjeparts molnplattformar.
Ange säkerhets- och dataskyddsskyldigheter tillräckligt detaljerade för att vara meningsfulla, utan att lova vad du inte kan leverera.
Förklara vem som är ansvarig för vilka aspekter av incidentdetektering, respons och kommunikation.
Förtydliga vad som händer i slutet av kontraktet, inklusive export eller radering av data och eventuellt övergångsstöd.

Där det är möjligt, anpassa detta språkbruk direkt till domänerna i era matriser för delat ansvar, så att det finns en tydlig linje från modell till formulering. Detta bidrar också till att uppfylla relaterade ISO 27001-krav gällande juridiska, regulatoriska och avtalsenliga skyldigheter.

När ansvarsområdena är tydliga i både matriser och kontrakt har dina team mindre utrymme för motstridiga tolkningar när incidenter eller komplexa kundkrav uppstår.

Anpassa den tekniska verkligheten till rättsliga åtaganden

Att anpassa den tekniska verkligheten till juridiska åtaganden innebär att kontrollera att det ni lovar i kontrakt är uppnåeligt med era nuvarande verktyg, processer och baslinjer. Det minskar risken att kunder eller revisorer upptäcker luckor mellan ord och praxis. Endast cirka 29 % av organisationerna i ISMS.online-undersökningen 2025 uppgav att de inte hade fått några böter för dataskyddsbrister, där majoriteten rapporterade böter och vissa riskerade böter på över 250 000 pund.

Det är lätt att juridiska klausuler glider bort från den tekniska verkligheten med tiden. Kanske lovar en mall mycket snabb incidentrapportering, men era övervaknings- och eskaleringsprocesser gör det svårt i praktiken. Eller så åtar sig ett SLA att återställningsmål som inte matchar säkerhetskopieringsdesigner.

För att undvika detta, granska era kontrakt och servicenivåavtal gemensamt inom juridik, säkerhet, drift och kontohantering. Fråga:

Kan vi konsekvent uppfylla de åtaganden vi gör, med tanke på vår nuvarande övervakning, supporttider och tekniska baslinjer?
Finns det områden där vi behöver investera i bättre kontroller eller verktyg för att uppfylla dem?
Finns det skyldigheter som istället borde ligga hos kunden eller leverantören, och kommuniceras som sådana?

När era juridiska åtaganden och tekniska kapaciteter är i linje med varandra blir A.5.23 lättare att bevisa och mindre riskabelt att leva med. Ni minskar också sannolikheten för överraskningar för kunder, tillsynsmyndigheter eller revisorer som gräver i detaljerna bakom era löften.

Integrera styrning i era avtal

Att införliva styrning i era avtal innebär att använda avtalstexter för att förstärka hur ni vill att leverantörer och kunder ska bete sig, inte bara dokumentera tjänster och priser. Det kan göra delat ansvar och livscykeltänkande till en del av den dagliga relationen.

Det kan inkludera:

Rätt att få eller granska leverantörsförsäkran, såsom uppdaterade certifieringar eller oberoende rapporter.
Förväntningar kring deltagande i gemensamma incidenter eller kontinuitetsövningar.
Skyldighet att anmäla betydande förändringar av tjänster eller platser.
Krav på att följa överenskomna utträdesprocesser, inklusive tidslinjer och samarbete.

Genom att väva in dessa i era avtal säkerställer ni att styrning inte bara är en intern fråga. Den blir en del av hur ni, era leverantörer och era kunder arbetar tillsammans under tjänstens livslängd. När revisorer testar A.5.23 kan de se att livscykel och delat ansvar återspeglas konsekvent i era avtal, inte bara i era policyer.

Boka en demo med ISMS.online idag

Att boka en demo med ISMS.online är ett praktiskt sätt att se hur din MSP kan få kontroll över A.5.23-molnstyrning utan att öka komplexiteten för dina team. På ett ställe kan du se hur molntjänster, risker, ansvar, livscykelsteg och bevis kopplas samman, så att du är redo för revisioner, kundfrågor och styrelsegranskningar.

Du får kontroll över A.5.23-molnstyrningen när du ersätter spridda dokument och ad hoc-beslut med ett enda, sammanhängande system som länkar samman tjänster, risker, ansvar, livscykelsteg och bevis. För många MSP:er kan det vara ett praktiskt sätt att uppnå den konsolideringen genom att använda en specialbyggd ISMS-plattform som ISMS.online utan att öka komplexiteten.

ISMS.online hjälper dig att omvandla dina A.5.23-ansvar för molnstyrning till ett enda, sammankopplat system som kopplar samman molninventeringar, modeller för delat ansvar, livscykelarbetsflöden, kontrakt och bevis. Istället för att jaga dokument över enheter, konsoler och inkorgar kan du se hur molntjänster styrs och hur ansvar hanteras på ett ställe.

För MSP:er innebär det att ni kan visa revisorer, styrelser och kunder en tydligare och mer sammanhängande berättelse: vilka molntjänster ni använder, hur ansvaret delas, vilka kontroller som finns på plats och hur dessa arrangemang förändras över tid. Observatörer av styrnings-, risk- och efterlevnadsverktyg (GRC) noterar ofta att centraliserade plattformar gör den här typen av berättelse lättare att sammanställa och hålla konsekvent, eftersom de sammanför risker, kontroller och bevis i en miljö. Ni behåller kontrollen över besluten; plattformen hjälper er att bevisa den kontrollen, konsekvent, allt eftersom er verksamhet skalas upp och standarder utvecklas.

Se din molnlagring i en vy

Att se er molnlagring i en enda vy gör det enklare för er CISO, verksamhetschef och kundnära team att besvara svåra frågor utan problem. A.5.23 blir mindre av en efterlevnadsövning och mer ett enkelt sätt att beskriva hur ni verkligen arbetar.

När du centraliserar din molnstyrning i en ISMS-plattform ger du dig själv och ditt team en enda referenspunkt för A.5.23. Du kan:

Upprätthåll ett aktivt register över interna och klientvända molntjänster.
Koppla varje tjänst till risker, kontroller, ansvarsmatriser och livscykelfaser.
Bifoga kontrakt, due diligence, ändringsregister och avslutsbevis direkt till de tjänster de avser.

Tillsammans gör dessa funktioner det mycket enklare att svara på frågor från revisorer, kunders säkerhetsgranskningar och interna beslutsfattare som vill förstå hur molnet hanteras. Du behöver inte längre förlita dig på minne eller olika kalkylblad för att se din molnhantering.

Ta nästa steg med självförtroende

Om du känner igen din MSP i de utmaningar som beskrivs här – suddiga ansvarsområden, spridda bevis, växande press från kunder och revisorer – är det ett praktiskt nästa steg att utforska en plattform som ISMS.online i en kort, fokuserad demonstration. Trots växande press listar nästan alla respondenter i 2025 års undersökning om informationssäkerhetens tillstånd att uppnå eller bibehålla säkerhetscertifieringar som ISO 27001 eller SOC 2 som högsta prioritet.

Du kan se hur det stöder dina befintliga verktyg och arbetssätt samtidigt som det ger dig den struktur som A.5.23 förväntar sig.

Välj ISMS.online när du vill ha ett ställe att lagra ditt molntjänstregister, ansvarsområden, risker och bevis så att du kan visa, inte bara hävda, att A.5.23 är under kontroll. Om du värdesätter tydlig styrning, smidigare revisioner och en starkare plattform för kunder och styrelser, är vårt team redo att hjälpa dig att se hur det ser ut i din miljö.

Boka demo

Vanliga frågor om partihandel med mat och dryck

Vad förväntar sig ISO 27001:2022 A.5.23 egentligen av en MSP som använder molntjänster?

ISO 27001:2022 A.5.23 förväntar sig att din MSP ska aktivt styra hela livscykeln för varje molntjänst du förlitar dig på, inte bara samla in leverantörscertifikat och hoppas på det bästa. Du bör snabbt och konsekvent kunna visa vad du använder, varför du använder det, vad som kan gå fel, vem som äger vilka kontroller och hur du skulle avsluta utan att förlora data eller tjänster.

Hur ser "bra" A.5.23-bevis ut för en MSP?

Revisorer och engagerade kunder letar vanligtvis efter en litet, sammanhängande knippe av bevis, inte ett gigantiskt arkiv. För en MSP inkluderar kärnuppsättningen vanligtvis:

En tydlig molnanvändning / molnsäkerhetspolicy

Detta definierar vad som räknas som "moln" i er värld (IaaS, SaaS, PaaS, hanterade säkerhetstjänster), vem som kan godkänna nya tjänster och era minimikrav för konfiguration, övervakning och avslutning.

A molntjänstregister som omfattar:
interna verktyg (RMM, PSA, ärendehantering, fakturering, CRM, övervakning, säker filöverföring); och
kundvända tjänster (IaaS-plattformar, Microsoft 365 och andra SaaS-sviter, säkerhetskopiering/DR, SOC/XDR, hanterade brandväggar och WAF:er).

Molnspecifika riskbedömningar och behandlingar:

Dessa bör lyfta fram exponering mot flera hyresgäster, kraftfulla roller mellan hyresgäster, datalagring, leverantörslåsning, API-beroenden och nyckelhantering. Riskerna bör kopplas till verkliga kontroller och förbättringsåtgärder.

Due diligence-register: för viktiga leverantörer och underleverantörer

Vanligtvis inkluderar detta säkerhetssammanfattningar, certifieringar (till exempel ISO 27001, SOC 2), dataskyddsavtal, drifttidshistorik, dataintrångshistorik och kända begränsningar eller undantag som påverkar dina designer.

Matriser för delat ansvar:

För varje större tjänst, visa vad leverantören gör, vad din MSP gör och vad kunden måste göra. Språket bör vara tillräckligt konkret för att en ingenjör eller kund kan se "mina uppgifter" utan ett andra möte.

Livscykelposter för molntjänster:

Bevis på att urval, onboarding, konfiguration, ändring, regelbunden granskning och avgång hanteras på ett kontrollerat och repeterbart sätt snarare än genom ad hoc-ärenden.

Om dessa element är sammankopplade och lätta att navigera känns A.5.23 under kontroll och trovärdigt. Att använda ISMS.online för att hålla policyer, riskposter, leverantörsregister, ansvarsmatriser och livscykelbevis i en ISMS-arbetsyta innebär att du inte behöver rekonstruera din molnlagring från inkorgssökningar och konsolskärmdumpar varje gång en revisor eller kund tar upp klausulen.

Hur ska en MSP bygga en användbar modell för delat ansvar för molnet enligt A.5.23?

Du uppfyller avsikten med A.5.23 när ”delat ansvar” blir en karta över verkliga uppgifter tjänst för tjänst, inte bara en marknadsföringsbild som säger ”vi och leverantören bryr oss båda om säkerhet”. Alla som läser den – ingenjörer, säljare, kontraktsgranskare eller kunder – ska kunna se exakt vad de äger.

Hur förvandlar man ”delat ansvar” till något konkret?

Ett praktiskt mönster som fungerar bra för MSP:er är att:

1. Katalogisera dina molntjänster efter kategori

Börja med en kort lista med hinkar:

Publika molnarbetsbelastningar (IaaS/PaaS).
SaaS-produktivitetssviter (Microsoft 365, Google Workspace och liknande).
Hanterade tjänster för säkerhetskopiering och katastrofåterställning.
Hanterade SOC/XDR- och hotdetekteringstjänster.
Andra återkommande molnbaserade verktyg som du förlitar dig på för att driva din verksamhet eller leverera tjänster.

Den här listan speglar vanligtvis posterna i ditt molntjänstregister, vilket gör det enklare att hålla saker och ting i linje.

2. Välj en gemensam uppsättning säkerhetsdomäner

Välj en liten uppsättning domäner som gäller för de flesta av dina tjänster, till exempel:

Identitets- och åtkomsthantering.
Baslinjekonfiguration och härdning.
Loggning, övervakning och varning.
Säkerhetskopiering, återställning och testrutiner.
Kryptering och nyckelhantering.
Incidentdetektering, triage och respons.
Ändringshantering och godkännanden.
Datalagring, lagring och bortskaffande.

Att hålla sig till en standarduppsättning gör modellen lättare att förstå och återanvända över olika tjänster.

3. Tilldela ägarskap per domän, per tjänst

För varje tjänst och varje säkerhetsdomän, bestäm vem som faktiskt utför arbetet i praktiken:

Molnleverantör: – infrastrukturens motståndskraft, fysisk säkerhet, de flesta underliggande plattformspatchar, vissa logglagringsalternativ.
Din MSP: – baslinjer för hyresgästkonfiguration, varningsrouting, säkerhetskopieringsscheman, återställningstestning, incidentsortering, kundrapportering.
kund: – användarbeteende, acceptabel användning, dataklassificering, åtkomstgodkännande, beslut om innehållslivscykeln.

Där ansvaret delas, skriv ner fördelningen som specifika uppgifter, inte vaga "led"-etiketter. Till exempel:

"Kunden godkänner lagringsperioden; MSP implementerar och granskar konfigurationen kvartalsvis."
”MSP granskar säkerhetsaviseringar; leverantören hanterar incidentrespons på plattformsnivå.”

4. Integrera modellen i den dagliga verksamheten

En ansvarsmatris spelar bara roll om den dyker upp där människor arbetar. Se till att du:

Referera till det i runbooks och playbooks, så att ingenjörer kan se vad de ska göra vid incidenter och förändringar.
Justera standardtjänstbeskrivningar och SoW:er med det, så att försäljningen inte lovar uppgifter du inte utför.
Reflektera det i kontrakt och SLA:er, så att rättsliga åtaganden matchar den tekniska verkligheten och uppströmsleverantörens kapacitet.
Inkludera det i introduktionspaket, så att nya kunder förstår vilka åtgärder som stannar hos dem och vilka som stannar hos dig.

Att hantera dessa matriser centralt i ISMS.online – länkade till tjänster i ditt molnregister, riskposter och leverantörsregister – låter dig uppdatera en matris en gång och låta ändringen sprida sig till runbooks, dokumentation och revisionsbevis. Det gör det mycket enklare att visa att A.5.23 fungerar i praktiken, inte bara i ett policydokument.

Vilka molnspecifika risker belyser A.5.23 för MSP:er, och var tenderar de att glida?

För MSP:er handlar A.5.23 mindre om generiska berättelser om "molnintrång" och mer om felaktiga förväntningar, konfigurationsbrister och dålig livscykelkontroll över delade miljöer. Problem tenderar att uppstå där era marknadsföringslöften, leverantörens kapacitet och teamets beteenden inte stämmer överens.

Var blir MSP:er oftast överraskade?

Mönster som upprepade gånger orsakar problem inkluderar:

Överdriven beroende av antaganden om leverantörssäkerhet

Det är lätt att tala om "säker genom design" samtidigt som man antar att uppgifter som återställningstestning, logggranskning, hotjakt eller härdning på hyresgästnivå ingår i en molnprenumeration. I verkligheten är många av dessa aktiviteter ditt ansvar som MSP, och ibland delvis din kunds. När de inte registreras i dina ansvarsmatriser och runbooks körs de sällan konsekvent.

Överdriven, dåligt styrd privilegierad åtkomst

MSP:er har ofta kraftfulla roller – globala administratörskonton, partnerportaler, "breakglass"-identiteter – som spänner över många hyresgäster. Om dessa rättigheter saknar starkt godkännande, loggning och granskning kan en enda komprometterad autentiseringsuppgift eller ett missbrukat konto bli en betydande incident med flera hyresgäster. A.5.23 förväntar sig att ni identifierar den risken i era tillgångs- och riskregister och inför tydliga kontroller kring den.

Oregistrerad eller "skugg"-SaaS

Team använder SaaS-verktyg som hanterar känslig data eller kunddata – för support, samarbete, utveckling, försäljning eller automatisering – utan att någonsin lägga till dem i era ISMS, leverantörsregister eller riskprocesser. Dessa tjänster faller sedan utanför era övervaknings-, incidenthanterings- och exitplaner.

Svaga eller oprövade exitplaner

Många MSP:er tänker bara på att lämna leverantören när en leverantör tillkännager en produktpensionering, en större prisändring eller ett avbrott. Utan en dokumenterad avvecklingsplan – inklusive dataexport, migrering, bevislagring och kundkommunikation – improviserar du vid den punkt där du behöver mest kontroll.

SLA:er som lovar för mycket

Kontrakt binder dig ibland till återställningsmål, lagringsperioder eller specifika datalagringskrav som den underliggande stacken inte kan garantera. När tjänstedesignen, molnleverantörens funktioner och kontraktstexten inte matchar bär du onödiga risker.

A.5.23 ger dig ett ramverk för att systematiskt hantera dessa problem:

Inventera och klassificera molntjänster: så att du vet var risken koncentreras.
Utföra molnspecifika riskbedömningar som åtgärdar problem med flera hyresgäster, privilegierad åtkomst och leverantörsfellägen.
Bibehålla ansvarsmatriser så uppgifter tilldelas, ägs och granskas.
Bevis livscykelsteg – från onboarding till exit – så att folk kan se att förändringar, granskningar och exits är kontrollerade händelser, inte reaktioner.

När du kan spåra en risk – till exempel överdriven åtkomst till partnerportaler – från ditt register till ansvarsmatriser, och sedan till ändringar i register och förbättringsåtgärder, uppfyller du inte bara kraven i A.5.23; du presenterar också en betydligt starkare molnriskrapport för revisorer och kunder.

Hur kan en MSP dokumentera A.5.23 i sitt ISMS utan att omdesigna allting?

Du kan vanligtvis täcka A.5.23 genom att lägga till molnspecifik styrning på dina befintliga ISMS, snarare än att bygga en parallell struktur. Målet är att alla som är bekanta med ISO 27001 ska kunna följa hur ni väljer, kontrollerar och tar bort molntjänster lika enkelt som de kan följa traditionella tillgångar eller leverantörer.

Hur väver ni in molnstyrning i det ni redan har?

Ett enkelt men effektivt mönster är att börja med tre sammankopplade komponenter och sedan ansluta dem till ditt befintliga ISMS:

1. Molnanvändning / molnsäkerhetspolicy

Utöka er befintliga informationssäkerhetspolicy med ett fokuserat dokument som:

Definierar vad som kvalificerar som en molntjänst i ditt sammanhang.
Anger tröskelvärden för godkännande (till exempel vem som kan auktorisera en ny leverantör).
Anger förväntningar på due diligence, konfigurationsbaslinjer, övervakning, incidenthantering och avslut.

Denna policy blir ankaret för relaterade procedurer och register.

2. Molntjänstregister

Skapa ett register – ofta en ISMS.online-tillgångs- eller leverantörslista – som åtminstone registrerar:

Tjänstens namn och leverantör.
Intern ägare.
Affärssyfte.
Hanterade datatyper och dataplatser.
Kritisk betydelse och inverkan av förlust.
Länkar till kontrakt, dataskyddsavtal, certifieringar och ansvarsmatriser.

Du kan integrera detta med ditt befintliga tillgångsinventarium så att molntjänster inte finns i ett separat universum.

3. Matriser för delat ansvar

För de tjänster som är viktigast, bygg och underhåll ansvarsmatriser enligt beskrivningen tidigare. Fokusera initialt på:

Din primära publika molnplattform.
Din huvudsakliga SaaS-produktivitets- och samarbetssvit.
Ditt flaggskeppserbjudande för hanterad säkerhetskopiering/DR.
Dina hanterade SOC/XDR eller liknande säkerhetslösningar som en tjänst.

Du kan sedan koppla dessa komponenter till de ISMS-element du redan använder:

Riskhantering: – länka molntjänster till riskposter och -behandlingar, särskilt där det finns scenarier med flera hyresgäster eller leverantörsfel.
Leverantörshantering: – bifoga avtal, säkerhetssammanfattningar, dataskyddsavtal och revisionsrapporter till berörda leverantörer; dokumentera regelbundna granskningar och beslut.
Driftskontroller: – referera till molnspecifika onboarding-, förändrings-, gransknings- och avslutningssteg inom era befintliga processer för förändringshantering och incidenthantering.
Bevishantering: – länka incidenter, resultat av säkerhetskopieringstest, åtkomstgranskningar och förbättringsåtgärder tillbaka till relevanta molnposter och risker.

Genom att använda fungerande exempel – till exempel en intern SaaS, en kundorienterad lösning byggd på ett publikt moln och en nischad men kritisk plattform – kan du visa revisorer att mönstret är upprepningsbart utan att behöva dokumentera varje mindre tjänst individuellt. ISMS.online är utformat för denna typ av modellering: policyer, register, risker, leverantörer, uppgifter och bevis sitter ihop, med länkar som gör bilden av molnstyrningen lätt att följa.

Vilka kontrakt och SLA:er bör en MSP anpassa för att demonstrera A.5.23 för kunder?

För att övertygande demonstrera A.5.23 behöver du både dina uppströms- och nedströmsavtal för att matcha hur ni faktiskt hanterar molnrisker. Det innebär att era kontrakt och servicenivåavtal med leverantörer och underleverantörer, och era villkor med kunder, alla bör peka på samma ansvarsfördelningar och kapaciteter som ni dokumenterar i era ISMS.

Vad bör du kontrollera i avtal med leverantörer uppströms och underbiträden?

Granska de delar av varje avtal som direkt påverkar dina tjänster och anspråk:

Säkerhets- och tillgänglighetsåtaganden: – säkerställa att RPO/RTO-mål, drifttids-SLA:er och datahållbarhet överensstämmer med hur ni utformar tjänster och löftena i era egna SLA:er.
Utlåtanden om dataplats och bosättning: – du ska kunna svara på frågan ”var finns våra data?” med säkerhet, inklusive platser för säkerhetskopiering och redundansregioner.
Incidentanmälan och eskalering: – kontrollera hur och när leverantörer åtar sig att informera dig om incidenter som kan påverka dina kunder.
Stöd för viktiga kontroller: – bekräfta om funktioner som detaljerad loggning, kundhanterade krypteringsnycklar, oföränderliga säkerhetskopior eller avancerade åtkomstkontroller som du förlitar dig på är explicit tillgängliga och stöds.
Säkerhetsmekanismer: – identifiera certifieringar, revisionsrapporter, sammanfattningar av penetrationstester eller avtalsenliga revisionsrättigheter som ni kan använda som bevis inom era egna ISMS och kundrapportering.

Ni kanske inte behöver omförhandla varje kontrakt, men ni bör förstå och dokumentera var en leverantörs åtaganden inte uppfyller era nuvarande tjänstebeskrivningar, och justera era egna erbjudanden eller arkitekturer därefter.

Hur bör kundkontrakt och SLA:er ändras för att återspegla A.5.23?

Nedströms bör dina kundvända dokument:

Identifiera tydligt vilka tjänster är beroende av vilka molnplattformar, särskilt där det påverkar datalokalisering, motståndskraft eller support.
Förklara vem ansvarar för vilka kontrollområden – såsom godkännanden av användaråtkomst, acceptabel användning, klassificering, juridiska reservationer och innehållslivscykel – i linje med era matriser för delat ansvar.
Åta sig återställningsmål, lagringsperioder och tidsramar för incidentkommunikation som era uppströmsavtal och designlösningar kan leverera på ett tillförlitligt sätt.
Referens, eller länk till, information om ansvar och beroende på ett sätt som kunderna kan förstå utan att läsa ert ISMS.

När uppströmskontrakt, interna ansvarsmatriser och nedströms SLA:er alla berättar samma sak är det mycket enklare att guida en kund eller revisor genom hur ni hanterar molnrisker enligt A.5.23. Att hantera dessa dokument inuti ISMS.online, tillsammans med era policyer och risker, hjälper er att hålla berättelsen i linje i takt med att leverantörer uppdaterar sina villkor, regler utvecklas och kunderna blir mer krävande.

Hur kan en MSP använda ISMS.online för att hålla A.5.23 under kontroll när molntjänster förändras?

ISMS.online hjälper dig att hålla A.5.23 under kontroll genom att förvandla molnstyrning till en kontinuerligt uppdaterat, uppkopplat system, snarare än en uppsättning statiska dokument som halkar efter ändringar i din stack. När du antar, modifierar eller tar bort molntjänster kan din ISMS-vy förbli aktuell, granskningsbar och förklarbar.

Hur ser den dagliga A.5.23-hanteringen ut i ISMS.online?

I en typisk uppställning skulle ert team använda ISMS.online för att:

Underhåll ett aktivt register över molntjänster

Registrera varje molntjänst med dess ägare, syfte, datatyper, dataplatser och kritiska karaktär.
Taggtjänster som används internt kontra de som används för att leverera hanterade tjänster.
Koppla varje post till relevanta policyer, risker, leverantörer och ansvarsmatriser.

Koppla och spåra molnspecifika risker och behandlingar

Skapa riskposter för exponering mot flera hyresgäster, kraftfulla konton över flera hyresgäster, datalagring, leverantörslåsning och API-beroenden.
Tilldela behandlingar, ägare och granskningsdatum.
Använd plattformens länkade arbete och projekt för att spåra åtgärds- och förbättringsåtgärder.

Lagra kontrakt, certifieringar och due diligence på ett ställe

Ladda upp leverantörsavtal, dataskyddsavtal, säkerhetssammanfattningar och revisionsrapporter direkt mot leverantörsregister.
Registrera granskningsresultat och beslut, så att du kan visa att leverantörsrisker hanteras över tid.

Centralisera matriser för delat ansvar

Upprätthåll en auktoritativ matris per större molntjänst eller tjänstefamilj.
Koppla matriser till policyer, tjänstebeskrivningar, riskposter och leverantörsregister.
Använd dem som referenspunkter när du uppdaterar runbooks, servicenivåavtal och onboarding-material.

Bevislivscykelaktiviteter

Loggval, onboarding, godkännanden av konfigurationsbaslinjer, ändringsgranskningar, regelbundna omvärderingar och avslutningssteg som uppgifter eller länkade arbetspunkter.
Koppla relaterade incidenter, säkerhetskopieringstester, åtkomstgranskningar och förbättringar till relevanta tjänster och risker.

När du implementerar en ny plattform kan du klona en befintlig post, justera konfiguration och ansvarsområden och koppla den till risker och leverantörer inom några minuter. När du tar bort en tjänst kan du registrera beslut om datamigrering, sanering och bevislagring på samma plats.

För revisioner, kundfrågeformulär eller styrelsemöten kan du sedan sätta ihop ett fokuserat A.5.23-evidenspaket direkt från ISMS.online: molnpolicyn, det aktuella registret, exempel på ansvarsmatriser, viktiga molnrisker och behandlingar, leverantörsbedömning och ett urval av livscykel- och incidentregister. Den förmågan att ge en konsekvent helhetsbild är det som gör att en MSP ser ut att ha kontroll över molnstyrningen snarare än att ständigt reagera. Om du vill att kunder och revisorer ska se dig i den första gruppen är det ett högpresterande nästa steg att investera i att strukturera A.5.23 korrekt i ISMS.online.

A.5.23 Informationssäkerhet för användning av molntjänster – MSP-molnplattformar och delat ansvar