Hvorfor MSP ICT-forsyningskæder nu former dine største sikkerhedsrisici

Hvorfor MSP-forsyningskæder nu er din største angrebsflade

Moderne udbydere af administrerede tjenester står over for en voksende risiko fra IKT-forsyningskæder, ikke kun fra deres egne datacentre. Upstream-værktøjer, platforme og partnere kan blive til enkeltstående fejlpunkter, der, når de er kompromitteret eller utilgængelige, påvirker mange kunder og tjenester på én gang. Bilag A.5.21 findes for at hjælpe dig med at forstå disse afhængigheder, aftale klare sikkerhedsforventninger med leverandører og kunder og behandle risiko i forsyningskæden som en bevidst del af dit ISMS snarere end en eftertanke.

For mange udbydere af administrerede tjenester er forsyningskæden af værktøjer, platforme og partnere, som I er afhængige af, blevet en af de mest risikable dele af jeres miljø, sammen med jeres eget datacenter. Disse delte komponenter understøtter jeres omsætning, jeres kontrakter og jeres regulatoriske løfter. Når en af dem fejler eller kompromitteres, kan virkningen ramme mange kunder i løbet af få timer, og derfor er bilag A.5.21 så vigtigt for at forvandle dette netværk af afhængigheder til noget, I bevidst designer og administrerer.

Moderne MSP'er arver risiko fra multi-tenant-karakteren af fjernadministrationsplatforme, cloud-tjenester, identitetsudbydere og nicheværktøjer, der ligger mellem dig og dine kunder. Et enkelt upstream-kompromis kan give en angriber privilegeret adgang til en stor del af din kundebase. Ligeledes kan et nedbrud i en kerneplatform føre til, at flere klienter er offline på én gang, uanset hvor godt du driver din egen infrastruktur.

Stærke forsyningskæder starter med at vide, hvem man virkelig er afhængig af.

Den nye virkelighed for MSP-forsyningskæderisiko

Den nye virkelighed for MSP'er er, at angribere og udfald nu bevæger sig hurtigere gennem delte IKT-platforme end gennem individuelle kunders netværk. Når du integrerer fjernstyringsværktøjer, cloudtjenester, identitetsplatforme og sikkerhedsprodukter i dine tilbud, bliver hver delt komponent et potentielt enkelt fejlpunkt. Bilag A.5.21 er designet til at hjælpe dig med at erkende denne virkelighed og opbygge forholdsmæssige kontroller omkring den.

Moderne MSP'er arver det meste af deres forsyningskæderisiko fra de cloudplatforme, SaaS-værktøjer og underleverandører, de integrerer i deres tjenester. Efterhånden som du sammensætter nye tilbud, er det naturligt at fortsætte med at tilføje specialiserede platforme, overvågningsværktøjer, backupudbydere og sikkerhedstjenester oven i et kernesæt af funktioner.

Rapporten State of Information Security 2025 viser, at et flertal af organisationer oplevede mindst én sikkerhedshændelse i det seneste år, der stammede fra en tredjepart eller leverandør.

Over tid skaber denne vækst tætte, flerlags afhængighedskæder: fjernovervågningsværktøjer oven på public cloud, identitetsplatforme knyttet til kundelejere, backupudbydere, der replikerer data mellem regioner, og specialiserede sikkerhedsværktøjer integreret via API'er. Angribere behøver ikke at målrette hver kunde individuelt. Kompromittering af én upstream-tjeneste kan give privilegeret adgang til mange administrerede miljøer eller tillade ransomware at sprede sig hurtigt mellem klienter, der deler de samme værktøjer. Analyser af software-forsyningskædehændelser beskriver præcis dette mønster, hvor kompromittering af en udbredt leverandør eller komponent kan påvirke et stort antal downstream-organisationer på én gang (analyse af software-forsyningskædeangreb).

Afbrydelser opfører sig på samme måde. En fejl i en central identitetsudbyder eller en fjernstyringsstak kan føre til offline-situationer for flere kunder, udløse kontraktlige sanktioner og tiltrække sig opmærksomhed fra myndighederne, selvom din egen infrastruktur ikke påvirkes. Branchevejledning om vurdering og håndtering af cybersikkerhedsrisici i forsyningskæden fremhæver ofte, hvordan afbrydelser eller kompromittering af delte cloud- eller identitetstjenester kan føre til samtidige afbrydelser og forretningsmæssige konsekvenser for mange kunder, samt kontraktlige og lovgivningsmæssige konsekvenser for udbydere, der er afhængige af dem (oversigt over cybersikkerhedsrisici i forsyningskæden). Bilag A.5.21 er rettet direkte mod den kombinerede tekniske og kontraktlige eksplosionsradius, ikke kun mod isolerede sårbarheder.

Sikkerhedsmålinger hos mange MSP'er har ikke indhentet dette skift. Teams sporer stadig perimeterhændelser, patchrater og endpoint-advarsler, men har ringe overblik over nedarvede sårbarheder eller leverandørdrevne hændelser. Uden et klart overblik over upstream-afhængigheder og deres risikoprofiler kører du effektivt i blinde på de steder, hvor fejl er mest tilbøjelige til at skade, hvilket er grunden til, at du har brug for forsyningskædeoversigter i dit ISMS i stedet for netværksmålinger alene.

Hvor synligheden virkelig bryder sammen

Synligheden bryder normalt sammen i den "skygge" forsyningskæde: værktøjer, tjenester og partnere, der er sneget sig ind uden for formel indkøb. Disse ser ofte ud som engangsbeslutninger på et givet tidspunkt, men de bliver en del af dit permanente afhængighedskort.

De fleste MSP'er kan angive deres primære leverandører udenad, men få kan vise et komplet billede af, hvem og hvad de virkelig stoler på. Freemium-tjenester taget i brug af ingeniører, "midlertidige" pilotværktøjer, der aldrig ophørte, og kundepålagte platforme, som du har indvilliget i at understøtte, bidrager alle til dette skjulte lag.

Problemet er, at angribere og regulatorer er ligeglade med, om en afhængighed blev formelt godkendt eller stille og roligt implementeret. Hvis et kompromitteret system passerer gennem det og ind i dine administrerede miljøer, vil kunderne stadig forvente svar fra dig. Bilag A.5.21 behandler disse relationer som værende inden for rammerne af scope. Det forventes, at du inkluderer dem i dit forsyningskædekort, klassificerer dem og beslutter, hvad "sikker nok" betyder for hver enkelt baseret på risiko.

Et praktisk første skridt er at kortlægge eksplosionsradiusen for dine mest kritiske delte komponenter. For hvert større værktøj eller platform skal du estimere, hvor mange kunder, hvilke typer data og hvilke tjenester der er afhængige af det. Når en enkelt fjernstyringsstak understøtter en betydelig del af din omsætning, er det ofte det øjeblik, hvor risiko i forsyningskæden holder op med at føles abstrakt og begynder at kræve strukturerede kontroller.

Hvorfor din bestyrelse bør bekymre sig lige så meget som dine ingeniører

Jeres bestyrelse og ledende medarbejdere skal se IKT-forsyningskædens sikkerhed som et ledelsesspørgsmål, ikke blot et teknisk anliggende for ingeniører. Kunder, forsikringsselskaber og tilsynsmyndigheder spørger i stigende grad, hvordan tredjeparts- og outsourcede IT-risici identificeres, vurderes og kontrolleres, og de forventer sammenhængende svar, der rækker ud over sikkerhedsteamet. Brancheorganisationer, der overvåger software- og IKT-forsyningskædetrusler, bemærker, at eksterne interessenter er mere opmærksomme på, hvordan organisationer håndterer tredjepartsrisici, ikke blot hvilke teknologier de implementerer (voksende trussel fra software-forsyningskædeangreb).

Ifølge ISMS.online-undersøgelsen fra 2025 forventer kunderne i stigende grad, at leverandørerne overholder formelle rammer som ISO 27001, ISO 27701, GDPR eller SOC 2 i stedet for at stole på generiske påstande om god praksis.

