A.5.23 Skysikkerhet: Delt ansvar for MSP-er i henhold til ISO 27001

Hvorfor MSP Cloud Security brøt sammen over natten

MSP-skysikkerhet «brøt sammen» da skyplattformer sluttet å være enkle leverandører og ble miljøer med delt ansvar som du aktivt må styre. ISO 27001 A.5.23 gjør dette skiftet eksplisitt ved å forvente at du kontrollerer hvordan du velger, bruker og avslutter skytjenester i tråd med ISMS-systemet ditt, i stedet for å bare stole på leverandørsertifikater. Denne forventningen gjenspeiler ordlyden i ISO 27001:2022 A.5.23 og vanlige retningslinjer for skysikkerhet, som vektlegger definerte prosesser for anskaffelse, bruk, administrasjon og avslutning av skytjenester i stedet for å bare stole på leverandørforsikringer, som fremhevet i kommentarer til ISO 27001 A.5.23-veiledningen.

Skytjenester lar MSP-en din vokse raskt, men de avdekket også hull i eierskap, styring og bevis som den gamle leverandørmodellen aldri trengte å løse. Når kunder og revisorer nå spør hvem som er ansvarlig for hva i skyen, er ikke lenger nok at «leverandøren gjør det». A.5.23 krystalliserer denne spenningen ved å forvente en kontrollert, dokumentert tilnærming til skybruk i stedet for ad hoc-plattformvalg.

Skyen blir bare en fordel for MSP-er når ansvaret deles bevisst, ikke tas på seg.

Skyen har vokst fra den gamle «leverandør»-tankegangen din

Skyen har vokst fra ideen om at du kan signere en kontrakt, stole på et sertifikat og anta sikkerhetsstopp i leverandørens utkant. For MSP-er tvinger A.5.23 deg til å erkjenne at identiteter, konfigurasjoner og daglig drift på hver plattform nå ligger trygt innenfor ditt ansvar.

Mange MSP-er behandler fortsatt skyleverandører som tradisjonelle leverandører, og det er nettopp der A.5.23 begynner å feile. I årevis kunne du signere en kontrakt, stole på sertifiseringer, legge til litt overvåking og fortsette. Det fungerte da skyen bare var e-posthosting eller noen få virtuelle maskiner.

I dag kjører hele tjenestekataloger på hyperskalaplattformer, der ingeniørene dine har kraftige administratorroller og automatiseringsverktøy som berører dusinvis av leietakere samtidig. I et slikt miljø slutter «leverandøren administrerer sikkerheten» å være sant. Skyleverandøren sikrer sin infrastruktur og kjernetjenester, men du bestemmer identiteter, konfigurasjoner, integrasjoner og mye av den operative robustheten. Kunder forstår i økende grad dette og forventer at du viser hvordan delt ansvar defineres og hvordan teamet ditt driver disse kontrollene i det daglige.

A.5.23 er punktet der standarden eksplisitt påpeker dette skiftet. Den forventer at du går fra generisk leverandørsikring til aktiv styring av hvordan skyplattformer støtter tjenestene og kundene dine.

Den skjulte kompleksiteten til din nåværende skystabel

Den skjulte kompleksiteten i skystakken din blir bare åpenbar når du skriver den ned. En kort, fokusert oversikt avslører vanligvis langt flere tjenester, dataflyter og administratorroller enn du forventet, og det er akkurat det A.5.23 ønsker at du skal se og deretter administrere bevisst.

De fleste MSP-er oppdager at de driver langt flere tjenester, på langt flere måter, enn noen var klar over:

Interne SaaS-verktøy for samarbeid, billettering, CRM og økonomi.
Offentlige skyplattformer som driver administrert infrastruktur, sikkerhetskopiering, overvåking og sikkerhetstjenester.
Nisjebaserte skyverktøy valgt av individuelle team eller ingeniører for å løse spesifikke problemer.

Samlet sett skaper disse tjenestene et nett av datalokasjoner, administratorroller, logger og feilmoduser. Uten en sentral oversikt akkumuleres risikoer stille og rolig: én ingeniør har global administrasjon på tvers av flere leietakere, et «midlertidig» SaaS-verktøy blir forretningskritisk, og en sikkerhetskopieringstjeneste har aldri blitt testet for reelle gjenopprettingsscenarier. En ISMS-plattform som ISMS.online kan hjelpe deg med å opprettholde den sentrale oversikten, slik at kompleksiteten ikke forblir skjult.

For å gjøre skiftet konkret, hjelper det å sammenligne den gamle leverandørtankegangen med skystyringen A.5.23 forventer.

En kort sammenligning viser hvordan tilnærmingen din må endres:

Aspekt	Gammel leverandørmodell	A.5.23 skystyring for MSP-er
Leverandørens synsvinkel	«Pålitlig leverandør håndterer sikkerheten.»	«Bli partner i en definert modell for delt ansvar.»
Kontrollomfang	Kontrakt pluss grunnleggende overvåking	Full livssyklus: valg, bruk, endring, avslutning
Bevis du har	Sertifikater og kontrakter	Registre, risikoregistreringer, matriser, livssyklusartefakter
Eierskap innenfor MSP	Implisitt, personavhengig	Eksplisitte roller, runbooks og ISMS-integrasjon

Når du ser situasjonen din gjennom dette linset, blir det enklere å bestemme hvor du trenger struktur i stedet for flere ad hoc-reparasjoner.

Der kunder og revisorer avslører sprekkene

Kunder og revisorer avslører sprekkene i skylagringen din ved å stille tydelige spørsmål om tjenester, data og ansvar. Spørsmålene deres fremhever ofte hull i eierskap, livssyklus og bevis lenge før et brudd eller driftsavbrudd skjer. Å håndtere tredjepartsrisiko og spore leverandørsamsvar ble nevnt som en største utfordring av 41 % av organisasjonene i ISMS.online-undersøkelsen i 2025.

Typiske spørsmål inkluderer:

Hvilke skytjenester bruker dere på våre vegne, og hvor lagres dataene våre?
Hvem er ansvarlig for sikkerhetskopiering, identitet, logging og konfigurasjon i hver plattform?
Hvordan gransker, overvåker og, om nødvendig, avslutter du skyleverandører?
Hvordan vil dere støtte oss hvis vi ønsker å slutte med en gitt tjeneste?

Disse spørsmålene avslører hvor din nåværende tilnærming er vag. Hvis svarene dine avhenger av hvem som er i møtet, eller krever at noen går inn og sjekker, er A.5.23 allerede et problem. Kontrollen forventer at du har prosesser for å anskaffe, bruke, administrere og avslutte skytjenester i tråd med definerte sikkerhetskrav. For en MSP betyr det å gå fra en improvisert skylagring til en strukturert en som revisorer og kunder kan teste.

Det er her det blir viktig snarere enn lurt å ha et aktivt register over skytjenester, knyttet til risikoer, ansvar og livssyklusregistreringer.

Kontakt

Hva ISO 27001 A.5.23 egentlig ber deg om

ISO 27001 A.5.23 ber deg om å behandle skyen som et styrt tjenestelandskap med klare regler, ansvar og bevis, ikke som en løs samling av verktøy og leverandører. I praksis betyr det å kunne vise hvordan skytjenester velges, kontrolleres og tas ut av bruk i tråd med dine informasjonssikkerhetskrav.

Rapporten om informasjonssikkerhetstilstanden for 2025 bemerker at kunder oftest forventer at leverandører skal tilpasse seg formelle rammeverk som ISO 27001, ISO 27701 , GDPR, Cyber Essentials, SOC 2 og nye AI-standarder.

I 2022-utgaven slår A.5.23 fast at dere bør etablere og implementere prosesser for anskaffelse, bruk, administrasjon og avvikling av skytjenester, i samsvar med deres informasjonssikkerhetskrav. Denne formuleringen er i samsvar med den publiserte kontrollteksten i ISO 27001:2022 A.5.23 og med støttende skyveiledning som ISO 27017 og ISO 27018, som alle vektlegger ende-til-ende-styring av skytjenester i stedet for engangs leverandørkontroller. En sentral ISMS-plattform som ISMS.online kan gjøre dette arbeidet håndterbart ved å holde retningslinjer, risikoer, ansvar og poster på ett sted.

Revisorer ser vanligvis etter en klar linje fra kontrollteksten til faktiske retningslinjer, prosedyrer og registre. Hvis du kan forklare med dine egne ord hva A.5.23 betyr for virksomheten din, ligger du allerede foran mange MSP-er som utelukkende stoler på den formelle ordlyden.

Fra én setning til praktiske mål