Når interessenter indser, at dine administrerede tjenester ligger oven på andre leverandører, der selv kan være mål, leder de efter bevis for, at du forstår og administrerer disse forbindelser. Sikkerhed i forsyningskæden bliver et emne på bestyrelsesniveau, fordi fejl her kan føre til driftsafbrydelser, regulatorisk kontrol og omdømmeskade på samme tid.

Ledelse har typisk brug for sikkerhed for, at:

Kritiske upstream-værktøjer og partnere identificeres, risikovurderes og kontraktligt forpligtes til at opfylde sikkerhedsforventningerne.
Organisationen forstår, hvilke kunder og tjenester der vil blive påvirket af bestemte upstream-fejl.
Der findes afprøvede håndbøger for leverandørhændelser, der dækker teknisk respons, kommunikation og kontraktlige forpligtelser.

Uden den sikkerhed lander vanskelige spørgsmål i bestyrelseslokalet på det værst tænkelige tidspunkt: under et strømafbrydelse, et brud eller en revision. Ved at behandle bilag A.5.21 som den formelle rygrad i din IKT-forsyningskædesikring får lederne et standardbaseret grundlag, de kan stole på, i stedet for improviserede forklaringer under pres.

Book en demo

Bilag A.5.21 og den nye definition af IKT-forsyningskædesikring

Bilag A.5.21 beder dig om at aftale, dokumentere og vedligeholde passende forventninger til informationssikkerhed med de IKT-leverandører og kunder, du er afhængig af. I praksis bør du vide, hvem du stoler på, hvad du forventer af dem, hvad de forventer af dig, og hvordan disse forventninger kontrolleres over tid. For en MSP betyder det at erkende, at du sidder i mange kunders IKT-forsyningskæder, samt at du styrer din egen. Dette afspejler den måde, ISO/IEC 27001:2022 beskriver kontrol A.5.21 i sit katalog over informationssikkerhedskontroller til IKT-forsyningskæder (ISO/IEC 27001:2022 oversigt).

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

Taget alvorligt, flytter Anneks A.5.21 IKT-forsyningskædesikring fra mavefornemmelse til risikobaseret, dokumenteret praksis. Det bygger på den bredere familie af Anneks A-kontroller for leverandørrelationer, kontrakter og overvågning og anvender dem specifikt på IKT-produkter og -tjenester. At forstå, hvordan det passer sammen med A.5.19, A.5.20 og A.5.22, giver dig en ramme for at gøre dette uden at genopfinde hele dit ISMS.

En integreret ISMS-platform som ISMS.online kan hjælpe dig med at holde overblikket samlet ét sted ved at forbinde leverandører, kunder, tjenester, risici og bilag A-kontroller, så de er nemme at gennemgå og opdatere, efterhånden som din virksomhed udvikler sig.

Disse oplysninger er generelle og udgør ikke juridisk rådgivning; organisationer bør søge passende professionel vejledning i forbindelse med lovgivningsmæssige beslutninger.

Hvad bilag A.5.21 rent faktisk forventer

Bilag A.5.21 forventer, at I behandler IKT-forsyningskædesikkerhed som et kontinuerligt, delt ansvar snarere end en engangskontraktklausul. Det forstærker ideen om, at forventninger bør være risikobaserede, dokumenterede og vedligeholdt over tid i stedet for at være antaget eller fastsat én gang og glemt. For MSP'er betyder det at udforme upstream- og downstream-forventninger og kontrollere, at de fortsat giver mening, efterhånden som tjenester og risici ændrer sig.

Bilag A.5.21 findes side om side med tre nært beslægtede kontroller:

A.5.19, som dækker politikker for leverandørrelationer.
A.5.20, som fokuserer på at sikre, at informationssikkerhed er adresseret i leverandøraftaler.
A.5.22, som omhandler overvågning, gennemgang og ændringsstyring af leverandørtjenester.

Samlet set kan disse kontroller i dagligdags sprog forstås som: identificer din IKT-forsyningskæde, definer de informationssikkerhedskrav, du forventer af den, integrer disse krav i, hvordan du udvælger, indgår kontrakter med og fører tilsyn med leverandører, og hold tilsynet kørende, efterhånden som tjenesterne ændrer sig. Bilag A.5.21 er, hvor dette specifikt handler om IKT-tjenester og -produkter, både upstream og downstream. Disse kontroltitler og -grupperinger følger den struktur, der er offentliggjort i ISO/IEC 27001:2022, som beskriver bilag A-kontrollerne og deres fokusområder for leverandør- og IKT-forsyningskædesikkerhed (ISO/IEC 27001:2022 oversigt).

For en MSP er der et ekstra twist. Du er både kunde og leverandør. Du er afhængig af upstream ICT-tjenester til at levere dine tilbud, og du er en kritisk leverandør i dine kunders egne ICT-forsyningskæder. Bilag A.5.21 forventer, at du håndterer begge sider konsekvent på en måde, der afspejler risiko og er integreret i de daglige processer og ikke håndteres i isolerede dokumenter.

At gøre standardtekst til noget, som alle kan forstå

Dine teams er mere tilbøjelige til at engagere sig, hvis du oversætter standardens sprog til et lille sæt klare, praktiske forpligtelser. Disse forpligtelser bør beskrive, hvad du rent faktisk gør, på en måde, som ingeniører, kundechefer og juridiske teams genkender, i stedet for at citere standarden.

Du kan gentage bilag A.5.21 som forpligtelser såsom:

"Vi undersøger og klassificerer de IKT-leverandører og -platforme, vi er afhængige af, og bruger dem, når de opfylder de aftalte sikkerhedskriterier."
"Vi definerer og dokumenterer, hvem der er ansvarlig for hvilke sikkerhedsforanstaltninger i alle de administrerede tjenester, vi sælger."
"Vi overvåger vigtige leverandører og tjenester over tid og reagerer hurtigt og transparent, når noget ændrer sig eller går galt."

Når du har disse oversættelser, bliver det meget nemmere at se, hvor du allerede har dele af bilag A.5.21 på plads, såsom onboarding-tjek af leverandører, kontraktskabeloner eller periodiske gennemgange. Det fremhæver også, hvor praksis er ad hoc, udokumenteret eller afhænger af individuelle medarbejdere. Denne kortlægning giver dig et udgangspunkt for det mere detaljerede upstream- og downstream-designarbejde, der følger.

Bilag A.5.21 forventer, at dine krav står i forhold til risikoen i stedet for at blive kopieret blindt fra ét forhold til et andet. Leverandører og kunder med stor indflydelse har normalt brug for dybere omhu og stærkere forpligtelser end leverandører med lav indflydelse, og det samme princip gør dine downstream-kontrakter mere forsvarlige for tilsynsmyndigheder og revisorer.

Kontrollen indebærer ikke, at du skal pålægge alle leverandører eller kunder identiske detaljerede sikkerhedsforventninger. Den forventer, at du retfærdiggør dine forventninger i lyset af risikoen. En kritisk cloudplatform, der hoster kundedata, kræver dybere due diligence, stærkere kontraktklausuler og mere intensiv overvågning end et lavrisikoværktøj, der ikke er kritisk.

Den samme logik gælder efterfølgende. En administreret service leveret til et hospital eller en finansiel institution medfører andre forpligtelser og kontrol end en service leveret til en lille, ureguleret virksomhed. Jeres implementering af bilag A.5.21 er troværdig, når disse forskelle er synlige i jeres risikovurderinger og i den måde, I strukturerer aftaler på, ikke når alle relationer bruger kopier-og-sæt-ind formuleringer uanset konsekvenser.

Det kan være en hjælp at tilpasse bilag A.5.21 til rammer, du allerede bruger, såsom SOC 2, anerkendte cybersikkerhedsretningslinjer eller nationale anbefalinger til forsyningskæder. Bedste praksis for forsyningskæder fra sikkerhedsleverandører og -praktikere opfordrer dig til at kortlægge fælles kontrolmål på tværs af standarder som ISO 27001, SOC 2 og nationale cybersikkerhedsrammer, så teams ikke opretholder flere modstridende sæt af krav (oversigt over sikkerhedspraksis i forsyningskæden). Her betyder "lagdeling" blot at gruppere leverandører og kunder i et par effektbaserede niveauer i stedet for at behandle hvert forhold som unikt.

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

ISO 27001 gjort nemt

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

Kom i gang

Upstream vs. downstream-kontroller i en MSP-kontekst

I en MSP dækker "upstream" de leverandører, platforme og underleverandører, du er afhængig af, mens "downstream" dækker de kunder og lejere, der er afhængige af dig. Bilag A.5.21 er lettere at implementere, når du behandler disse relationer som adskilte, men forbundne, med klare ansvarsområder og forventninger i hver retning. Denne struktur forvandler abstrakte forsyningskædeproblemer til kontrakter, playbooks og dashboards, som folk kan handle ud fra.

En klar upstream/downstream-model omdanner standardtekst til brugbare kontrakter, runbooks og dashboards. Du kan definere, hvordan du udvælger og overvåger leverandører, hvordan du deler ansvaret med kunderne, og hvordan du reagerer, når der opstår hændelser i begge retninger. Når denne struktur er på papiret, bliver det meget mere ligetil at operationalisere den i værktøjer og adfærd.

Definition af upstream-, downstream- og hybridrelationer

Din første opgave er at navngive og klassificere de eksterne relationer, du er afhængig af, i stedet for at behandle dem alle som generiske "leverandører" eller "kunder". Denne klassificering former, hvilke dele af bilag A.5.21 der er stærkest gældende, og hvor du skal fokusere din designindsats. Den skaber også et fælles sprog i din organisation, når du diskuterer risiko i forsyningskæden.

Start med at liste eksterne parter og klassificere dem ud fra to dimensioner: Leverer de til dig, eller leverer du til dem, og hvor kritiske er de for dine tjenester? En upstream-IKT-leverandør kan være en udbyder af cloudinfrastruktur, et fjernovervågningsværktøj, en backupplatform eller en specialiseret sikkerhedspartner. Downstream-parter er dine kunder inden for administrerede tjenester, herunder dem, hvor du fungerer som databehandler i henhold til databeskyttelseslovgivningen.

Nogle relationer er hybride. En peer-MSP i en fælles administreret aftale leverer både bestemte funktioner til dig og er afhængig af dine tjenester til gengæld. En kunde, der er vært for sin egen cloud-lejer, men beder dig om at administrere den, udvisker grænsen mellem kundens platform og upstream-miljøet. Disse hybrider kræver særlig omhu, fordi det er nemt for begge sider at påtage sig vigtige ansvarsområder eller ingen af dem.

Når du har registreret disse roller, kan du begynde at definere, hvilke kategorier af kontroller der gælder for hvilke roller. For upstream-relationer bliver due diligence, sikker teknisk integration, hændelsesnotifikation og underdatabehandlerkontroller centrale. For downstream-relationer er delt ansvar, grundlæggende sikkerhedsforventninger og kundeforpligtelser mere fremtrædende. Hybride ordninger kræver en blanding og meget klare grænser for at forhindre huller.

Brug af risikobaserede niveauer til at skabe struktur

Risikobaserede niveauer forvandler en lang liste af leverandører og kunder til noget, du kan arbejde med. Ved at gruppere relationer i et par effektbaserede klasser kan du definere standardkontrolsæt for hvert niveau i stedet for at designe alle relationer fra bunden.

Du kan for eksempel oprette tre niveauer for upstream-leverandører:

Niveau 1: kritiske platforme med privilegeret adgang eller hosting af kundedata.
Niveau 2: vigtige supporttjenester med begrænset direkte adgang til kundens systemer.
Niveau 3: Lavrisikoværktøjer uden adgang til følsomme data eller produktionsmiljøer.

Nedstrøms kan du anvende niveauer som "reguleret", "høj tilgængelighed" og "standard", baseret på datafølsomheden og den forretningsmæssige indvirkning af afbrydelser.

Hver kombination af upstream- og downstream-niveauer skaber forskellige forventninger. En Tier 1 upstream-platform, der understøtter en reguleret sundhedsklient, kræver dybere sikkerhed og strengere kontroller end et Tier 2-værktøj, der understøtter en standardklient. Ved at dokumentere disse kombinationer i enkle mønstre - for eksempel "MSP-hyperscaler-reguleret klient" versus "MSP-distributør-MSP-virksomhed" - kan du designe standardkontrolsæt i stedet for at starte forfra for hver ny relation.

En kortfattet måde at visualisere dette på er gennem en lille matrix, der viser, hvordan ansvarsområder varierer efter relationstype.

Relationstype	Opstrømsansvar (eksempler)	Nedstrømsansvar (eksempler)
MSP – cloudplatform – reguleret klient	Certificeringer, hændelsesmeddelelser, segmentering, adgangslogfiler	Godkendelser, databeskyttelsesforpligtelser, sikkerhedskommunikation med kunder
MSP – SaaS-sikkerhedsværktøj – blandede klienter	Sikker integration, rolledesign, overvågning, leverandørgennemgang	Kundens kendskab til værktøjets omfang, samtykke hvor det er nødvendigt
MSP – peer MSP (fællestyret) – klient	Grænsedefinition, fælles håndtering af hændelser, delt adgang	Kunden forstår opgavefordeling og eskaleringsveje

Som tabellen antyder, ændrer ansvarsområderne sig markant mellem f.eks. et hyperscaler-scenarie og en fælles administreret MSP-aftale. I praksis kan du starte med at kortlægge dine nuværende relationer i et af disse mønstre, bekræfte hvilke opgaver der falder hvor, og derefter standardisere dine kontraktklausuler og interne runbooks omkring disse mønstre.

Design af upstream-kontroller for leverandører og underdatabehandlere

Upstream-kontroller definerer, hvordan du vælger, onboarder, overvåger og forlader de leverandører og platforme, du er afhængig af. En simpel, gentagelig livscyklus forvandler leverandørtillid fra antagelse til bevis, der understøttes af risikovurderinger, kontrakter og konfiguration. Bilag A.5.21 forventer, at livscyklussen står i forhold til risikoen og anvendes konsekvent på de leverandører, der betyder mest.

Godt upstream-design omdanner tillid fra en uformel vurdering til en dokumenteret beslutning. Det betyder at forstå, hvad hver leverandør gør for dig, hvilke risici du arver, hvilke kontroller de opererer, og hvilke du selv skal sørge for. En risikobaseret livscyklus gør dette håndterbart og giver revisorer tillid til, at du ikke behandler leverandører som en sort boks.

Opbygning af en leverandørlivscyklus, som revisorer genkender

Revisorer leder generelt efter en klar, risikobaseret livscyklus for kritiske leverandører: hvordan du vurderer en leverandør før brug, hvordan du integrerer kontroller, når du implementerer dem, hvordan du holder tilsynet kørende, og hvordan du afgår sikkert. Hvis du kan vise disse trin og dokumentationen bag dem, vil din Annex A.5.21-etage føles troværdig og komplet. Vejledning om leverandørrisiko fra institutter som SANS beskriver risikobaserede leverandørlivscyklusser - der dækker udvælgelse, onboarding, løbende tilsyn og afgang - som et kendetegn for moden tredjepartssikkerhedsstyring (SANS leverandørrisiko-hvidbog).

Rapporten State of Information Security 2025 viser, at et flertal af organisationer allerede har styrket tredjepartsrisikostyring og planlægger at investere yderligere i det.