Å gjøre A.5.23 om til praktiske mål betyr å dele opp den formelle formuleringen i et lite sett med konkrete, testbare forventninger som du kan utforme kontroller og bevis rundt. Disse målene gir deg et rammeverk for å forklare kontrollen til teamet ditt og revisorer. Tolkninger fra skyfokuserte ISO 27001-utøvere grupperer vanligvis A.5.23-krav i temaer som skypolicy, risiko og krav, delt ansvar, livssyklus og bevis, som er tilnærmingen som gjenspeiles her.

I praksis forventer A.5.23 at du gjør fem ting konsekvent og kan bevise dem. En nyttig måte å tolke kontrollen på er å dele den opp i fem praktiske mål:

Skypolicy og omfang – definere hva «skyen» betyr for organisasjonen din, hvilke tjenester og data som er omfattet, og hvem som kan ta i bruk nye tjenester.
Risiko og krav – identifisere skyspesifikke risikoer som flerleieforhold, dataplassering og tilkobling, og sette minimumskrav til sikkerhet og personvern.
Delt ansvar – dokumentere hvem som er ansvarlig for nøkkelkontroller på tvers av leverandør, MSP og kunde for hver større plattform og tjeneste.
Livsforvaltning – bygg sikkerhet inn i valg, onboarding, endring, overvåking og avslutning av skytjenester, ikke bare i kontrakter.
Bevis og forbedring – føre oversikt som viser at disse prosessene fungerer, og gjennomgå dem etter hvert som plattformer, kunder og regelverk endres.

Sammen gjør disse målene A.5.23 fra én enkelt setning til et sett med vaner. De gir deg også en struktur for å kartlegge kontrollen i din erklæring om anvendelighet og ditt bredere ISMS. Registrering av mål, eiere og støttende bevis i et system som ISMS.online hjelper deg med å holde dem konsistente etter hvert som tjenester og standarder utvikler seg.

Hvordan A.5.23 utvider den eldre leverandørmodellen

A.5.23 utvider den eldre leverandørmodellen ved å anerkjenne at skyen er et teknisk fundament, ikke bare nok en outsourcingkontrakt. Når tjenestene dine er avhengige av delte plattformer, påvirker konfigurasjons-, tilgangs- og driftsvalgene dine sikkerhetsresultatene sterkt, selv om den underliggende infrastrukturen tilhører noen andre.

Sammenlignet med generiske leverandørkontroller innen domener som leverandørstyring og driftssikkerhet, A.5.23:

Vektlegger skytjenestens livssyklus, ikke bare leverandørvalg.
Forventer eksplisitt vurdering av delt ansvar og flerleietak.
Fokuserer på hvordan du skal avslutte eller erstatte skytjenester uten å miste kontrollen over data.

Disse vektleggingene gjenspeiles i spesialiserte A.5.23-kommentarer og kartlegginger av skykontroll, som fremhever livssyklus, delt ansvar og avslutningsplanlegging som forskjellig fra tradisjonell leverandørtilsyn. For MSP-er står A.5.23 også sammen med tilgangskontroll, ressursstyring, hendelseshåndtering og andre kontroller i tillegg A. Målet er ikke å duplisere arbeid, men å sørge for at eksisterende kontroller fullt ut tar hensyn til skyen og måten du leverer tjenester på.

Å koble denne kontrollen tydelig til ISMS-systemet ditt hjelper revisorer med å se at skystyring er integrert og ikke behandlet som et separat spor.

Dokumenttyper revisorer forventer å se

Dokumenttyper som revisorer forventer å se for A.5.23 er de som beviser at skypolicyene, prosessene og ansvaret deres er reelle, konsistente og anvendte. De vil se etter et lite, sammenhengende sett med artefakter snarere enn et stort volum av løst relaterte dokumenter. Implementeringsveiledninger for skystyring for A.5.23 peker ofte på en kombinasjon av policyer, tjenesteregistre, risikovurderinger og livssyklusregistre som det sentrale bevissettet som revisorer forventer.

Under en revisjon vil du sannsynligvis bli bedt om å oppgi bevis som:

En policy for skybruk eller skysikkerhet.
Et register over skytjenester som brukes internt og på vegne av kunder.
Skyspesifikke risikovurderinger og behandlingsplaner.
Due diligence-registre for viktige skyleverandører og underdatabehandlere.
Matriser for delt ansvar eller tilsvarende rolledefinisjoner.
Prosedyrer eller håndbøker for onboarding og exiting services.
Eksempler på logger, anmeldelser eller saker som viser at disse prosessene fungerer.

Hvis du raskt kan finne disse, og de forteller en konsistent historie, vil A.5.23 føles kontrollert og proporsjonal. Hvis de bare finnes i spredte dokumenter eller folks hoder, blir kontrollen en kilde til funn og ekstra arbeid. Å bruke en ISMS-plattform som ISMS.online til å holde disse artefaktene på ett sted gjør det mye enklere å vise hvordan skyen håndteres i praksis.

ISMS.online gir deg et forsprang på 81 % fra det øyeblikket du logger deg på

ISO 27001 gjort enkelt

Vi har gjort det harde arbeidet for deg, og gir deg 81 % forsprang fra det øyeblikket du logger på. Alt du trenger å gjøre er å fylle ut de tomme feltene.

Start

MSP-ens dobbeltliv: Skykunde og leverandør

Din MSP har et dobbeltliv under A.5.23: du er både en krevende skykunde hos oppstrømsleverandører og en ansvarlig skyleverandør overfor dine egne kunder. Kontrollen forventer at du forstår, dokumenterer og styrer begge rollene, inkludert hvordan de samhandler på tvers av den delte ansvarskjeden.

Som skykunde er du avhengig av hyperskalaplattformer og SaaS-verktøy for å drive din egen virksomhet og levere tjenester. Som skyleverandør ser kundene dine på deg som den parten som er ansvarlig for sikkerhet, kontinuitet og støtte, selv når den underliggende teknologien tilhører noen andre. A.5.23 bringer disse to perspektivene sammen og ber deg om å håndtere dem sammenhengende.

Forstå dine oppstrøms- og nedstrømsroller

Å forstå dine oppstrøms- og nedstrømsroller betyr å erkjenne at du bruker skytjenester som en intern kunde, samtidig som du selger skybaserte tjenester som leverandør til dine egne kunder. A.5.23 forventer at du har begge perspektivene i sikte og sørger for at de støtter, snarere enn å motsi, hverandre.

Som skykunde bruker du tjenester som produktivitetspakker, ticketing, overvåkingsplattformer og offentlig skyinfrastruktur. Du er ansvarlig for hvordan disse tjenestene er konfigurert, hvem som har tilgang og hvordan de overvåkes. Når hendelser oppstår eller regulatorer stiller spørsmål, avhenger din evne til å vise kontroll av hvor godt du håndterer dette forbruket og hvor tydelig det er knyttet til ISMS-prosessene dine, for eksempel risikovurdering og endringsledelse.

Som skyleverandør eller -administrator designer, leverer og støtter du tjenester som kjører på disse plattformene. Du selger kanskje administrert infrastruktur, sikkerhetskopiering, SOC, applikasjonshosting eller sikkerhetstjenester. Kundene dine ser deg som den ansvarlige parten, selv når du bygger på en tredjeparts sky. De skiller ikke mellom tjenesten din og hyperskaleringen den kjører på; de antar at du har tatt vare på detaljene.

En vanlig feiljustering oppstår når du forplikter deg til kunder om loggoppbevaring eller sikkerhetskopieringshistorikk, men et oppstrømsverktøy fortsatt kjører på standardinnstillingen, som er mye kortere. I så fall har nedstrømsforpliktelsen din overgått oppstrømskonfigurasjonen din, og A.5.23 vil avdekke dette gapet.

Å bygge et todelt ansvarsperspektiv

Å bygge et todelt ansvarsperspektiv betyr å kartlegge ansvar på tvers av leverandører, MSP-team og kunder i én enkelt, sammenhengende modell. Dette gir CISO, leder for tjenestelevering og kundeansvarlige et felles bilde av hvem som eier hva i hele kjeden.

En praktisk måte å gjøre dette på er å lage en ansvarsmatrise med to roller. På tvers av viktige kontrollområder – identitets- og tilgangshåndtering, konfigurasjon, logging, sikkerhetskopiering, hendelsesrespons, endringskontroll, databeskyttelse – lister du opp:

Hva dine oppstrømsleverandører forplikter seg til.
Hva du, som MSP, forplikter deg til oppstrøms (for eksempel å aktivere visse funksjoner, håndtere visse risikoer).
Hva dere forplikter dere til nedstrøms i kundekontraktene og tjenestenivåavtalene deres.
Det du forventer at kundene skal gjøre selv.

Denne øvelsen avdekker ofte feil: forpliktelser overfor kunder som ikke har oppstrømsstøtte, eller antagelser om leverandører som ikke er dekket av kontraktene deres. Den tydeliggjør også hvor du trenger sterkere kontroller, tydeligere formuleringer eller forskjellige tjenestedesign. Når du bygger dette synet inn i en ISMS-plattform som ISMS.online, gir du teamene én enkelt kilde til sannhet om delt ansvar.

Gjør ansvarskart om til daglig praksis

Å gjøre ansvarskart til daglig praksis betyr at alle som berører skytjenester forstår delene som gjelder for dem og kan handle raskt ut fra dem. Kartene bør forme atferd innen salg, ingeniørfag, support og kundeadministrasjon.

Å gjøre ansvarskart virkelige betyr:

Bruk dem til å orientere salgs- og kundeteam, slik at de ikke lover for mye eller improviserer forpliktelser.
Samsvarer med runbooks og playbooks med ansvarsområdene du har definert, slik at tekniske team handler konsekvent.
Opplæring av ingeniører i hvordan og når de skal utøve rettighetene sine hos kundeleietakere, inkludert tidsbestemte forhøyelser og godkjenninger.
Avtale hvordan hendelser som involverer leverandører skal kommuniseres og håndteres med kunder, inkludert eskaleringsprosesser.

Når ditt dobbeltrolleperspektiv er innebygd på denne måten, slutter A.5.23 å være et abstrakt krav og blir et naturlig perspektiv på hvordan MSP-en din opererer i skyen. Det gir deg også en tydelig fortelling for styrer og kunder som ønsker å forstå din plass i den delte ansvarskjeden.

En praktisk modell for delt ansvar for MSP-skyplattformer

En praktisk modell for delt ansvar for MSP-skyplattformer er et sett med tydelige matriser som viser hvem som gjør hva på tvers av leverandør, MSP og kunde for hver tjeneste. I henhold til A.5.23 gjør disse matrisene ideen om delt ansvar til noe du kan kjøre, lære bort og revidere.

De fleste leverandører av offentlige skytjenester beskriver en enkel oppdeling: de sikrer infrastrukturen; du sikrer det du bygger på den. Dette mønsteret er dokumentert i forklaringer av delt ansvarsmodell fra store leverandører som AWS, Azure og Google Cloud, og det har blitt en vanlig grunnlinje for design av skykontroll. For MSP-er er det bare utgangspunktet. Du trenger modeller som gjenspeiler de spesifikke plattformene du bruker, tjenestene du tilbyr og måten teamene dine faktisk opererer på.

Å gå utover det vanlige «felles ansvar»

Å gå utover generiske «felles ansvar»-etiketter betyr å erstatte vage utsagn med spesifikke, navngitte oppgaver som enkeltpersoner og team forstår. A.5.23 belønner denne klarheten fordi revisorer og kunder kan se hvem som er ansvarlig for reelle handlinger, ikke bare abstrakte konsepter.

Generiske «felles ansvar»-etiketter skjuler reelle risikoer. For å komme deg forbi dem må du vurdere:

De spesifikke plattformene du bruker (for eksempel infrastruktur som en tjeneste, programvare som en tjeneste, administrerte sikkerhetsverktøy).
De spesifikke tjenestene du tilbyr (for eksempel administrert sikkerhetskopiering, administrert SOC, administrert moderne arbeidsplass).
Måten teamet ditt faktisk opererer på (for eksempel bruk av automatisering, sentralisert overvåking, vedlikeholdsvinduer).

For hver kombinasjon av plattform og tjeneste bør en ansvarsmatrise definere ansvarsområder i tilstrekkelig detalj til at folk kan handle. Det betyr å navngi hvem som muliggjør logging, hvem som tester gjenoppretting, hvem som håndterer forespørsler om tilgang og hvem som leder hendelseskommunikasjon, i stedet for bare å si «delt».

Å ta dette ekstra trinnet støtter også relaterte kontroller, som hendelseshåndtering og driftssikkerhet, fordi alle kan se hvor rollen deres starter og slutter.

Strukturering av ansvarsmatrisene dine

Å strukturere ansvarsmatrisene dine godt betyr å bruke en konsistent layout som speiler hvordan ingeniørene og tjenestelederne dine tenker, samtidig som den er detaljert nok til å veilede handlinger. En enkel struktur, gjentatt på tvers av tjenester, gjør opplæring og gjennomgang mye enklere.

En praktisk matrise for hver tjeneste kan dekke domener som:

Identitets- og tilgangsadministrasjon: – hvem som oppretter og tilbakekaller kontoer, administrerer roller og gjennomgår tilgang.
Konfigurasjon og herding: – hvem som anvender grunnlinjer, håndterer sikkerhetsoppdateringer og gjennomgår konfigurasjonsavvik.
Logging og overvåking: – hvem som aktiverer logger, lagrer dem, gjennomgår varsler og reagerer på hendelser.
Sikkerhetskopiering og gjenoppretting: – som konfigurerer sikkerhetskopier, tester gjenoppretting og verifiserer gjenopprettingsmål.
Databeskyttelse og personvern: – hvem som klassifiserer data, anvender oppbevaringsregler og administrerer den registrertes rettigheter.
Kontinuitet og utgang: – hvem som er ansvarlig for robusthetsmønstre, failover og dataeksport eller -sletting ved kontraktens slutt.

For hver rad bør matrisen tydelig markere ansvarsområdene: leverandør, MSP, kunde eller delt med spesifikke tildelte oppgaver. Du bør også sørge for at hver matrise er versjonskontrollert og gjennomgås når tjenester, plattformer eller kontrakter endres, slik at den forblir nøyaktig over tid.

Et forenklet eksempel på administrert sikkerhetskopiering på en offentlig skyplattform kan se slik ut:

Domene	Leverandør-/MSP-/kundeansvar
Sikkerhetskopieringskonfigurasjon	Leverandøren tilbyr funksjoner; MSP konfigurerer policyer; omfang av kundeanmeldelser
Gjenopprett testing	MSP utfører periodiske testgjenopprettinger; kunden validerer dataenes fullstendighet
Oppbevaringsinnstillinger	Leverandøren håndhever grenser; MSP angir oppbevaring; kunden godkjenner policyen

Du kan deretter bruke disse matrisene på nytt på tvers av kunder som bruker samme tjenestemønster, og bare justere der det virkelig er nødvendig.

Koble modellen til ISMS-systemet og kundene dine

Ved å koble den delte ansvarsmodellen til ISMS-systemet og kundene dine, sikrer du at den påvirker beslutninger fra førsalg til avslutning, i stedet for å stå isolert. Jo mer du kobler den sammen, desto mer nyttig og troverdig blir den.

Når du har definert disse modellene, kobler du dem sammen:

Internt, ved å referere til dem i retningslinjer, prosedyrer, runbooks og opplæring.
Kommersielt, ved å samkjøre tjenestebeskrivelsene, tilbudene og tjenestenivåavtalene med ansvaret du har satt.
Med kunder, ved å dele forenklede visninger eller diagrammer under onboarding, slik at forventningene er tydelige fra dag én.

Når en revisor spør hvordan dere håndterer delt ansvar i henhold til A.5.23, kan dere peke på disse matrisene, koblingene deres til ISMS-systemet deres og eksempler på hvordan de har veiledet reelle beslutninger. Når en kunde, for eksempel en CISO eller IT-sjef, spør «hvem eier denne kontrollen?», har dere et svar som er konsistent på tvers av virksomheten. En sentral plattform som ISMS.online kan holde disse matrisene sammen med risikoer, kontroller og kontrakter, slik at de er enkle å vedlikeholde og dokumentere.

Bygg inn, utvid og skaler samsvarsstyringen din uten rot. IO gir deg robustheten og selvtilliten til å vokse sikkert.

Bestill demoen din

Utforming av livssyklusprosesser for skytjenester for A.5.23

Livssyklusprosesser for skytjenester er måten du beviser at A.5.23 er mer enn en policyerklæring: de viser at du velger, kjører og avvikler skytjenester på en kontrollert og repeterbar måte. For en MSP er målet å veve inn livssyklustrinn i skytjenester i eksisterende ISMS-prosesser, ikke å opprette et separat byråkrati.