En praktisk upstream-livscyklus har fire faser: due diligence før engagement, onboarding, business-as-usual-tilsyn og exit. For hver fase skal du definere, hvad der forventes for hvert leverandørniveau, og hvilke artefakter der skal være til stede for at bevise, at disse aktiviteter har fundet sted.

Trin 1: Udfør risikobaseret due diligence

Risikobaseret due diligence handler om at indsamle tilstrækkelige oplysninger til at forstå en leverandørs sikkerhedsstatus og hvordan den stemmer overens med dine behov. Dette omfatter typisk uafhængige certificeringer, sikkerhedserklæringer på overordnet niveau, opsummeringer af test, roller i behandling af personoplysninger og oplysninger om underdatabehandlere. Resultatet bør være en udfyldt vurderingsrapport, der forklarer, hvorfor leverandøren er acceptabel på det valgte niveau.

Trin 2: Onboarding med konkrete tekniske og kontraktmæssige kontroller

Onboarding forvandler vurdering til konkrete kontroller. For en kritisk platform kan dette omfatte konfiguration af stærk autentificering, begrænsning af administrative roller, aktivering og integration af logføring og aftale om tidsfrister for hændelsesmeddelelser og kontaktpunkter. En simpel onboarding-tjekliste hjælper med at sikre, at disse trin ikke overses, og at en person tydeligt er ansvarlig for hvert trin.

Trin 3: Oprethold overvågning som sædvanlig

Business-as-usual-tilsyn skal være let, men reelt. For leverandører med stor indflydelse skal du fastsætte gennemgangskadenser for at bekræfte, at certificeringer opretholdes, sikkerhedsforpligtelser stadig gælder, og at der ikke er sket større ændringer uden din viden. For lavere niveauer kan gennemgange udløses af begivenheder såsom serviceændringer, nye datastrømme eller hændelser. Optegnelser over disse gennemgange, selvom de er korte, viser, at tilsynet er aktivt snarere end antaget.

Trin 4: Sikker afkørsel, og opdater dit forsyningskædekort

Udgang overses ofte, men er afgørende. Når du stopper med at bruge en leverandør eller skifter til en ny platform, bør der være en defineret proces til at tilbagekalde adgang, returnere eller sikkert slette data og opdatere din dokumentation, så dit forsyningskædekort forbliver nøjagtigt. En kort udgangstjekliste og en opdateret registerpost viser, at du har lukket forholdet på en kontrolleret måde.

Revisorer forventer ikke perfektion, men de forventer at se, at en sådan livscyklus eksisterer, er risikobaseret og følges i praksis for kritiske leverandører.

Ingen leverandør er perfekt, og bilag A.5.21 kræver ikke perfektion. Det forventes, at du træffer informerede, dokumenterede beslutninger om de risici, du arver, og de kompenserende kontroller, du anvender, og at du er i stand til at forklare disse beslutninger til revisorer og kunder.

Ikke alle leverandører vil opfylde alle ideelle kontroller, og det behøver ikke alle leverandører. Det, der betyder noget, er din evne til at forklare, hvorfor et forhold er acceptabelt i betragtning af den risiko, det introducerer. Lagdeling hjælper, men du har også brug for klarhed over, hvornår du er tryg ved at arve kontroller fra en leverandørs eget sikkerhedsrammeværk, og hvornår du foretrækker kompenserende foranstaltninger.

Hvis en stor cloududbyder for eksempel har bredt anerkendte certificeringer og følger en stærk sikkerhedsstandard, er det normalt rimeligt at stole på disse for mange underliggende kontroller, forudsat at du administrerer din konfiguration sikkert. I modsætning hertil kan du for en mindre specialiseret platform med mindre formel sikring beslutte at begrænse dens omfang, kræve specifikke kontraktlige forpligtelser eller tilføje din egen overvågning og testning.

Hændelseshåndtering fortjener særlig opmærksomhed. For kerneplatforme bør der være eksplicitte forpligtelser til, hvor hurtigt I vil blive underrettet om et sikkerhedsproblem, hvilke oplysninger I vil modtage, og hvordan I kan koordinere reaktioner for at beskytte jeres kunder. Disse forventninger er bedst skrevet ind i kontrakter eller serviceaftaler i stedet for at blive efterladt som uformelle aftaler.

Dokumentation af disse vurderinger i dit risikoregister og din anvendelighedserklæring viser revisorerne, at bilag A.5.21 anvendes omhyggeligt og ikke automatisk. Din anvendelighedserklæring er blot din formelle liste over bilag A-kontroller, hvor du forklarer, hvilke der gælder, hvordan og hvorfor.

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

Book din demo

Design af downstream-kontroller for kunder og deres forpligtelser

Downstream-kontroller definerer, hvordan I deler ansvaret med kunderne, og hvad I forventer af dem for at holde tjenesterne sikre. For MSP'er reducerer klare downstream-kontroller risikoen for at blive bebrejdet for eksponeringer, der ligger hos kunden, og viser tilsynsmyndighederne, at I har sat passende, dokumenterede forventninger. Bilag A.5.21 understreger behovet for at gøre disse forventninger eksplicitte, håndhævelige og evidensbaserede.

I praksis handler downstream-kontrol om at sætte grænser og sikre, at alle forstår dem. Du definerer, hvad du gør som standard, hvad kunderne skal gøre, og hvordan du vil demonstrere, at begge sider lever op til deres ansvar. Når dette gøres godt, starter samtaler om hændelser, nye krav eller yderligere tjenester ud fra en fælles forståelse i stedet for en uenighed om, hvem der var ansvarlig.

Design af servicespecifikke modeller for delt ansvar

En nyttig model for delt ansvar fortæller kunderne, i et letforståeligt sprog, hvilke dele af sikkerheden du ejer, og hvilke de ejer for en given tjeneste. Forskellige tjenestefamilier har forskellige opdelinger, så hver har brug for sin egen simple model, der afspejler, hvordan tjenesten er designet i virkeligheden. I denne sammenhæng er en model for delt ansvar blot en klar beskrivelse af, hvordan sikkerhedsopgaver er fordelt mellem dig og kunden.

For hver servicefamilie skal du opbygge en model for delt ansvar, der besvarer tre spørgsmål:

Hvilken konfiguration og overvågning tilbyder I som standard?
Hvad skal kunden gøre for at gøre det effektivt?
Hvordan vil du bevise, at begge sider gør deres del?

For eksempel kan dine ansvarsområder for en administreret Microsoft 365-tjeneste omfatte konfiguration af politikker for betinget adgang, aktivering af logføring og overvågning af vigtige advarsler. Kundens ansvarsområder kan omfatte at holde brugeroplysninger nøjagtige, håndhæve politikker for acceptabel brug og reagere hurtigt på sikkerhedsmeddelelser. Dokumentation af modellen kan omfatte periodiske konfigurationsrapporter og dokumenterede kundegodkendelser.

Disse modeller bør være skrevet i et tilgængeligt sprog, genbruges på tværs af kontrakter og tilbud og understøttes af interne håndbøger, der viser dine teams, hvordan de kan opfylde deres del af aftalen. Når kunderne forstår modellen fra starten, bliver senere samtaler om sikkerhedshændelser eller yderligere forpligtelser baseret på den fælles forståelse snarere end på ad hoc-forventninger.

Fastsættelse af kundeforpligtelser og håndtering af manglende overholdelse

Kundens forpligtelser beskriver, hvad kunderne skal gøre for at gøre dine tjenester effektive og for at holde deres egen risiko inden for acceptable grænser. Bilag A.5.21 forventer, at du fastsætter disse forpligtelser klart, overvåger dem, hvor du kan, og på forhånd beslutter, hvordan du vil håndtere mangler.

Downstream-kontroller omfatter ofte forpligtelser såsom:

Vedligeholdelse af understøttede operativsystemer.
Sikre, at medarbejderne gennemfører sikkerhedsbevidsthedstræning.
Aktivering af multifaktor-godkendelse på deres egne systemer.
At give dig besked omgående om relevante ændringer i deres miljø.