A.5.23 forventer at du demonstrerer at skytjenester følger definerte trinn fra idé til avslutning, med sikkerhet og delt ansvar vurdert i hvert trinn. Dette samsvarer tett med kontrollens eget språk rundt «anskaffelse, bruk, administrasjon og avslutning» av skytjenester i tråd med krav til informasjonssikkerhet, og med vanlige livssyklusmodeller som brukes i ISO 27001 og veiledning om skystandarder, som for eksempel ISO 27001 A.5.23-kommentarer. Dette samsvarer naturlig med ISO 27001-klausuler om risikohåndtering, driftsplanlegging, endringsledelse og leverandørstyring.

Definere en livssyklus for skytjenester som folk kan følge

Å definere en livssyklus for skytjenester som folk kan følge, betyr å gjøre A.5.23 om til et lite sett med repeterbare stadier som passer til dine eksisterende arbeidsmåter. Livssyklusen bør være enkel nok til at produkteiere, ingeniører og innkjøpsteam kan bruke den uten spesialkunnskap. To tredjedeler av organisasjonene i ISMS.online-undersøkelsen State of Information Security i 2025 sier at hastigheten og volumet av regelendringer gjør det vanskeligere å opprettholde samsvar.

En typisk livssyklus for viktige skytjenester kan inkludere stadier som:

Idé og vurdering – noen foreslår en ny skytjeneste eller en ny måte å bruke en eksisterende på. Du vurderer den for forretningsverdi, sikkerhet og samsvar med regelverk.
Utvalg og due diligence – du sjekker sertifiseringer, datalokasjoner, kontraktsvilkår og støttemuligheter, og sammenligner alternativer.
Design og onboarding – du bestemmer hvordan tjenesten skal konfigureres, integreres og overvåkes, og hvem som skal eie den.
Drift og endring – du driver tjenesten, gjennomgår logger og målinger, håndterer endringer og hendelser, og sørger for at konfigurasjonen er i samsvar med standardene dine.
Gjennomgang og fornyelse – du vurderer jevnlig om tjenesten fortsatt oppfyller behovene, om risikoen er akseptabel og om det er behov for forbedringer.
Utgang eller erstatning – hvis du slår av eller erstatter tjenesten, håndterer du dataeksport, sletting og kundekommunikasjon.

Disse stadiene gjør beslutninger om skytjenester repeterbare i stedet for ad hoc. For hver enkelt, definer minimumshandlingene, godkjenningene og registreringene du forventer. Dette kan inkludere risikovurderinger, sjekklister for due diligence, konfigurasjonsgrunnlinjer, endringsregistreringer og bekreftelser om avslutning, alt i tråd med ditt sentrale ISMS.

For å gjøre dette enda mer brukbart, kan du uttrykke livssyklusen som et enkelt sett med trinn som teamene kan følge.

Trinn 1: Fang opp og screen ideen

Registrer og screen hver skytjenesteidé før noen registrerer seg eller integrerer den, slik at du kan veie verdi, risiko og samsvar med ISMS-et ditt.

Registrer den foreslåtte skytjenesten, dens formål og innledende risikoer før noen registrerer seg eller integrerer den.

Trinn 2: Fullfør due diligence og design

Fullstendig due diligence og design før en skytjeneste tas i bruk, slik at konfigurasjon, overvåking og ansvar defineres i stedet for improvisert.

Sjekk sikring, kontrakter og datahåndtering, og definer deretter konfigurasjon, overvåking og delt ansvar.

Trinn 3: Ombordstigning, drift og planlegging avkjørsel

Ombord, drift og planlegg avkjørsel på en strukturert måte, slik at du kan bevise hvordan tjenesten kontrolleres gjennom hele levetiden.

Installer tjenesten i henhold til grunnlinjene dine, overvåk den og registrer hvordan du vil avslutte eller erstatte den på en sikker måte.

Integrering av livssykluskontroller i måten du jobber på

Å integrere livssykluskontroller i måten du jobber på betyr å integrere dem i prosesser og verktøy teamene dine allerede bruker. Når livssyklusen er standardveien, blir det mye enklere å opprettholde samsvar med A.5.23.

Ta i betraktning:

Samsvarer med innkjøpsarbeidsflyter, slik at kontrakter ikke kan signeres før sikkerhets-, personvern- og driftskrav er kontrollert.
Koble det til tjenesteintroduksjonsprosessen din, slik at nye tilbud eller større endringer går gjennom skyens livssyklusporter.
Integrering av livssyklusoppgaver i dine billett- og endringssystem, ikke bare i separate skydokumenter.

Ved å koble livssyklustrinn til etablerte prosesser som endringsledelse og leverandørstyring, reduserer du friksjon og forbedrer adopsjonen. Folk følger livssyklusen fordi det er minste motstands vei, ikke fordi de ble bedt om å lese en annen policy.

Klargjøring for revisjon av livssyklusbevis

Å gjøre livssyklusbevis klare for revisjon betyr å kunne vise noen få komplette eksempler som demonstrerer den samme logikken brukt på forskjellige tjenester. Revisorer ønsker å se mønstre, ikke engangssuksesser.

For hvert eksempel, sikt mot å demonstrere:

Hvorfor tjenesten ble valgt, basert på risiko og krav.
Hvordan ansvar ble definert, ved hjelp av deres modell for delt ansvar.
Hvilke kontroller som ble implementert ved onboarding, inkludert grunnlinjer og tilgangsmønstre.
Hvordan tjenesten overvåkes og evalueres, med eksempler på endringer eller forbedringer.
Hvordan data og tilgang ville bli håndtert ved avslutning, selv om avslutningen ennå ikke har skjedd.

Hvis du kan fremlegge disse bevisene uten større problemer, vil A.5.23 føles innebygd snarere enn boltet på. Et system som ISMS.online kan hjelpe ved å koble sammen tjenester, risikoer, ansvar, endringer og avslutningsrapporter på ett sted, slik at du ikke trenger å sette sammen bildet fra bunnen av hver gang noen spør.

Tekniske kontroller for flere leietakere: Implementering av konsistente sikkerhetstiltak

Tekniske kontroller for flere leietakere er det praktiske uttrykket for dine A.5.23-skystyringsbeslutninger i det daglige ingeniørarbeidet. De oversetter modeller for delt ansvar og livssyklusprosesser til konkrete grunnlinjer som beskytter mange kunder samtidig.

Når du administrerer flere leietakere på felles plattformer, forventer A.5.23 at du har en proaktiv, standardisert tilnærming til identitet, konfigurasjon, logging, sikkerhetskopiering og isolering. På den måten kan du vise at dine tekniske sikkerhetstiltak samsvarer med ansvaret du har akseptert og forpliktelsene du gir kundene.

Hvorfor grunnlinjer for flere leietakere er viktige

Grunnlinjer for flerleietakere er viktige fordi små svakheter kan ha store konsekvenser for mange kunder samtidig. Én enkelt rolle som gir for mye tillatelse, en manglende oppdatering eller en uprøvd sikkerhetskopiering kan undergrave den generelle sikkerhetsnivået for skyen. Rammeverk for skysikkerhet og nasjonale retningslinjer, som risikodiskusjoner for flere leietakere i kontrollkataloger og samlinger for skysikkerhet fra nasjonale cybersikkerhetssentre, fremhever konsekvent identitetshåndtering, oppdateringer og sikkerhetskopiering som systemiske risikoområder som raskt kan skaleres på tvers av leietakere når de svikter. Et flertall av organisasjonene i ISMS.online-undersøkelsen i 2025 rapporterte at de var påvirket av minst én tredjeparts- eller leverandørrelatert sikkerhetshendelse i løpet av det siste året.

I et MSP-miljø kan én overprivilegert administratorkonto, en ulogget kritisk handling eller en uprøvd sikkerhetskopieringsprosess påvirke dusinvis av kunder i én hendelse. A.5.23 forventer at du håndterer disse risikoene systematisk, ikke reaktivt, og at du kan vise hvordan kontrollene dine gjelder på tvers av skytjenestene du bruker og tilbyr. Konsistente grunnlinjer definerer minimumskontrollene som er på plass for enhver kunde som bruker en gitt plattform eller tjeneste, og gir revisorer og kunder trygghet for at du ikke gjenoppfinner sikkerheten hver gang.

Fra et lederskapsperspektiv gir disse grunnlinjene også en trygghetskilde: du kan vise styrer og kunder at tekniske sikkerhetstiltak er i samsvar med styrings- og kontraktsbeslutningene du allerede har tatt.

Kjernetekniske temaer som skal standardiseres

Kjernetekniske temaer som skal standardiseres er områdene der konsistente sikkerhetstiltak reduserer sannsynligheten for problemer på tvers av leietakere og gir ingeniører et klart utgangspunkt på alle plattformer.

Selv om detaljene varierer fra plattform til plattform, drar de fleste MSP-er nytte av å standardisere minst følgende temaer. Dette gjør det enklere for sikkerhetssjefen, driftslederen og ingeniørteamene å trekke i samme retning.

Identitets- og tilgangsadministrasjon: – rollebasert tilgang, færrest privilegier, separasjon av oppgaver, tidsbegrenset forfremmelse for handlinger med høy risiko og robust offboarding.
Konfigurasjon og herding: – grunnleggende maler for nettverkssegmentering, kryptering, endepunktbeskyttelse, oppdateringspolicyer og navngiving av ressurser.
Logging og overvåking: – konsistente loggkonfigurasjoner, sentral loggsamling, definerte varslingsregler og dokumenterte responsplaner.
Sikkerhetskopiering og gjenoppretting: – standard sikkerhetskopieringsplaner, oppbevaring, kryptering, testrutiner for gjenoppretting og dokumentasjon av klientens gjenopprettingsmål.
Isolasjon og leieforhold: – mønstre for å separere leietakere i nettverket, identitets- og datalag, og kontroller for å bekrefte at isolasjonen holder.

Hver grunnlinje bør tydelig angi hva leverandøren leverer, hva du konfigurerer og vedlikeholder, og hva du forventer at kundene skal gjøre. Samlet sett blir disse temaene den tekniske ryggraden i A.5.23-implementeringen din.

Etter at du har definert disse temaene, er neste trinn å bygge dem inn der ingeniørene bor: maler, skript, infrastruktur som kode, sentrale administrasjonsverktøy og dokumenterte strategier.

Koble tekniske kontroller til A.5.23 og utover

Å koble tekniske kontroller til A.5.23 og relaterte kontroller sikrer at styring, juridiske forpliktelser og tekniske praksiser støtter hverandre i stedet for å bli skilt fra hverandre. Denne samordningen gjør det enklere å forklare og forsvare det overordnede systemet.

Det betyr:

Kartlegge hvert grunnlinjeelement til dine delte ansvarsmatriser, slik at tekniske kontroller samsvarer med ansvaret du har tildelt.
Sørg for at grunnlinjer er en del av skytjenestens livssyklus, slik at de brukes ved onboarding og gjennomgås på nytt under gjennomganger.
Koble temaer som tilgang, logging og sikkerhetskopiering til Annex A-kontroller for tilgangskontroll, driftssikkerhet, hendelseshåndtering og forretningskontinuitet.

Denne tilpasningen gjør det overordnede kontrollsystemet ditt sammenhengende. Det betyr også at når A.5.23 diskuteres under revisjoner eller kundevurderinger, er du klar til å vise ikke bare retningslinjer, men også fungerende tekniske sikkerhetstiltak som samsvarer med styringssystemet ditt. Hvis du administrerer disse grunnlinjene i et sentralt system som ISMS.online, kan du demonstrere forbindelsen fra en skytjeneste til risikovurderingen og de tekniske kontrollene med noen få klikk.

ISMS.online støtter over 100 standarder og forskrifter, og gir deg én enkelt plattform for alle dine samsvarsbehov.

Bestill demoen din

Kontrakter, tjenestenivåavtaler og underdatabehandlerklausuler som holder i revisjon

Kontrakter, tjenestenivåavtaler og klausuler for underdatabehandlere er der A.5.23-beslutningene dine om skystyring blir juridisk bindende løfter. Kontrollen forventer at avtalene dine med leverandører, underdatabehandlere og kunder gjenspeiler det delte ansvaret, livssyklusen og de tekniske valgene du har tatt, snarere enn å motsi dem.

A.5.23 krever ikke at du skriver kontrakter på en bestemt måte, men revisorer og kunder vil teste om dine juridiske forpliktelser og din tekniske virkelighet stemmer overens. Prinsippbasert veiledning om A.5.23 og relaterte skykontroller understreker rutinemessig viktigheten av å samkjøre kontraktsløfter med faktiske kontroller og modeller for delt ansvar, fordi det er feilaktig samsvar som fører til mange revisjonsfunn og tvister.

A.5.23 krever ikke at du skriver kontrakter på en bestemt måte, men revisorer og kunder vil teste om dine juridiske forpliktelser og din tekniske virkelighet stemmer overens. Hvis de ikke gjør det, blir kontrollen en kilde til risiko og funn.

Å gjøre ansvar og forventninger eksplisitte i kontrakter og tjenestenivåavtaler betyr å oversette interne ansvarsmatriser til klare og stabile formuleringer som alle kan forstå innen jus, salg og kunder. A.5.23 er mye enklere å dokumentere når disse dokumentene samsvarer med måten dere faktisk opererer på.

Kontrakter og tjenestenivåavtaler er der misforståelser blir til tvister, spesielt når det gjelder skytjenester. For å støtte A.5.23 bør avtalene dine:

Beskriv tjenestene tydelig, inkludert eventuell avhengighet av tredjeparts skyplattformer.
Sett frem sikkerhets- og databeskyttelsesforpliktelser i tilstrekkelig detalj til at de er meningsfulle, uten å love noe du ikke kan levere.
Forklar hvem som er ansvarlig for hvilke aspekter ved hendelsesdeteksjon, respons og kommunikasjon.
Avklar hva som skjer ved kontraktens slutt, inkludert dataeksport eller -sletting og eventuell overgangsstøtte.

Der det er mulig, sørg for at denne formuleringen er direkte tilpasset domenene i matrisene for delt ansvar, slik at det er en klar linje fra modell til formulering. Dette bidrar også til å oppfylle relaterte ISO 27001-krav rundt juridiske, regulatoriske og kontraktsmessige forpliktelser.

Når ansvarsområder er eksplisitte i både matriser og kontrakter, har teamene dine mindre rom for motstridende tolkninger når hendelser eller komplekse kundekrav oppstår.

Samsvarer den tekniske virkeligheten med juridiske forpliktelser

Å tilpasse den tekniske virkeligheten til juridiske forpliktelser betyr å kontrollere at det du lover i kontrakter er oppnåelig med dine nåværende verktøy, prosesser og grunnlinjer. Det reduserer risikoen for at kunder eller revisorer oppdager hull mellom ord og praksis. Bare omtrent 29 % av organisasjonene i ISMS.online-undersøkelsen i 2025 sa at de ikke hadde mottatt bøter for svikt i databeskyttelsen, og flertallet rapporterte bøter, og noen risikerte bøter på over £250 000.

Det er lett for juridiske klausuler å avvike fra den tekniske virkeligheten over tid. Kanskje en mal lover svært rask hendelsesvarsling, men overvåkings- og eskaleringsprosessene dine gjør det vanskelig i praksis. Eller en tjenestenivåavtale forplikter seg til gjenopprettingsmål som ikke samsvarer med sikkerhetskopieringsdesign.

For å unngå dette, bør du gjennomgå kontraktene og tjenestenivåavtalene dine i fellesskap på tvers av juridisk, sikkerhets-, drifts- og kontoadministrasjon. Spør:

Kan vi konsekvent oppfylle forpliktelsene vi påtar oss, gitt vår nåværende overvåking, supporttimer og tekniske grunnlinjer?
Finnes det områder der vi må investere i bedre kontroller eller verktøy for å oppfylle dem?
Finnes det forpliktelser som i stedet bør ligge hos kunden eller leverandøren, og kommuniseres som sådan?

Når dine juridiske forpliktelser og tekniske muligheter er i samsvar, blir A.5.23 enklere å dokumentere og mindre risikabelt å leve med. Du reduserer også sannsynligheten for overraskelser for kunder, regulatorer eller revisorer som graver i detaljene bak løftene dine.

Integrering av styring i avtalene dine

Å innlemme styring i avtalene dine betyr å bruke kontraktsspråk for å forsterke måten du ønsker at leverandører og kunder skal oppføre seg på, ikke bare dokumentere tjenester og priser. Det kan gjøre delt ansvar og livssyklustenkning til en del av det daglige forholdet.

Det kan inkludere:

Rettigheter til å motta eller gjennomgå leverandørforsikring, for eksempel oppdaterte sertifiseringer eller uavhengige rapporter.
Forventninger rundt deltakelse i felles hendelses- eller kontinuitetsøvelser.
Plikter til å varsle om vesentlige endringer i tjenesten eller lokasjonen.
Krav om å følge avtalte utgangsprosesser, inkludert tidslinjer og samarbeid.