Disse forpligtelser bør være passende i forhold til tjenesten og risikoprofilen, nedfældet i kontrakter eller sikkerhedsplaner og understøttet af enkle mekanismer til indsamling af dokumentation. Det kan omfatte periodiske attesteringer, tekniske kontroller, hvor du har indsigt, eller resultater fra fælles evalueringer.

Det er lige så vigtigt at beslutte på forhånd, hvordan man vil håndtere manglende overholdelse. Nogle mangler kan afbødes; andre kan føre til undtagelser, yderligere gebyrer eller i ekstreme tilfælde afvisning af at levere en tjeneste.

Trin 1: Definer, hvordan manglende overholdelse identificeres

Beslut hvilke forpligtelser du kan kontrollere teknisk, og hvilke der er baseret på kundeattestationer eller evalueringsmøder. Registrer kontrollerne i dine processer eller værktøjer, så manglende overholdelse er synlig.

Trin 2: Beslut, hvem der kan give og godkende undtagelser

Dokumentér hvilke roller, der kan godkende midlertidige undtagelser, under hvilke betingelser og hvor længe. Dette undgår kompromiser på stedet, der senere bliver permanente.

Trin 3: Registrer og gennemgå restrisiko

Sørg for, at undtagelser og tilfælde af manglende overholdelse registreres i dit risikoregister og gennemgås i relevante ledelsesfora. Dette viser, at du styrer, ikke ignorerer, den resterende risiko.

Tydelige downstream-modeller og forpligtelser er attraktive for modne kunder. De viser, at du tager deres risiko alvorligt, og at du er parat til at sætte og holde fornuftige grænser i stedet for at acceptere vage, uhåndhævelige løfter.

Styring, roller og livscyklus for forsyningskædekontrol

Forsyningskædesikkerhed skaleres kun, når nogen tydeligt tager ansvar for den, og resten af organisationen forstår deres rolle. Bilag A.5.21 bliver bæredygtigt, når det er integreret i styringen med definerede roller, ansvarsområder og gennemgangsrytmer, snarere end at blive efterladt som en uformel sideopgave for sikkerheden. Effektiv styring handler mindre om at oprette nye møder og mere om at stille bedre spørgsmål i de møder, du allerede har.

Hvis forsyningskædens sikkerhed behandles som "nogens problem" uden klarhed, vil det drive hen imod. Du skal beslutte, hvem der er ansvarlig for kontrollen, hvem der giver input, hvem der udfører specifikke opgaver, og hvor ofte præstationen evalueres. God ledelse handler om klare beslutninger og regelmæssig feedback, ikke flere møder.

Effektiv styring af forsyningskæden handler om at stille bedre spørgsmål i eksisterende møder.

Tildeling af ejerskab og RACI på tværs af virksomheden

En navngiven kontrolejer giver bilag A.5.21 et tydeligt præg, men succes afhænger af en koordineret indsats på tværs af indkøb, drift, juridiske forhold og kundestyring. En simpel RACI-model gør det tydeligt, hvem der gør hvad, hvem der godkender, og hvem der skal holdes informeret, når leverandør- eller kunderisici ændrer sig.

Et praktisk udgangspunkt er at udpege en enkelt kontrolejer til bilag A.5.21, ofte din informationssikkerhedsleder eller virtuelle CISO. Denne person er ansvarlig for at sikre, at kontrollen er designet og fungerer, men de kan ikke udføre den alene. Indkøb, jura, drift og kundestyring har alle roller at spille.

En simpel RACI-matrix (Responsible, Accountable, Consulted, Informed) hjælper. For eksempel til onboarding af en ny Tier 1-leverandør:

Indkøb er ansvarlig for at sikre, at aftalte sikkerhedsklausuler er i kontrakten.
Informationssikkerhedslederen er ansvarlig for at godkende leverandørens risikovurdering og -niveau.
Juridisk rådgivning finder sted om komplekse vilkår, undtagelser og ansvar.
Drifts- og kundeadministration informeres om forpligtelser, der påvirker, hvordan de leverer tjenester.

Når denne fordeling er tydelig, holder kollegerne op med at se bilag A.5.21 som "ISO-personens problem" og begynder at forstå deres egen rolle i at løse det.

Valg af styringsrytmer, der passer til driften

Governance fungerer bedst, når spørgsmål vedrørende forsyningskæden er indbygget i møder, der allerede er vigtige, såsom risikoudvalg, ledelsesgennemgange og servicegennemgange. Bilag A.5.21 kræver ikke nyt bureaukrati; det kræver, at du stiller de rigtige spørgsmål om leverandører og kunder på de rigtige tidspunkter og registrerer svarene.

Kontrollerne forbliver mere tilbøjelige til at forblive aktive, når de følger rytmer, som organisationen allerede respekterer. For forsyningskædens sikkerhed kan det betyde:

Inkludering af centrale emner vedrørende leverandør- og kunderisiko som faste dagsordenspunkter i eksisterende risiko- eller serviceevalueringsudvalg.
Planlægning af periodiske gennemgange af kritiske leverandører og højrisikokunder i overensstemmelse med kontraktcyklusser eller væsentlige ændringer.
Gennemgang af hændelser og nærved-ulykker relateret til forsyningskæden i evalueringer efter hændelser og tilbageføring af erfaringer i leverandør- og kundestyring.

Undgå at oprette helt nye udvalg, medmindre du har brug for dem; væv i stedet bilag A.5.21 ind i etablerede ledelsesfora. For eksempel kan din ISO 27001-ledelsesevaluering eksplicit dække præstation i forhold til forsyningskædeindikatorer, såsom antallet af kritiske leverandører uden aktuelle vurderinger, hyppigheden af leverandørrelaterede hændelser eller rettidigheden af hændelsesmeddelelser.

Governance bør også omfatte mindre synlige relationer, såsom underleverandører, der anvendes til dækning uden for normal arbejdstid, eller white-label-udbydere, der leverer tjenester under dit brand. Billedet af forsyningskæden er ufuldstændigt uden dem, og hændelser, der involverer disse parter, kan være lige så skadelige. At sikre, at de er omfattet af risikovurdering, kontraktlige kontroller og tilsyn, er en del af en troværdig implementering af bilag A.5.21.

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

Book din demo

Integration af A.5.19–A.5.22 med risiko-, leverandør- og ændringsprocesser

Bilag A.5.19-A.5.22 fungerer bedst, når de er vævet ind i processer, du allerede bruger til at håndtere risici, leverandører, ændringer og hændelser. I stedet for at stå adskilt som isolerede "ISO-opgaver" bør de afspejles i dit risikoregister, indkøbsworkflow, ændringsstyring og evalueringer efter hændelser, så forsyningskædetænkning bliver en del af det daglige arbejde. Denne integration er det, der forvandler politikerklæringer til konsekvent adfærd.

To tredjedele af organisationerne i undersøgelsen om informationssikkerhedens tilstand i 2025 sagde, at hastigheden og omfanget af lovgivningsmæssige ændringer gør det sværere at opretholde overholdelse af regler.

Det er nødvendigt, men ikke nok at designe politikker og modeller. Forsyningskædekontroller fungerer kun, når de er integreret i de formularer, supportsager og arbejdsgange, som folk allerede bruger til at anmode om ændringer, implementere nye værktøjer, vurdere risici og reagere på hændelser. Bilag A.5.19-A.5.22 er mest effektive, når de afspejles i, hvordan du registrerer risici, træffer leverandørbeslutninger, godkender ændringer og lærer af hændelser.

Integrering af forsyningskædetænkning i de daglige arbejdsgange

Det første skridt er at synliggøre risikoen i IKT-forsyningskæden sammen med andre risici. Det betyder, at du opretter eksplicitte risikoposter for kritiske tjenester og leverandører og registrerer, hvordan du planlægger at håndtere disse risici. Når dette er på plads, kan du tilføje små, obligatoriske kontrolpunkter til arbejdsgange, som dit team allerede følger, så beslutninger om leverandører og ændringer automatisk afspejler forventningerne i bilag A.

Start med at sikre, at dit centrale risikoregister eksplicit indfanger risici i IKT-forsyningskæden. For hver større service og kritisk leverandør bør der være risikoposter, der afspejler den potentielle indvirkning af deres svigt eller kompromittering, sammen med de valgte behandlinger. Dette sætter forsyningskæderisici sammen med andre sårbarheder og hjælper ledelsen med at forstå afvejninger.

Integrer derefter kontrolpunkter for forsyningskæden i eksisterende arbejdsgange:

Indkøbsprocesser bør omfatte opfordringer til at kontrollere, om en foreslået leverandør falder ind under et bestemt risikoniveau, om due diligence er gennemført, og om kontraktskabeloner indeholder de nødvendige sikkerhedsklausuler.
Ændringsanmodninger, der introducerer eller erstatter væsentlige værktøjer eller underdatabehandlere, bør automatisk udløse gennemgang af upstream- og downstream-påvirkninger, ikke kun teknisk kompatibilitet.
Servicedesign eller onboardingprocesser for nye kunder bør omfatte trin til at anvende den relevante model for delt ansvar og bekræfte, at forpligtelser downstream er dokumenteret og accepteret.

Disse prompts kan ofte tilføjes til formularer og billetskabeloner med minimal friktion, forudsat at de er obligatoriske for de scenarier, der er vigtige, og svarene registreres centralt, så de kan sendes tilbage til dine ISMS-registreringer.

Måling af præstation og læring af hændelser

Du kan ikke forbedre det, du ikke kan se. Bilag A.5.21 bliver langt mere værdifuldt, når du sporer, hvor godt forsyningskædekontrollerne fungerer, og bruger erfaringerne fra hændelser tilbage til dine niveauer, skabeloner og playbooks. Målet er ikke at reducere alle tal til nul, men at forstå, hvor dine største risici i forsyningskæden virkelig sidder, og demonstrere, at du håndterer dem.

Når kontrollerne fungerer, har du brug for feedback for at forbedre dem. Nyttige foranstaltninger kan omfatte:

Andelen af kritiske leverandører med opdaterede risikovurderinger og dokumenterede sikkerhedsforpligtelser.
Antallet og alvorligheden af hændelser, hvor den underliggende årsag involverede et opstrøms- eller nedstrømsforhold.
Den tid, det tager at blive underrettet om relevante leverandørhændelser og at kommunikere med berørte kunder.
Andelen af kunder, der ikke overholder centrale forpligtelser downstream, og hvor ofte der gives undtagelser.

Når der opstår hændelser, bør rodårsagsanalysen bevidst skelne mellem fejl i opstrømsfasen, interne problemer og svagheder i nedstrømsfasen. Denne sondring informerer om, hvor du skal skærpe forventningerne, forbedre din egen praksis eller justere kundeforpligtelser. Ved at føre disse indsigter tilbage til leverandørniveauer, kontraktskabeloner og playbooks, bliver din implementering af Annex A.5.21 ægte iterativ, ikke statisk.

En dedikeret ISMS-platform kan hjælpe dig med at forbinde leverandører, tjenester, kunder, risici og kontroller på ét sted, så en enkelt ændring eller hændelse kan spores på tværs af de relationer, den påvirker. Selv hvis du ikke er klar til at implementere en sådan platform med det samme, er det et pragmatisk skridt i retning af et mere integreret ISMS at designe dine processer, så de nødvendige data kan indsamles centralt senere.

Book en demo med ISMS.online i dag

ISMS.online kan hjælpe dig med at flytte Anneks A.5.21 fra spredte leverandørlister og kontraktklausuler til et enkelt, levende billede af din IKT-forsyningskæde, kontroller og dokumentation. Ved at erstatte regneark, e-mailspor og isolerede dokumenter med ét forbundet miljø kan du se opstrøms- og nedstrømsrelationer tydeligere, spore ansvar og besvare vanskelige spørgsmål fra kunder og revisorer med større sikkerhed.

Hvis du har mistanke om, at besvarelse af et komplekst kundespørgeskema eller en ISO 27001:2022-revision stadig vil udløse et kaos, er det et signal til at udforske en mere struktureret tilgang. At se dine upstream- og downstream-relationer kortlagt tydeligt, med ansvar og risici synlige med et enkelt blik, giver dig en mere tryg forretning for kunder, revisorer og ledelse.

Sådan afprøver du A.5.21 i én del af din forsyningskæde

En fokuseret pilotundersøgelse er den enkleste måde at se, hvordan bilag A.5.21 ser ud, når det er fuldt integreret i et ISMS. I stedet for at forsøge at modellere hele din verden på én gang, koncentrerer du dig om en lille, repræsentativ del af din forsyningskæde og tester, om strukturen og værktøjerne reelt reducerer indsats og usikkerhed.

Et praktisk pilotprojekt kunne starte med én kritisk upstream-platform og én højrisikokunde. Du kan importere disse relationer til ISMS.online, knytte dem til bilag A.5.19-A.5.22 og registrere de vigtigste artefakter: risikovurderinger af leverandører, modeller for delt ansvar, kundeforpligtelser og overvågningsdokumentation. Inden for dette begrænsede omfang kan du se, om platformen i væsentlig grad reducerer indsatsen, præciserer ejerskab og forbedrer din parathed til spørgsmål fra revisorer og kunder.

Ved at holde pilotprojektet lille, bevarer du kontrollen over omfanget og undgår at overvælde allerede travle teams. Samtidig giver du dig selv konkrete eksempler – en udfyldt risikoregisterpost, en dokumenteret leverandørlivscyklus, en matrix for delt ansvar – som du kan vise til kolleger og ledelse, når du diskuterer, hvordan man skalerer tilgangen.

Hvad skal man medbringe til en ISMS.online-samtale

Du får mest ud af en samtale om ISMS.online, hvis du kommer med et simpelt billede af din nuværende forsyningskæde og udfordringer. En lille smule forberedelse gør det nemmere at se, hvordan platformen kan understøtte din specifikke situation, og om den er et godt match for din organisation.

Nyttige input omfatter typisk:

En liste over dine vigtigste upstream ICT-leverandører og de tjenester, de understøtter.
En kort liste over kunder med stor indflydelse, især dem i regulerede sektorer.
Eventuelle eksisterende dokumenter, der beskriver fælles ansvar, kundeforpligtelser eller leverandørforventninger.
Eksempler på nylige leverandør- eller kunderelaterede hændelser, der var vanskelige at håndtere.

Med disse input kan ISMS.online-teamet gennemgå, hvordan jeres reelle relationer ville se ud på platformen, og hvordan bilag A.5.19-A.5.22 ville blive udtrykt i praksis. Målet er ikke at foreslå en generisk løsning, men at vise, ved hjælp af jeres egne eksempler, hvordan et sammenkædet ISMS kunne forenkle bilag A.5.21 og forbedre jeres forsyningskæde.

Hvis du genkender din egen organisation i disse scenarier og ønsker at teste en mere integreret tilgang, er ISMS.online klar til at udforske et fokuseret pilotprojekt med dig, hvor vi bruger dine rigtige leverandører og kunder til at se, om et forbundet ISMS er det næste skridt for din MSP.

Book en demo

Ofte stillede spørgsmål

Hvordan ændrer ISO 27001:2022 Anneks A.5.21 den måde, en MSP bør tænke på sin IKT-forsyningskæde?

Bilag A.5.21 forventer, at du driver din IKT-forsyningskæde som ét styret system fra cloudplatform til kunderesultat, ikke som et sæt af usammenhængende leverandører, værktøjer og kontrakter. For en MSP betyder det, at du har brug for et live, forsvarligt overblik over, hvordan upstream-udbydere, dine egne tjenester og downstream-kunder er knyttet sammen, og hvordan du styrer risici på tværs af denne kæde.