Ved å integrere disse i kontraktene dine, sikrer du at styring ikke bare er en intern sak. Det blir en del av måten du, leverandørene dine og kundene dine samarbeider på i løpet av tjenestens levetid. Når revisorer tester A.5.23, kan de se at livssyklus og delt ansvar gjenspeiles konsekvent i avtalene dine, ikke bare i retningslinjene dine.

Bestill en demo med ISMS.online i dag

Å bestille en demonstrasjon med ISMS.online er en praktisk måte å se hvordan MSP-en din kan få kontroll over A.5.23-skystyring uten å gjøre teamene dine mer komplekse. På ett sted kan du se hvordan skytjenester, risikoer, ansvar, livssyklustrinn og bevis henger sammen, slik at du er klar for revisjoner, kundespørsmål og styrevurderinger.

Du får kontroll over A.5.23-skystyring når du erstatter spredte dokumenter og ad hoc-beslutninger med et enkelt, sammenhengende system som kobler sammen tjenester, risikoer, ansvar, livssyklustrinn og bevis. For mange MSP-er kan bruk av en spesialbygd ISMS-plattform som ISMS.online være en praktisk måte å oppnå denne konsolideringen på uten å legge til mer kompleksitet.

ISMS.online hjelper deg med å gjøre dine A.5.23-ansvar for skystyring om til ett enkelt, sammenhengende system som kobler sammen skyinventar, modeller for delt ansvar, livssyklusarbeidsflyter, kontrakter og bevis. I stedet for å jage dokumenter på tvers av stasjoner, konsoller og innbokser, kan du se hvordan skytjenester styres og hvordan ansvar administreres på ett sted.

For MSP-er betyr det at du kan vise revisorer, styrer og kunder en tydeligere og mer sammenhengende fortelling: hvilke skytjenester du bruker, hvordan ansvaret deles, hvilke kontroller som er på plass og hvordan disse ordningene endres over tid. Observatører av verktøy for styring, risiko og samsvar (GRC) bemerker ofte at sentraliserte plattformer gjør denne typen fortelling enklere å sette sammen og holde konsistent, fordi de samler risikoer, kontroller og bevis i ett miljø. Du beholder kontrollen over beslutninger; plattformen hjelper deg med å bevise den kontrollen, konsekvent, etter hvert som virksomheten skaleres og standardene utvikler seg.

Se skylageret ditt i én visning

Å se skylageret ditt i én visning gjør det enklere for CISO, driftsleder og kundevendte team å svare på vanskelige spørsmål uten friksjon. A.5.23 blir mindre en samsvarsøvelse og mer en enkel måte å beskrive hvordan du egentlig jobber.

Når du sentraliserer skystyringen din i en ISMS-plattform, gir du deg selv og teamet ditt ett enkelt referansepunkt for A.5.23. Du kan:

Vedlikehold et live register over interne og klientrettede skytjenester.
Koble hver tjeneste til risikoer, kontroller, ansvarsmatriser og livssyklusfaser.
Legg ved kontrakter, due diligence, endringsrapporter og exit-dokumentasjon direkte til tjenestene de er relatert til.

Sammen gjør disse funksjonene det mye enklere å svare på revisorspørsmål, sikkerhetsvurderinger fra kunder og interne beslutningstakere som ønsker å forstå hvordan skyen administreres. Du er ikke lenger avhengig av minne eller ulike regneark for å fortelle skyens historikk.

Ta neste steg med selvtillit

Hvis du kjenner igjen utfordringene som er beskrevet her hos din MSP – uklare ansvarsområder, spredte bevis, økende press fra kunder og revisorer – er det et praktisk neste steg å utforske en plattform som ISMS.online i en kort, fokusert demonstrasjon. Til tross for økende press, oppgir nesten alle respondentene i 2025 State of Information Security-undersøkelsen å oppnå eller opprettholde sikkerhetssertifiseringer som ISO 27001 eller SOC 2 som en topprioritet.

Du kan se hvordan det støtter dine eksisterende verktøy og arbeidsmåter, samtidig som det gir deg strukturen A.5.23 forventer.

Velg ISMS.online når du ønsker ett sted å oppbevare registeret over skytjenestene dine, ansvar, risikoer og bevis, slik at du kan vise, ikke bare hevde, at A.5.23 er under kontroll. Hvis du verdsetter tydelig styring, smidigere revisjoner og en sterkere plattform for kunder og styrer, er teamet vårt klart til å hjelpe deg med å se hvordan det ser ut i ditt miljø.

Kontakt

Ofte Stilte Spørsmål

Hva forventer ISO 27001:2022 A.5.23 egentlig av en MSP som bruker skytjenester?

ISO 27001:2022 A.5.23 forventer at MSP-en din aktivt styrer hele livssyklusen til hver skytjeneste du er avhengig av , ikke bare samler inn leverandørsertifikater og håper på det beste. Du bør raskt og konsekvent kunne vise hva du bruker, hvorfor du bruker det, hva som kan gå galt, hvem som eier hvilke kontroller, og hvordan du kan avslutte uten å miste data eller tjenester.

Hvordan ser «god» A.5.23-bevis ut for en MSP?

Revisorer og engasjerte kunder ser vanligvis etter en liten, sammenhengende samling av bevis, ikke et gigantisk arkiv. For en MSP inkluderer kjernesettet vanligvis:

En klar skybruk / sikkerhetspolicy for skyen

Dette definerer hva som regnes som «sky» i din verden (IaaS, SaaS, PaaS, administrerte sikkerhetstjenester), hvem som kan godkjenne nye tjenester, og dine minimumsforventninger til konfigurasjon, overvåking og avslutning.

A register over skytjenester som dekker:
interne verktøy (RMM, PSA, billettering, fakturering, CRM, overvåking, sikker filoverføring); og
kundevendte tjenester (IaaS-plattformer, Microsoft 365 og andre SaaS-pakker, sikkerhetskopiering/DR, SOC/XDR, administrerte brannmurer og WAF-er).

Skyspesifikke risikovurderinger og behandlinger:

Disse bør peke ut eksponering for flere leietakere, kraftige roller på tvers av leietakere, datalagring, leverandørinnlåsing, API-avhengigheter og nøkkelhåndtering. Risikoene bør være knyttet til reelle kontroller og forbedringstiltak.

Due diligence-rapporter: for nøkkelleverandører og underdatabehandlere

Vanligvis inkluderer dette sikkerhetssammendrag, sertifiseringer (for eksempel ISO 27001, SOC 2), databehandleravtaler, oppetidshistorikk, historikk over sikkerhetsbrudd og kjente begrensninger eller unntak som påvirker designene dine.

Matriser for delt ansvar:

For hver større tjeneste, vis hva leverandøren gjør, hva MSP-en din gjør, og hva kunden må gjøre. Språket bør være konkret nok til at en ingeniør eller kunde kan se «oppgavene mine» uten et nytt møte.

Livssyklusoppføringer for skytjenester:

Bevis på at valg, onboarding, konfigurasjon, endring, periodisk gjennomgang og avslutning håndteres på en kontrollert og repeterbar måte i stedet for gjennom ad hoc-saker.

Hvis disse elementene er sammenhengende og enkle å navigere, føles A.5.23 under kontroll og troverdig. Å bruke ISMS.online til å oppbevare retningslinjer, risikoregistreringer, leverandørregistre, ansvarsmatriser og livssyklusbevis i ett ISMS-arbeidsområde betyr at du ikke trenger å rekonstruere skylageret ditt fra innbokssøk og konsollskjermbilder hver gang en revisor eller kunde tar opp klausulen.

Hvordan bør en MSP bygge en brukbar modell for delt ansvar for skyen under A.5.23?

Du oppfyller intensjonen i A.5.23 når «delt ansvar» blir et tjeneste-for-tjeneste-kart over reelle oppgaver , ikke bare et markedsføringsbilde som sier at «vi og leverandøren bryr oss begge om sikkerhet». Alle som leser det – ingeniør, selger, kontraktsanmelder eller kunde – skal kunne se nøyaktig hva de eier.

Hvordan gjør man «delt ansvar» om til noe konkret?

Et praktisk mønster som fungerer bra for MSP-er er å:

1. Katalogiser skytjenestene dine etter kategori

Start med en kort liste over bøtter:

Offentlig sky-arbeidsbelastninger (IaaS/PaaS).
SaaS-produktivitetspakker (Microsoft 365, Google Workspace og lignende).
Administrerte tjenester for sikkerhetskopiering og gjenoppretting etter katastrofe.
Administrerte SOC/XDR- og trusseldeteksjonstjenester.
Andre tilbakevendende skybaserte verktøy du er avhengig av for å drive virksomheten din eller levere tjenester.