Hvad betyder "end-to-end IKT-forsyningskæde" egentlig for en MSP?

End-to-end betyder, at du kan starte med en enkelt tjeneste og spore:

Hvilken IKT-produkter og -tjenester du er afhængig af for at levere den.
Hvordan din egne platforme og processer sidde i midten.
Hvilken kunder eller kundesegmenter bliver påvirket, hvis noget går i stykker.

I stedet for "vi bruger leverandør X, og vi betjener kunde Y" antager bilag A.5.21, at du forstår og styrer hele stien: cloud/platforme → MSP-værktøjer og -processer → kundemiljøerHvis en kerneplatform fejler eller kompromitteres, bør du allerede vide, hvilke tjenester og lejere der er udsatte, og hvad du vil gøre ved det.

I praksis betyder det, at du kan:

Peg på et leverandørregister, der knytter IKT-leverandører til tjenester og risikoklasser.
Forklar i et letforståeligt sprog, hvem der gør hvad (dig, leverandøren, kunden) for hver servicetype.
Vis, at dette billede forbliver aktuelt, når tjenester, leverandører eller regler ændres.

Hvis du kan guide en revisor gennem den etage ved hjælp af almindelige optegnelser i stedet for en engangs "revisionspakke", behandler du bilag A.5.21 som en del af, hvordan du driver virksomheden, hvilket er præcis, hvad de leder efter.

Hvordan bygger bilag A.5.21 på de andre leverandørkontroller i bilag A.5 for en administreret tjenesteudbyder?

Bilag A.5.21 tager de generelle leverandørtemaer fra A.5.19, A.5.20 og A.5.22 og anvender dem specifikt på den IKT-stakk, der understøtter dine administrerede tjenester. Det handler mindre om at opfinde nye processer og mere om at forbinde leverandørudvælgelse, kontrakter, overvågning og forandring i én sammenhængende tilgang til IKT-produkter og -tjenester.

Hvordan passer leverandørkontrollerne i bilag A.5 sammen i en MSP's IKT-forsyningskæde?

Du kan tænke på de fire kontroller som ét flow:

A.5.19 – Informationssikkerhed i leverandørrelationer: Beslut, hvor sikkerhed er vigtig i dit leverandørlandskab, og hvordan du tager højde for det i dine valg.
A.5.20 – Håndtering af informationssikkerhed i leverandøraftaler: Omsæt disse forventninger til klare klausuler, tillæg og servicebeskrivelser.
A.5.21 – Håndtering af informationssikkerhed i IKT-forsyningskæden: Anvend den tankegang på det specifikke netværk af IKT-platforme, værktøjer og integrationer, der ligger under dine administrerede tjenester.
A.5.22 – Overvågning, gennemgang og ændringsstyring af leverandørtjenester: Hold leverandørens risiko og præstation under opsyn, og reager på hændelser og ændringer.

For en MSP omsættes dette normalt til tre synlige egenskaber:

A et sammenføjet register hvor IKT-leverandører er bundet til tjenester, risikovurderinger og kontraktlige forpligtelser.
A konsekvent mønster for hvordan I onboarder, overvåger og forlader IKT-leverandører, i stedet for engangsbeslutninger via e-mail.
A sporbart link fra disse aktiviteter til kundevendte løfter og dit interne risikoregister.

Brug af en platform som ISMS.online gør det nemmere at forbinde disse punkter, fordi du kan samle leverandører, kontrakter, risici og bilag A.5.19-A.5.22-kontroller ét sted. Det giver dig mulighed for at vise revisorer og kunder, at du styrer en IKT-forsyningskæde, ikke blot et arkivskab med aftaler.

Hvordan skal en MSP designe en upstream ICT-leverandørlivscyklus, der opfylder bilag A.5.21 uden at overbelaste teamet?

Den mest effektive måde at opfylde bilag A.5.21 upstream på er at definere en enkelt, gentagelig leverandørlivscyklus og derefter skalere dybden af kontrollerne efter risiko, ikke efter gætværk. Dit team skal kun lære ét mønster, og du forbeholder dig stor due diligence for de leverandører, der virkelig kan skade dig eller dine kunder.

Hvordan ser en praktisk, gentagelig IKT-leverandørlivscyklus ud for en MSP?

En simpel livscyklus med fire trin balancerer normalt indsats og sikkerhed:

Vælg: Klassificer leverandøren efter effekt, før du forpligter dig. En platform, der behandler kundedata eller sidder midt i din fjernstyringsstak, fortjener dybere kontrol end et lavværdiforsyningsselskab.
Ombord: Omdan dine forventninger til konkrete kontroller. Konfigurer adgang, logføring, ændringsmeddelelser, supportkanaler og exit-vilkår, før du går live.
betjene: Gennemgå ydeevne og risiko i en fornuftig takt. Planlæg mindst en årlig gennemgang for kritiske platforme samt kontroller efter sikkerhedsrådgivning, hændelser eller væsentlige serviceændringer.
Exit: Planlæg, hvordan du vil fjerne eller migrere data, tilbagekalde adgang, skifte afhængigheder og opdatere din egen dokumentation, når du forlader eller nedgraderer en leverandør.

Du behøver ikke komplekse værktøjer til at bevise, at du følger denne livscyklus. Et vedligeholdt leverandørregister, korte due diligence-notater, enkle onboarding-tjeklister og grundlæggende gennemgangsregistre giver allerede revisorer et klart signal om, at du behandler IKT-leverandører som en del af dit ISMS.

ISMS.online kan yderligere styrke dette ved at samle leverandørregisteret, livscyklusdokumentation og de tilknyttede bilag A.5.19-A.5.22-kontroller i ét miljø. Det hjælper dig med at holde processen let for dit team, samtidig med at det præsenterer et klart og ensartet mønster for kunder, revisorer og partnere.

Hvordan kan en MSP definere delte downstream-ansvar med kunder, så bilag A.5.21 er dækket uden at gøre hver kontrakt til en juridisk roman?

Nedstrøms er bilag A.5.21 opfyldt, når dine kunder i et klart sprog kan se, hvad du sikrer som standard, hvad de selv skal gøre, og hvordan du vil samarbejde, når noget ændrer sig eller går galt. Du behøver ikke skræddersyet juridisk tekst til hver aftale, men du har brug for et lille sæt af fælles ansvarsmønstre, som dine teams forstår og anvender konsekvent.

Hvordan ser en brugbar model for delt ansvar ud for fælles MSP-tjenester?

Et praktisk mønster er at standardisere modeller efter servicefamilie og holde strukturen identisk hver gang. For hver familie defineres fire blokke:

Serviceomfang: Hvad denne administrerede tjeneste dækker, og hvad den ikke dækker.
Dine ansvarsområder: For eksempel baselinekonfiguration, logning, backup, overvågning, håndtering af sårbarheder og koordinering af hændelser.
Kundens ansvar: For eksempel at holde slutpunkter understøttet, håndhæve multifaktor-godkendelse, administrere tiltrædende/afgående medarbejdere og informere dig om større ændringer.
Fælles ansvar: For eksempel adgangsgennemgange, godkendelse af ændringer med høj risiko eller kommunikation om hændelser.

Du kan derefter udtrykke disse modeller på flere måder:

Brief ansvarsmatricer i forslag, arbejdsomfang og onboarding-dokumenter.
Sikkerhedstillæg: der knytter sig til kontrakter uden at omskrive de fulde vilkår.
Interne runbooks: som dine teams bruger ved onboarding, drift og håndtering af hændelser.

Når en kunde har brug for en undtagelse, dokumenterer du denne afvigelse eksplicit i stedet for stille at strække modellen. Når disse mønstre og undtagelser findes i dit ISMS og afspejles i dit risikoregister, kan du vise, at downstream-risiko håndteres bevidst snarere end uformelt. Det er præcis, hvad bilag A.5.21 har til formål at teste.

ISMS.online giver dig et centralt sted til at gemme og genbruge disse modeller, linke dem til specifikke tjenester og kunder og holde kontraktformulering, interne playbooks og risikoposteringer på plads, efterhånden som din portefølje vokser.

Hvordan kan en MSP forvandle et komplekst netværk af leverandører, platforme og kunder til et tydeligt risikokort for IKT-forsyningskæden, der lever op til revisionerne i bilag A.5.21?

Den nemmeste måde at opbygge et meningsfuldt risikokort for forsyningskæden er at starte med, hvordan dine tjenester rent faktisk kører i dag, i stedet for at starte fra en statisk leverandørliste. Når du følger datastrømme og kontrolpunkter fra venstre mod højre, har de relationer, der er vigtigst for bilag A.5.21, en tendens til at afsløre sig selv.

Hvilke praktiske trin skaber et kort over IKT-forsyningskæden, som revisorer kan følge?

Du kan opbygge kortet i tre uafhængige trin, der forstærker hinanden:

Servicevisning: Angiv dine administrerede tjenester (f.eks. administreret Microsoft 365, administrerede slutpunkter, administreret backup, fælles administreret cloud), og noter hvilke upstream-platforme, værktøjer og integrationer hver enkelt er afhængig af.
Forholdsvisning: For hver tjeneste, angiv:

opstrøms IKT-leverandører og -platforme, der er essentielle.
nedstrøms kunder eller kundegrupper, der forbruger den pågældende tjeneste.

Risikoperspektiv: For hvert leverandør- eller kundesegment med stor indflydelse skal du registrere en separat risiko, der angiver:

Hvad der med rimelighed kan gå galt (f.eks. strømafbrydelse, databrud, ændring af licens).
Hvordan det ville påvirke dine tjenester og kunderesultater.
Hvilke kontroller, kontraktvilkår og driftspraksis reducerer sandsynligheden eller virkningen.

Mange MSP'er finder et simpelt diagram nyttigt, selvom du aldrig viser det eksternt: cloud/platforme → MSP-værktøjer og -processer → kundemiljøer, med farver eller ikoner, der viser den relative risiko. Billedet hjælper dig med at beslutte, hvor du skal investere indsatsen, og giver revisorer og kunder en nem måde at forstå dine afhængigheder på.

I ISMS.online kan du spejle denne struktur ved at forbinde tjenester, leverandører, kunder og risici i ét miljø. Det gør det meget nemmere at demonstrere, hvordan en ny platform eller en ny kunde tilføjes til kortet, hvordan den klassificeres, og hvordan relaterede risici og ansvar opdateres konsekvent.

Hvilke daglige optegnelser overbeviser ISO 27001-revisorer om, at en MSP reelt administrerer bilag A.5.21 i stedet for blot at nævne det i dokumentationen?

Revisorer er normalt mere interesserede i, om dine daglige optegnelser fortæller en sammenhængende historie, end i hvor imponerende dine værktøjer ser ud. For bilag A.5.21 ønsker de at se, at du forstår, hvor risikoen i IKT-forsyningskæden stammer fra, anvender en gentagelig behandling og kan dokumentere denne behandling uden at oprette en anden virksomhed dedikeret til revisionspapirer.

Hvilke normale artefakter opfylder normalt bilag A.5.21 for MSP'er uden at opbygge en parallel "revisionsindustri"?

I de fleste MSP'er er et kompakt sæt af poster tilstrækkeligt, hvis det er komplet og holdes opdateret:

A leverandørregister der viser en liste over IKT-leverandører, linker dem til tjenester, viser deres risikoklassificering og registrerer datoer for seneste gennemgang.
Kort due diligence-noter for leverandører med højere risiko, såsom henvisninger til certificeringer, spørgeskemabesvarelser eller præcise risikovurderinger.
Kontrakter eller sikkerhedstillæg: der fastsætter sikkerhedsforventninger, regler for underretning om hændelser, datahåndtering og betingelser for underdatabehandlere.
Overvågning og gennemgang af optegnelser: , såsom serviceanmeldelsessager, referater fra leverandørcheck-ins eller anmeldelser efter hændelsen, der viser, hvordan du reagerede.
Modeller for delt ansvar: og relaterede klausuler i kundekontrakter, plus virkelige eksempler på, hvordan du handler, når forpligtelser på begge sider ikke opfyldes.

I stedet for at bygge separate "revisionspakker" er det generelt mere effektivt at sørge for, at dine normale dokumenter – onboarding-tjeklister, ændringsregistreringer, runbooks, hændelses- og problemgennemgange – automatisk efterlader den dokumentation, en revisor vil bede om.

Hvis du centraliserer disse artefakter i ISMS.online og eksplicit forbinder dem til Annex A-kontroller og relevante risici, kan du hurtigt besvare revisionsspørgsmål og kundespørgeskemaer ved at filtrere og eksportere fra ét sted. Over tid reducerer det revisionsstress, forkorter salgscyklusser og hjælper dit team med at blive anerkendt for at drive en velstyret IKT-forsyningskæde i stedet for at skulle kæmpe hvert år for at samle den samme etage fra bunden.

Hvordan kan en MSP bruge ISMS.online til at integrere bilag A.5.21 i det normale arbejde i forsyningskæden i stedet for at behandle det som et engangs compliance-projekt?

Bilag A.5.21 bliver håndterbart, når det integreres i, hvordan du køber, leverer og evaluerer tjenester, ikke når det behandles som en selvstændig standard, der skal "sættes kryds ved". ISMS.online understøtter dette skift ved at give dig et enkelt miljø til at forbinde leverandører, tjenester, kunder, risici, kontroller og dokumentation, så hverdagens handlinger naturligt holder bilag A.5.21 i god stand.

Hvordan ser det ud, når bilag A.5.21 reelt operationaliseres i ISMS.online?

Et realistisk mønster for mange MSP'er ser sådan ud:

Du opretholder en live leverandørregister i ISMS.online, klassificere IKT-leverandører efter indvirkning og forbinde hver enkelt med de administrerede tjenester og bilag A.5.19-A.5.22-kontroller, den understøtter.
Du fanger due diligence, onboarding, overvågning og exitaktiviteter som normale arbejdspunkter eller opgaver, så den dokumentation, du har brug for til bilag A.5.21, opbygges automatisk, efterhånden som dit team arbejder med leverandører.
Du opbevarer og genbruger modeller for delt ansvar som struktureret indhold, der kortlægges til servicefamilier og kundegrupper, så kontraktsprog, runbooks og risikoposter forbliver på linje.
Du linker risici til både upstream-leverandører og downstream-kunder, så en ændring i en del af kæden justerer øjeblikkeligt dit syn på den samlede eksponering i forsyningskæden.

En lavrisiko-måde at starte på er at vælge én vigtig tjeneste, én kritisk upstream-platform og én repræsentativ kunde, modellere denne kæde end-to-end i ISMS.online og derefter køre en reel ændring eller hændelse gennem systemet. Hvis dine teams og din revisor finder det lettere at se afhængigheder, forklare forpligtelser og indsamle beviser fra det ene eksempel, vil du have et stærkt internt argument for at udvide den samme tilgang til flere af din IKT-forsyningskæde.

Med tiden hjælper denne arbejdsmetode din virksomhed med at blive set ikke blot som en virksomhed, der "holder systemerne kørende", men som en virksomhed, der driver en sporbar, velstyret IKT-forsyningskæde, der kan modstå kundespørgeskemaer og ISO 27001-revisioner med langt mindre forstyrrelse af dit daglige arbejde. Når du er klar til at vise den historie til en kunde eller revisor, giver ISMS.online dig alt, hvad du behøver, samlet ét sted, i stedet for at lade dig selv stykke det hele sammen under pres.

A.5.21 Håndtering af informationssikkerhed i IKT-forsyningskæden – MSP Upstream-downstream-kontrol