Denne listen speiler vanligvis oppføringene i skytjenesteregisteret ditt, noe som gjør det enklere å holde ting på plass.

2. Velg et felles sett med sikkerhetsdomener

Velg et lite sett med domener som gjelder for de fleste av tjenestene dine, for eksempel:

Identitets- og tilgangshåndtering.
Grunnlinjekonfigurasjon og herding.
Logging, overvåking og varsling.
Sikkerhetskopiering, gjenoppretting og testrutiner.
Kryptering og nøkkelhåndtering.
Hendelsesdeteksjon, triage og respons.
Endringshåndtering og godkjenninger.
Dataoppbevaring, -lagring og -destruksjon.

Å holde seg til et standardsett gjør modellen enklere å forstå og gjenbruke på tvers av tjenester.

3. Tildel eierskap per domene, per tjeneste

For hver tjeneste og hvert sikkerhetsdomene, avgjør hvem som faktisk gjør jobben i praksis:

Skyleverandør: – infrastrukturens robusthet, fysisk sikkerhet, de fleste underliggende plattformoppdateringer, noen alternativer for logglagring.
Din MSP: – grunnlinjer for leietakerkonfigurasjon, varslingsruting, sikkerhetskopieringsplaner, gjenopprettingstesting, hendelsessortering, kunderapportering.
Kunde: – brukeratferd, akseptabel bruk, dataklassifisering, tilgangsgodkjenning, beslutninger om innholdslivssyklus.

Der ansvaret deles, skriv ned fordelingen som spesifikke oppgaver , ikke vage «felles» etiketter. For eksempel:

«Kunden godkjenner oppbevaringsperioden; MSP implementerer og gjennomgår konfigurasjonen kvartalsvis.»
«MSP gjennomgår sikkerhetsvarsler; leverandøren håndterer hendelsesrespons på plattformnivå.»

4. Integrer modellen i den daglige driften

En ansvarsmatrise har bare betydning hvis den dukker opp der folk jobber. Sørg for at du:

Referer til det i løpebøker og spillbøker, slik at ingeniører kan se hva de skal gjøre under hendelser og endringer.
Rette inn standard tjenestebeskrivelser og SoWs med det, slik at salg ikke lover oppgaver du ikke utfører.
Reflekter det inn kontrakter og tjenestenivåavtaler, slik at juridiske forpliktelser samsvarer med den tekniske virkeligheten og oppstrømsleverandørens kapasitet.
Inkluder det i onboarding-pakker, slik at nye kunder forstår hvilke handlinger som blir værende hos dem og hvilke som blir værende hos deg.

Ved å vedlikeholde disse matrisene sentralt i ISMS.online – koblet til tjenester i skyregisteret ditt, risikoposter og leverandørregistre – kan du oppdatere en matrise én gang og la endringen forplante seg til løpebøker, dokumentasjon og revisjonsbevis. Det gjør det mye enklere å vise at A.5.23 fungerer i praksis, ikke bare i et policydokument.

Hvilke skyspesifikke risikoer fremhever A.5.23 for MSP-er, og hvor har de en tendens til å gli ut?

For MSP-er handler A.5.23 mindre om generiske historier om «skybrudd» og mer om feiljusterte forventninger, konfigurasjonssvakheter og dårlig livssykluskontroll på tvers av delte miljøer. Problemer har en tendens til å dukke opp der markedsføringsløftene, leverandørens evner og teamets atferd ikke stemmer overens.

Hvor blir MSP-er ofte tatt på fersken?

Mønstre som gjentatte ganger forårsaker problemer inkluderer:

Overdreven avhengighet av leverandørens sikkerhetsantagelser

Det er lett å snakke om «sikkerhet gjennom design» mens man antar at oppgaver som gjenopprettingstesting, logggjennomgang, trusseljakt eller herding på leietakernivå er inkludert i et skyabonnement. I virkeligheten er mange av disse aktivitetene ditt ansvar som MSP , og noen ganger delvis kundens. Når de ikke fanges opp i ansvarsmatrisene og runbookene dine, blir de sjelden utført konsekvent.

Overdreven, dårlig styrt privilegert tilgang

MSP-er har ofte mektige roller – globale administratorkontoer, partnerportaler, «breakglass»-identiteter – som strekker seg over mange leietakere. Hvis disse rettighetene mangler sterk godkjenning, logging og gjennomgang, kan én kompromittert legitimasjon eller misbrukt konto bli en betydelig hendelse med flere leietakere. A.5.23 forventer at du anerkjenner denne risikoen i dine aktiva- og risikoregistre, og at du setter tydelige kontroller rundt den.

Uregistrert eller «skygge»-SaaS

Team tar i bruk SaaS-verktøy som håndterer sensitive data eller kundedata – for support, samarbeid, utvikling, salg eller automatisering – uten å legge dem til i ISMS-systemet, leverandørregisteret eller risikoprosessene dine. Disse tjenestene faller da utenfor overvåkings-, hendelsesrespons- og exitplanene dine.

Svake eller uprøvde exitplaner

Mange MSP-er tenker bare på exit når en leverandør kunngjør en produktavvikling, en større prisendring eller et driftsavbrudd. Uten en registrert exit-plan – inkludert dataeksport, migrering, bevisoppbevaring og kundekommunikasjon – improviserer du på det punktet der du trenger mest kontroll.

SLA-er som lover for mye

Kontrakter forplikter deg noen ganger til gjenopprettingsmål, oppbevaringsperioder eller spesifikasjoner for datalagring som den underliggende stakken ikke kan garantere. Når tjenestedesign, skyleverandørfunksjoner og kontraktsspråk ikke samsvarer, bærer du unødvendig risiko.

A.5.23 gir deg et rammeverk for å håndtere disse problemstillingene systematisk:

Inventar og klassifiser skytjenester: slik at du vet hvor risikoen konsentreres.
Utfør skyspesifikke risikovurderinger som adresserer problemer med flere leietakere, privilegert tilgang og leverandørfeilmoduser.
Vedlikeholde ansvarsmatriser slik at oppgaver blir tildelt, eid og gjennomgått.
bevis livssyklustrinn – fra onboarding til exit – slik at folk kan se at endringer, gjennomganger og exits er kontrollerte hendelser, ikke reaksjoner.

Når du kan spore en risiko – for eksempel overdreven tilgang til partnerportaler – fra registeret ditt til ansvarsmatriser, og deretter til endring av poster og forbedringstiltak, er du ikke bare i samsvar med A.5.23; du presenterer også en langt sterkere risikohistorie for skyen til revisorer og kunder.

Hvordan kan en MSP dokumentere A.5.23 i sitt ISMS uten å redesigne alt?

Du kan vanligvis dekke A.5.23 ved å legge til skyspesifikk styring i ditt eksisterende ISMS , i stedet for å bygge en parallell struktur. Målet er at alle som er kjent med ISO 27001, kan følge hvordan du velger, kontrollerer og avvikler skytjenester like enkelt som de kan følge tradisjonelle eiendeler eller leverandører.

Hvordan vever du skystyring inn i det du allerede har?

Et enkelt, men effektivt mønster er å starte med tre tilkoblede komponenter og deretter koble dem til ditt eksisterende ISMS:

1. Skybruk / sikkerhetspolicy for skyen

Utvid ditt eksisterende informasjonssikkerhetspolicysett med et fokusert dokument som:

Definerer hva som kvalifiserer som en skytjeneste i din kontekst.
Angir godkjenningsterskler (for eksempel hvem som kan autorisere en ny leverandør).
Angir forventninger til due diligence, konfigurasjonsgrunnlinjer, overvåking, hendelseshåndtering og avslutning.

Denne policyen blir ankeret for relaterte prosedyrer og registre.

2. Skytjenesteregister

Opprett et register – ofte en ISMS.online-ressurs- eller leverandørliste – som som et minimum registrerer:

Tjenestenavn og leverandør.
Intern eier.
Forretningsformål.
Datatyper som håndteres og dataplasseringer.
Kritisk betydning og virkning av tap.
Lenker til kontrakter, databehandleravtaler, sertifiseringer og ansvarsmatriser.

Du kan integrere dette med din eksisterende beholdning av eiendeler, slik at skytjenester ikke befinner seg i et separat univers.

3. Matriser for delt ansvar

For de tjenestene som betyr mest, bygg og vedlikehold ansvarsmatriser som beskrevet tidligere. Fokuser først på:

Din primære offentlige skyplattform.
Din primære SaaS-produktivitets- og samarbeidspakke.
Ditt flaggskiptilbud innen administrert sikkerhetskopiering/DR.
Dine administrerte SOC/XDR- eller lignende sikkerhets-som-en-tjeneste-løsninger.

Du kan deretter koble disse komponentene til ISMS-elementene du allerede bruker:

Risikostyring: – koble skytjenester til risikooppføringer og -behandlinger, spesielt der det finnes scenarier med flere leietakere eller leverandørsvikt.
Leverandøradministrasjon: – legge ved kontrakter, sikkerhetssammendrag, databehandleravtaler og revisjonsrapporter til de relevante leverandørene; registrere periodiske gjennomganger og beslutninger.
Driftskontroller: – referer til skyspesifikke trinn for onboarding, endring, gjennomgang og avslutning i dine eksisterende endringshåndterings- og hendelseshåndteringsprosesser.
Bevishåndtering: – koble hendelser, resultater av sikkerhetskopieringstest, tilgangsgjennomganger og forbedringstiltak tilbake til relevante skyposter og risikoer.

Ved å bruke eksempler som fungerer – for eksempel én intern SaaS, én kunderettet løsning bygget på offentlig sky og én nisjebasert, men kritisk plattform – kan du vise revisorer at mønsteret er repeterbart uten å dokumentere hver mindre tjeneste individuelt. ISMS.online er utviklet for denne typen modellering: retningslinjer, registre, risikoer, leverandører, oppgaver og bevis sitter sammen, med lenker som gjør det enkelt å følge bildet av skystyringen.

Hvilke kontrakter og tjenestenivåavtaler bør en MSP tilpasse for å demonstrere A.5.23 til kunder?

For å demonstrere A.5.23 på en overbevisende måte, må både oppstrøms- og nedstrømsavtalene dine samsvare med måten du faktisk håndterer skyrisiko på. Det betyr at kontraktene og tjenestenivåavtalene dine med leverandører og underdatabehandlere, og vilkårene dine med kunder, alle bør peke på de samme ansvarsfordelingene og funksjonene som du dokumenterer i ISMS-systemet ditt.

Hva bør du sjekke i avtaler mellom oppstrøms leverandører og underdatabehandlere?

Gjennomgå delene av hver avtale som direkte påvirker tjenestene og kravene dine:

Sikkerhets- og tilgjengelighetsforpliktelser: – sørg for at RPO/RTO-mål, SLA-er for oppetid og dataholdbarhet samsvarer med hvordan du designer tjenester og løftene i dine egne SLA-er.
Erklæringer om dataplassering og bosted: – du bør kunne svare på spørsmålet «hvor er dataene våre?» med sikkerhet, inkludert sikkerhetskopieringssteder og failover-regioner.
Hendelsesvarsling og eskalering: – sjekk hvordan og når leverandører forplikter seg til å informere deg om hendelser som kan påvirke kundene dine.
Støtte for viktige kontroller: – bekrefte om funksjoner som detaljert logging, kundeadministrerte krypteringsnøkler, uforanderlige sikkerhetskopier eller avanserte tilgangskontroller du stoler på er eksplisitt tilgjengelige og støttet.
Sikringsmekanismer: – identifiser sertifiseringer, bekreftelsesrapporter, sammendrag av penetrasjonstester eller kontraktsmessige revisjonsrettigheter som du kan bruke som bevis i ditt eget ISMS og kunderapportering.

Du trenger kanskje ikke å reforhandle alle kontrakter, men du bør forstå og dokumentere hvor en leverandørs forpliktelser ikke oppfyller dine nåværende tjenestebeskrivelser, og justere dine egne tilbud eller arkitekturer deretter.

Hvordan bør kundekontrakter og tjenestenivåavtaler endres for å gjenspeile A.5.23?

Nedstrøms bør dine kundevendte dokumenter:

Identifiser tydelig hvilke tjenester er avhengige av hvilke skyplattformer, spesielt der det påvirker dataplassering, robusthet eller støtte.
Forklar hvem er ansvarlig for hvilke kontrollområder – som for eksempel godkjenninger av brukertilgang, akseptabel bruk, klassifisering, juridiske forbehold og innholdslivssyklus – i tråd med deres delte ansvarsmatriser.
forplikte seg til gjenopprettingsmål, oppbevaringsperioder og tidsrammer for hendelseskommunikasjon som dine oppstrømsavtaler og -design kan levere pålitelig.
Referanse, eller lenke til, informasjon om ansvar og avhengighet på en måte kundene kan forstå uten å lese ISMS-en din.

Når oppstrømskontrakter, interne ansvarsmatriser og nedstrøms tjenestenivåavtaler forteller samme historie, er det mye enklere å veilede en kunde eller revisor gjennom hvordan du håndterer skyrisiko under A.5.23. Å administrere disse dokumentene i ISMS.online, sammen med dine retningslinjer og risikoer, hjelper deg med å holde narrativet samstemt etter hvert som leverandører oppdaterer sine vilkår, regelverk utvikler seg og kundene blir mer krevende.

Hvordan kan en MSP bruke ISMS.online til å holde A.5.23 under kontroll etter hvert som skytjenester endres?

ISMS.online hjelper deg med å holde A.5.23 under kontroll ved å gjøre skystyring om til et kontinuerlig oppdatert, tilkoblet system , i stedet for et sett med statiske dokumenter som henger etter endringer i stacken din. Når du tar i bruk, endrer eller pensjonerer skytjenester, kan ISMS-visningen din forbli oppdatert, reviderbar og forklarbar.

Hvordan ser den daglige A.5.23-administrasjonen ut i ISMS.online?

I et typisk oppsett ville teamet ditt bruke ISMS.online til å:

Vedlikehold et aktivt register over skytjenester

Registrer hver skytjeneste med eier, formål, datatyper, dataplasseringer og kritiskhet.
Taggtjenester brukt internt kontra de som brukes til å levere administrerte tjenester.
Koble hver oppføring til relevante retningslinjer, risikoer, leverandører og ansvarsmatriser.

Fest og spor skyspesifikke risikoer og behandlinger

Opprett risikooppføringer for eksponering mot flere leietakere, kraftige kontoer på tvers av leietakere, dataopphold, leverandørlåsing og API-avhengigheter.
Tildel behandlinger, eiere og evalueringsdatoer.
Bruk plattformens tilknyttede arbeid og prosjekter til å spore utbedrings- og forbedringstiltak.

Lagre kontrakter, sertifiseringer og due diligence på ett sted

Last opp leverandørkontrakter, databehandleravtaler, sikkerhetssammendrag og garantirapporter direkte mot leverandørens registre.
Registrer resultater og beslutninger fra evalueringer, slik at du kan vise at leverandørens risiko håndteres over tid.

Sentraliser delte ansvarsmatriser

Oppretthold én autoritativ matrise per større skytjeneste eller tjenestefamilie.
Koble matriser til policyer, tjenestebeskrivelser, risikooppføringer og leverandørregistre.
Bruk dem som referansepunkter når du oppdaterer runbooks, tjenestenivåavtaler og onboarding-materiell.

Aktiviteter i bevisets livssyklus

Loggvalg, onboarding, godkjenninger av konfigurasjonsgrunnlinjer, endringsgjennomganger, periodiske revurderinger og avslutningstrinn som oppgaver eller lenkede arbeidselementer.
Knytt relaterte hendelser, sikkerhetskopieringstester, tilgangsgjennomganger og forbedringer til relevante tjenester og risikoer.

Når du tar i bruk en ny plattform, kan du klone en eksisterende oppføring, justere konfigurasjon og ansvar, og koble den til risikoer og leverandører i løpet av få minutter. Når du avvikler en tjeneste, kan du registrere datamigrering, sanering og beslutninger om bevisoppbevaring på samme sted.

For revisjoner, kundespørreskjemaer eller styremøter kan du deretter sette sammen en fokusert A.5.23-dokumentasjonspakke direkte fra ISMS.online: skypolicyen, gjeldende register, eksempler på ansvarsmatriser, viktige skyrisikoer og -behandlinger, leverandørens due diligence og et utvalg av livssyklus- og hendelsesrapporter. Denne evnen til å fortelle en konsistent, ende-til-ende-historie er det som får en MSP til å se ut som om de har kontroll over skystyringen i stedet for å stadig reagere. Hvis du vil at kunder og revisorer skal se deg i den første gruppen, er det å investere i å strukturere A.5.23 riktig i ISMS.online et neste skritt med høy innflytelse.

A.5.23 Informasjonssikkerhet for bruk av skytjenester – MSP-skyplattformer og delt ansvar