Hvordan ISO 27001 A.5.21 beskytter spilplatforme mod IKT-forsyningskæderisici

Hvorfor er jeres forsyningskæde til spil-IKT nu en del af jeres angrebsflade.

Din forsyningskæde inden for spil-IKT er en del af din angrebsflade, fordi spillere oplever dine leverandørers afbrydelser, fejl og brud som dine fejl. Enhver algoritme, SDK, cloudtjeneste og betalingsudbyder, der berører spillerdata, spillogik eller omsætning, opfører sig effektivt som en del af din egen platform, så svagheder i disse forbindelser hurtigt bliver til svagheder i din tjeneste.

Dine spil afhænger nu af et tæt netværk af spilmotorer, cloud-tjenester, SDK'er og betalingssystemer, der strækker sig langt ud over din egen kode og dine servere. En moderne stak kan læne sig op ad en kommerciel spilmotor, flere analyse- og annonce-SDK'er, udbydere af sociale logins, adskillige betalingsgateways, et indholdsleveringsnetværk, anti-cheat-tjenester, moderationsværktøjer og build- eller patch-pipelines, som du ikke selv driver. Hver af dem håndterer spillerdata, spillogik, kryptografiske hemmeligheder eller indtægtsstrømme, og derfor udvider hver enkelt din praktiske angrebsflade.

Hvis en partners opdateringsproces bliver kapret, et SDK introducerer en sårbarhed, eller en konfigurationsændring sendes uden varsel, mærker du effekten, som om hændelsen skete i dit eget miljø. Det kan betyde nedetid under en livebegivenhed, beskadigede progressionsdata, unfair konkurrence eller direkte økonomisk tab. Fra en revisors eller regulators perspektiv er du ansvarlig for at administrere disse afhængigheder som en del af dit informationssikkerhedsstyringssystem (ISMS) og ikke behandle dem som en andens problem.

Disse oplysninger er generelle og udgør ikke juridisk eller lovgivningsmæssig rådgivning. Du bør altid bekræfte præcise forpligtelser med kvalificerede fagfolk i de jurisdiktioner, hvor du opererer.

Hvordan skader tredjepartsfejl rent faktisk spilplatforme?

Tredjepartsfejl skader spilplatforme ved at bryde de oplevelser og forsikringer, som spillere, partnere og regulatorer er mest interesserede i. Nedbrud, datalækager eller unfair spil forårsaget af leverandører skader stadig dit omdømme, selvom din interne kode og infrastruktur forbliver sikker. Disse fejl bliver hurtigt dit problem i dit fællesskabs og dine kommercielle partneres øjne.

Et stort cloud-udfald kan sætte matchmaking eller login offline i timevis under en vigtig begivenhed. Et kompromitteret analyse-SDK kan stjæle legitimationsoplysninger, hvilket fører til kontoovertagelse, svindel og chargeback-tvister. En fejl i en ekstern anti-cheat-tjeneste kan afmærke legitime spillere og ødelægge tilliden til konkurrencedygtige platforme. I alle disse tilfælde afgør dine kontrakter, arkitektur og overvågning, om problemet er inddæmmet og forklarligt, eller om det udvikler sig til en fuldskala krise, der bringer certificering og kommende revisioner i fare.

Hvorfor er ISO 27001 specifikt optaget af dette inden for spil?

ISO 27001 fokuserer på IKT-forsyningskæderisiko i spil, fordi moderne spil altid er digitale tjenester, hvis pålidelighed og retfærdighed afhænger af et økosystem snarere end en enkelt applikation. Spilplatforme håndterer store mængder personoplysninger, betalinger og i nogle tilfælde regulerede spilaktiviteter, så regulatorer og store platforme i stigende grad behandler dem som kritiske tjenester.

Vejledning om informationssikkerhedsstyring understreger, at organisationer skal behandle eksterne teknologiudbydere som en del af deres eget risikolandskab. For spil betyder det, at bilag A.5.21 fuldt ud dækker cloudinfrastruktur, motorer, SDK'er, anti-cheat, identitet og betalinger, samt de pipelines, der bygger og distribuerer dine klienter og indhold. Hvis du kun kan tale om dine egne servere og ikke om de tjenester, der omgiver dem, vil din sikkerhedshistorie, risikoregister og erklæring om anvendelighed (SoA) virke ufuldstændige for revisorer.

Book en demo

Hvad kræver ISO 27001:2022 Annex A.5.21 egentlig af spiludbydere?

ISO 27001:2022 Anneks A.5.21 kræver, at du definerer og kører gentagelige processer for at identificere og håndtere informationssikkerhedsrisici, der stammer fra de IKT-produkter og -tjenester, du er afhængig af. I praksis betyder det at vide, hvilke leverandører der er vigtige, forstå, hvordan de kan påvirke dine spil og spillere, og at være i stand til at vise ensartede vurderings- og behandlingsbeslutninger i hele deres livscyklus.

Da hele bilag A-teksten er ophavsretligt beskyttet, beskriver offentlige resuméer A.5.21 på følgende måde: Du bør definere og implementere processer og procedurer til at håndtere informationssikkerhedsrisici forbundet med forsyningskæden for IKT-produkter og -tjenester. Standarden foreskriver ikke specifikke værktøjer eller fortæller dig, hvilke leverandører du skal vælge; den forventer, at du har en struktureret måde at forstå og kontrollere den risiko, disse leverandører introducerer, og at du forbinder denne struktur tilbage til dit ISMS og SoA.

For udbydere af spilteknologi betyder det spørgsmål som: hvilke tredjeparter kan påvirke spillerdata eller spilintegritet; hvilken minimumssikkerhed forventer du af dem; hvordan kontrollerer du dette før og efter kontraktunderskrivelse; og hvordan reagerer du, hvis noget går galt. Bilag A.5.21 står side om side med andre leverandørfokuserede kontroller vedrørende definition af krav og overvågning af leverandørtjenester og danner en lille klynge inden for bilag A's leverandørrelaterede kontroller, der styrer, hvordan du arbejder med ekstern teknologi som en del af dit bredere kontrolsæt i bilag A.

Hvordan passer A.5.21 ind i resten af jeres ISMS?

Inden for dit ISMS er A.5.21 den kontrol, der forbinder leverandørrisiko med dit primære risikostyrings- og styringsapparat. Den forbinder din leverandørliste, kontraktlige kontroller, tekniske arkitektur og hændelsesresponsplaner tilbage til det centrale system, der understøtter certificering og ledelsesgennemgang.

I en typisk implementering vil du:

Henvisning til A.5.21 i din SoA, hvor du angiver, hvordan den er anvendt og begrundet.
Registrer IKT-forsyningskæderisici i jeres centrale risikoregister i stedet for i separate regneark.
Vis, hvordan leverandørvurderinger, kontraktklausuler og overvågningsrapporter indgår i ledelsesgennemgange og interne revisioner.

Andre kontroller i bilag A håndterer derefter detaljerede foranstaltninger: leverandørrelationskontroller styrer forventninger og evalueringer; kontroller til sikker udvikling og ændringsstyring styrer, hvordan motorer og SDK'er integreres; logføring, overvågning og hændelsesstyring dækker detektion og reaktion. Når du har defineret din A.5.21-proces, bliver den hoveddøren, hvorigennem IKT-forsyningskæderisici kommer ind i det bredere kontrolsæt.

Hvad dækker "IKT-forsyningskæde" over i en spilkontekst?

I en spilkontekst dækker "IKT-forsyningskæde" ethvert eksternt produkt eller enhver ekstern tjeneste, der væsentligt kan ændre fortrolighed, integritet, tilgængelighed eller overholdelse af regler for dine spil og platform. Det er bredere end klassisk outsourcing og omfatter eksplicit software-, cloud- og build-pipeline-afhængigheder, der ligger bag dine udgivelsescyklusser og live-drift.

Dette omfatter normalt cloudinfrastruktur og administrerede databaser; spilmotorer og kernebiblioteker; identitets- og adgangstjenester; værktøjer til anti-cheat, svindeldetektering og risiko; analyse-, annonce- og attributions-SDK'er; indholdsleveringsnetværk og patch-systemer; backoffice-tjenester, der påvirker rettigheder eller betalinger; og supporttjenester såsom kundesupportplatforme, der kan nulstille konti. Open source-komponenter og build-pipelines er også en del af billedet, selvom du ikke betaler en leverandør direkte for dem, fordi de stadig former, hvor sikre og forudsigelige dine udgivelser og esports-sæsoner er.

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

Hvordan afgrænser du din IKT-forsyningskæde for spil i forhold til A.5.21 uden at fare vild?

Du afgrænser din IKT-forsyningskæde til spil i forhold til A.5.21 ved at beslutte, hvilke leverandører og komponenter der reelt berettiger til struktureret risikostyring, og hvilke der sikkert kan følge lettere kontroller. En praktisk måde at bevare kontrollen på er at opbygge en lagdelt opgørelse, der afspejler, hvor meget skade hver leverandør kan forårsage, hvis den fejler eller bliver kompromitteret, og derefter tilpasse dine ISO 27001-processer til disse lag.

I stedet for at forsøge at dække alle cloud-konti eller mindre værktøjer ligeligt, starter du med at identificere, hvilke udbydere der er afgørende for at holde spil kørende, beskytte spillernes aktiver og opfylde lovgivningsmæssige forventninger. Disse bliver dit vigtigste fokuspunkt i A.5.21, og de bør have en fremtrædende plads i dit risikoregister og din SoA-begrundelse. Alt andet kan evalueres ud fra klare tærskler, så dit teams tid bruges der, hvor det betyder mest, og du stadig kan forklare scoping-beslutninger til revisorer og større partnere.

Hvad er en fornuftig måde at opbygge et leverandørlager på?

En fornuftig måde at opbygge dit lager på er at starte med de systemer og oplevelser, som spillere og kunder værdsætter, og derefter arbejde sig baglæns til de underliggende leverandører. Dette er ofte mere effektivt end at starte udelukkende med fakturaer eller indkøbslister, fordi det afspejler, hvordan afbrydelser og hændelser rent faktisk optræder i live-driften.

Du kan for eksempel liste kernespiltjenester såsom login, matchmaking, progression, lagerbeholdning, betalinger, chat, ranglister og support. For hver tjeneste skal du identificere, hvilke eksterne parter der bidrager med teknologi eller driftskontrol, og derefter gruppere leverandører i kategorier som cloudhosting, motorer, SDK'er, betalinger, identitet, anti-cheat, indholdslevering og backoffice. Når du har set, hvilke leverandører der befinder sig på stierne mellem spillere, data og penge, kan du tildele kritikalitets- og følsomhedsscorer til hver enkelt og kontrollere, at de leverandører med den største indflydelse tydeligt er omfattet af A.5.21-området.

Hvordan afgør man, hvad der virkelig hører hjemme i A.5.21-området?

Du bestemmer, hvad der hører under omfanget, ved at kombinere teknisk påvirkning, forretningsmæssig påvirkning og regulatorisk eksponering i enkle kriterier, der kan anvendes konsekvent. Et par fokuserede spørgsmål hjælper dig med at vurdere, om en leverandør berettiger til fuld A.5.21-behandling eller en lempeligere tilgang.

Nyttige tests inkluderer:

Behandler eller påvirker denne leverandør personlige, økonomiske eller på anden måde regulerede spillerdata?
Kan en fejl eller et kompromis forhindre spillere i at logge ind, betale, komme videre eller konkurrere på en fair måde?
Forventer regulatorer, platformindehavere eller vigtige virksomhedskunder eksplicit, at du styrer dette forhold?
Ville det være vanskeligt at udskifte denne leverandør hurtigt uden driftsmæssige eller kommercielle forstyrrelser?

Hvis svaret er "ja" til et af disse, er leverandøren en stærk kandidat til at blive inkluderet i dine A.5.21-processer og risikoregister. Samtidig skal du være opmærksom på, at nogle interne værktøjer med lav risiko muligvis ikke fortjener den fulde vægt af dine forsyningskædeprocedurer. Anvendelse af væsentlighedsgrænser og dokumentation af scoping-beslutninger hjælper dig med at forblive proportional, undgå at lamme spilleveringen og forblive klar til forklaringer til certificering eller platformvurderinger.

Tydelige beslutninger om omfang og enkle niveauer gør forsyningskædesikkerhed til en proces, som teams rent faktisk kan køre.

Hvilke styrings- og livscyklusprocesser har I brug for omkring IKT-leverandører?

I har brug for styrings- og livscyklusprocesser, der gør leverandørrisiko fra ad hoc-samtaler til en gentagelig og reviderbar del af, hvordan I vælger, driver og afvikler IKT-tjenester. Det betyder at definere, hvem der kan godkende hvilke typer leverandører, på hvilken dokumentation, og hvordan beslutninger og undtagelser registreres, så I kan demonstrere kontrol under revisioner og platformgennemgange.

Governance for A.5.21 kræver ikke et nyt udvalg for hver leverandør, men det kræver klarhed. Uden denne klarhed tilføjer udviklere SDK'er under tidspres, indkøb forhandler kontrakter udelukkende baseret på omkostninger, og sikkerhed ser kun leverandører, når noget allerede er gået i stykker. For en spilorganisation med hyppige udgivelser og livebegivenheder dukker det ofte op på de værst tænkelige tidspunkter. A.5.21 skubber dig hen imod koordineret livscyklusstyring, der passer til eksisterende leveringsrytmer, og én måde at opnå det på er at definere en simpel, delt livscyklus, som alle vigtige leverandører gennemgår.

Hvordan ser en A.5.21-tilpasset leverandørlivscyklus ud?

En A.5.21-tilpasset livscyklus følger normalt fem faser, som du kan beskrive, tildele og dokumentere. Hver fase bør have klare aktiviteter, ejere og output, der forbinder sig tilbage til dit ISMS.

Trin 1 – Udvælgelse

Definer kategorispecifikke sikkerheds- og robusthedskrav, og screen kandidatleverandører i forhold til dem, før den tekniske integration påbegyndes.

Trin 2 – Onboarding

Udfør en struktureret risikovurdering, aftal kontraktlige kontroller, tildel internt ejerskab og registrer resultater i jeres ISMS og SoA.

Trin 3 – Betjening

Overvåg ydeevne, hændelser og overholdelse af aftalte forpligtelser, og hold leverandørregistre opdaterede, efterhånden som funktioner og sæsoner ændrer sig.

Trin 4 – Ændring

Genvurder risikoen, når leverandøren eller din brug af dem ændrer sig væsentligt, f.eks. håndtering af nye data eller højere transaktionsvolumener.

Trin 5 – Afslut

Planlæg returnering eller sletning af data, nøgleoverdragelse og operationel overgang for at undgå ukontrolleret eksponering eller nedetid, når kontrakter udløber.

Ved at indramme din livscyklus på denne måde kan du vise revisorer, platforme og virksomhedskunder, at leverandørrisiko styres som en kontinuerlig proces, ikke en engangsforeteelse ved kontraktunderskrivelse.

Hvordan integrerer man disse processer uden at lamme spillets levering?

Du integrerer dem ved at afstemme kontroller med beslutningspunkter, der allerede findes: godkendelser af finansiering, grønt lys for funktioner, større indholdsopdateringer, esports-sæsoner og kontraktfornyelser. Målet er at bringe A.5.21-spørgsmål ind i øjeblikke, hvor hold allerede sætter farten ned for at træffe valg, i stedet for at indsætte nye gates overalt og forsinke udgivelsescyklusser.

Hvis for eksempel en ny anti-cheat- eller betalingsintegration er afgørende for en funktion, bør beslutningen om at fortsætte omfatte en bekræftelse af, at grundlæggende leverandørkontroller er udført, og at nøgleklausuler er aftalt. Hvis en eksisterende leverandør opgraderes til at håndtere nye typer spillerdata eller højere transaktionsvolumener, bør denne ændring udløse en kort revurdering af risikoen og om nødvendigt justeringer af overvågning eller kontrakter. Governance bliver et tyndt, men ensartet lag over eksisterende arbejdsgange, ikke en blokering.

En platform som ISMS.online kan hjælpe ved at tilbyde et enkelt miljø, hvor leverandørregistre, A.5.21-tilpassede risikovurderinger, godkendelser og overvågningslogfiler findes sideløbende med dine ISO 27001-kontroller. Det reducerer fristelsen til at oprette separate, kortlivede regneark for hvert nyt forhold og gør det lettere at demonstrere livscyklusdisciplin under revisioner.

Når grundlæggende styring og livscyklus er på plads, kan du se mere konkret på de specifikke IKT-forsyningskædetrusler, der er mest betydningsfulde for dine spil.

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

Book din demo

Hvilke trusler fra IKT-forsyningskæden rammer spil hårdest, og hvordan hjælper A.5.21?

De trusler inden for IKT-forsyningskæden, der rammer spil hårdest, er dem, der ødelægger tilgængelighed, retfærdighed, betalingsintegritet eller spillernes tillid på grund af svagheder, du ikke fuldt ud kontrollerer. Med en defineret A.5.21-proces på plads kan du fokusere denne styring på de leverandører og scenarier, der udgør de største risici for dine spillere og indtægter.

Almindelige eksempler inkluderer kontoovertagelse gennem kompromitterede partnere, malware indlejret i SDK'er, manipulation af ranglister eller matchmaking via leverandøradgang og falske eller manipulerede betalingsintegrationer. Hver af disse udnytter kløften mellem, hvor meget tillid du giver en leverandør, og hvor meget sikkerhed du har for deres adfærd og sikkerhed. For en spiludbyder resulterer det ofte i forstyrrede begivenheder, giftige reaktioner fra fællesskabet og akavede samtaler om, hvorvidt dine kontroller virkelig er effektive.

Hvordan relaterer disse trusler sig til praktiske kontroller?

Du kan kortlægge trusler mod praktiske kontroller ved at parre hvert scenarie med specifikke forebyggende, detektive og kontraktlige foranstaltninger og derefter registrere denne kortlægning i dit ISMS. Tabellen nedenfor illustrerer en simpel tilgang til fire fremtrædende trusselstyper.

Før tabellen er det værd at bemærke, at A.5.21 ikke foreskriver præcise kontrolsæt for hvert scenarie. I stedet forventes det, at du viser, at du har gennemtænkt, hvordan leverandører kan blive misbrugt, og valgt rimelige kontrolforanstaltninger for at reducere disse risici til et acceptabelt niveau i dit miljø.

Trusselsscenarie	Eksempel på indflydelse i spil	Nøglekontroller tilpasset A.5.21
Kontoovertagelse via partnere	Spillere mister adgang og værdi; svindel og support stiger	Stærke krav til identitetsudbydere, overvågning af delte sessioner, klare opgaver inden for hændelse
Malware i SDK'er eller motorer	Klienter exfiltrerer data eller kører skjult kode	Leverandørgodkendelse, kodeintegritetstjek, sandboxing, hurtige kill-switch-ruter
Riggede ranglister eller matchmaking	Konkurrenceprægede scener og spiløkonomier mister troværdighed	Funktionsadskillelse for databehandlingspartnere, anti-svindel-styring, revisionsspor
Falske eller kompromitterede betalingsstrømme	Stjålne kortdata, fejldirigeret omsætning, tilbageførsler	Certificerede betalingsudbydere, sikkert integrationsmønster, svindelovervågning, kontraktlige sikkerhedsforanstaltninger

Disse kontrolsæt er ofte afhængige af andre Annex A-kontroller til adgangskontrol, overvågning, sikker udvikling og hændelsesstyring, men din A.5.21-proces giver den styringsramme, der siger: "Vi tænkte over denne afhængighed; her er hvorfor vi stoler på den, og hvordan vi fortsætter med at overvåge den." Hvert scenarie kan omdannes til et kort, genanvendeligt kontrolmønster i dit ISMS, der forbinder synlige spillerresultater tilbage til klare, kontrollerbare målinger.

Findes der andre ISO 27001-kontroller, der understøtter A.5.21 i spil?

Ja. Selvom A.5.21 fokuserer på styring af IKT-forsyningskæden, er adskillige andre kontroller i bilag A typisk knyttet til de samme risici i spilmiljøer, og der bør henvises til dem i jeres SoA og interne procedurer.

Leverandørrelationskontroller kræver, at du definerer sikkerhedsforventninger og gennemgår leverandørernes ydeevne. Sikker udvikling, teknisk hærdning og konfigurationsstyring hjælper dig med at integrere motorer, SDK'er og tjenester sikkert. Logførings- og overvågningskontroller understøtter detektion af usædvanlig adfærd knyttet til leverandører. Hændelsesstyring og forretningskontinuitetskontroller sikrer, at du kan reagere og genoprette, når en tredjepart fejler, herunder omkring vigtige begivenheder og sæsonbestemte spidsbelastninger.

Samlet set danner disse kontroller et netværk: A.5.21 fortæller dig, at du skal være opmærksom på IKT-forsyningskæden som helhed; andre bilag A-kontroller giver dig værktøjerne til at gøre noget ved specifikke svagheder. Når du dokumenterer disse forbindelser tydeligt, gør du det lettere for revisorer, platformpartnere og virksomhedskunder at følge, hvordan leverandørrisikoen gennemsyrer dit ISMS, og hvorfor din tilgang er forholdsmæssig.

Hvordan kan man designe en praktisk A.5.21-risikovurderingsproces for spilleverandører?

Du kan designe en praktisk A.5.21 risikovurderingsproces ved at følge en kort, gentagelig sekvens: opbyg en opgørelse, klassificer leverandører efter kritisk karakter, identificer relevante trusler, score risiko, vælg behandlinger og registrer resultater i dit ISMS. Nøglen er at holde metoden enkel nok til, at teams vil bruge den, men struktureret nok til, at revisorer og partnere kan se, at du er konsekvent, og at nøgleleverandører virkelig behandles mere omhyggeligt end mindre værktøjer.

For spiludbydere skal denne proces kunne håndtere hurtige forandringer. Nye leverandører, SDK'er og tjenester dukker konstant op; din proces bør kunne håndtere dette tempo uden at genopfinde sig selv hver gang. Et godt tegn er, når udviklere eller producenter kan besvare de centrale risikospørgsmål med minimal støtte fra specialister, fordi kriterierne og skabelonerne er klare, og når du kan producere et lille sæt repræsentative vurderinger som dokumentation for ISO 27001-revisioner og SoA-gennemgange.

Hvordan ser en trinvis A.5.21-vurdering ud?

En trinvis A.5.21-vurdering kan opdeles i en håndfuld klare trin, der stemmer overens med din leverandørlivcyklus og risikoappetit.

Trin 1 – Bekræft omfang og kritiskhed

Anvend dine scopingkriterier til at afgøre, om leverandøren er omfattet af A.5.21-området, og vurder derefter kritiskhed baseret på de tjenester og data, den berører.

Trin 2 – Identificer trusler og fejltilstande

Angiv plausible måder, hvorpå fortrolighed, integritet, tilgængelighed eller compliance kan blive skadet, såsom afbrydelser, datalækager, misbrug af privilegier, snyd eller svindel.

Trin 3 – Evaluer risiko og eksisterende kontroller

Score sandsynlighed og effekt ved hjælp af din organisations standardskalaer, og kortlæg nuværende kontroller såsom certificeringer, tekniske sikkerhedsforanstaltninger og intern overvågning.

Trin 4 – Bestem behandlinger og ejere

Hvor den resterende risiko er for høj, skal du definere behandlingstiltag såsom stærkere integrationsmønstre, strammere kontraktvilkår, forbedret overvågning eller leverandørskifte, og derefter tildele ejere og gennemgå datoer.

Når disse trin er dokumenteret og knyttet til specifikke leverandører, kan du vise, at beslutninger om søgemotorer, cloudplatforme eller betalingsudbydere er baseret på en ensartet metode snarere end uformelle indtryk.

Hvordan holder man vurderingerne lette, men troværdige?

Du holder vurderingerne lette, men troværdige, ved at opdele leverandører i niveauer og tilpasse vurderingsdybden i overensstemmelse hermed, samtidig med at du genbruger skabeloner og skalaer, så lignende situationer giver lignende resultater. Leverandører med høj risiko kan retfærdiggøre detaljerede spørgeskemaer, gennemgang af uafhængige revisionsrapporter og fælles testplaner, hvorimod værktøjer med lav risiko muligvis kun behøver en kort tjekliste og en hurtig bekræftelse på, at de ikke håndterer følsomme data.

For at beskytte troværdigheden bør du:

Brug standardvurderingsskabeloner og scoremodeller på tværs af teams.
Sørg for, at resultaterne indgår direkte i kontrakter, onboardingopgaver, overvågningsplaner og hændelsesplaner.
Gennemgå højrisikovurderinger regelmæssigt, ikke kun ved kontraktfornyelse.

En platform som ISMS.online kan centralisere disse vurderinger, forbinde dem til kontroller og leverandører og afdække, hvor evalueringer er forsinkede. Det gør det nemmere at opretholde processen over tid, selv når teams er under pres fra udgivelsescyklusser, live-events eller nye platformkrav.

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

Book din demo

Hvordan omdanner man A.5.21 til konkrete kontrakter, SLA'er og operationelle kontroller?

Du omdanner A.5.21 til konkrete kontrakter, serviceniveauer og operationelle kontroller ved at integrere dine risikobaserede forventninger i den juridiske og tekniske struktur i hvert forhold. Standarden forventer, at du ikke blot forstår risiciene, men også handler på dem på måder, som leverandører kan se, acceptere og måles i forhold til, så du kan fremlægge klar dokumentation for disse forventninger under ISO 27001-revisioner og kundedue diligence.

Dette involverer typisk udvikling af standardsikkerhedsplaner for forskellige leverandørkategorier, definition af tidsfrister for hændelser, specifikation af revisions- og rapporteringsrettigheder og beskrivelse af minimumskravene til tekniske sikkerhedsforanstaltninger. Det involverer også en aftale om, hvordan data skal håndteres, hvor de skal opbevares, hvor længe de skal opbevares, og hvordan de skal returneres eller slettes, når forholdet ophører. Eksemplerne i dette afsnit er illustrative; du bør altid søge din egen juridiske rådgivning, når du udarbejder eller forhandler specifik kontrakttekst.

Hvad skal man kigge efter i kontrakter med spilleverandører?

I kontrakter med spilleverandører bør du sørge for klare formuleringer om sikkerhedsansvar, servicekontinuitet, håndtering af hændelser og datastyring, skræddersyet til leverandørens risikoniveau. Jo mere en udbyder berører spillerdata, spilbalance eller omsætning, desto mere eksplicitte og krævende bør dine klausuler være.

For kritiske udbydere såsom søgemaskiner, anti-snydetjenester, cloudplatforme og betalingsgateways kan du forvente forpligtelser til at opretholde anerkendte sikkerhedscertificeringer, underrette dig om relevante hændelser inden for bestemte tidsrammer, deltage i fælles undersøgelser, hvor det er relevant, og støtte rimelige sikkerhedsforanstaltninger. Du kan også kræve begrænsninger på brugen af underleverandører, klare regler for telemetri og data om spilleradfærd samt robuste bestemmelser for returnering eller sletning af data ved kontraktens udløb.

For leverandører med lavere risiko kan du i højere grad benytte standardvilkår og branchetypiske sikkerhedsbestemmelser, forudsat at de stadig er i overensstemmelse med dine politikker og risikovillighed. Det vigtige er, at dine kontrakter afspejler resultaterne af dine A.5.21-risikovurderinger, så du kan vise en klar linje fra risikoidentifikation til kontraktuel kontrol.

Hvordan hænger disse forpligtelser sammen med ISO 27001-dokumentation?

Disse forpligtelser er knyttet tilbage til ISO 27001-dokumentation ved at give dig konkrete artefakter, som du kan vise revisorer, platforme og virksomhedskunder. Din A.5.21-proces er lettere at demonstrere, når du kan pege på specifikke klausuler, aftalte serviceniveauer og optegnelser over hændelsesrapporter eller sikkerhedsgennemgange, der svarer til højrisikoleverandører i din beholdning.

Revisionsklar dokumentation omfatter ofte:

Standardkontraktskabeloner og sikkerhedsplaner for vigtige leverandørkategorier.
Uddrag fra underskrevne aftaler for kritiske leverandører, der viser sikkerheds- og hændelsesmeddelelsesklausuler.
Ændringslogge, der viser, hvornår sikkerhedsrelevante vilkår blev opdateret eller gennemgået.
Registreringer af periodiske gennemgange, servicerapporter eller fælles hændelsesøvelser.

Når disse dokumenter er knyttet til dine risikovurderinger og leverandørlager, danner de en klar fortælling: Du har genkendt en risiko, fastsat forventninger, modtaget bekræftelse og justeret efter behov. En ISMS-centreret platform som ISMS.online kan hjælpe ved at gemme disse artefakter sammen med de relevante kontroller og risici og ved at tilbyde enkle dashboards til at besvare spørgsmål som "hvilke højrisikoleverandører mangler en aftalt hændelsesmeddelelsesklausul" eller "hvilke gennemgange er forsinkede", uden at du behøver at lede gennem spredte mapper.

Book en demo med ISMS.online i dag

ISMS.online hjælper dig med at forvandle ISO 27001 A.5.21 fra et bekymrende krav til en praktisk, daglig måde at håndtere IKT-forsyningskæderisici på tværs af din spilstak. Ved at opbevare leverandørlagre, risikovurderinger, kontrakter, kontroller og overvågning i ét miljø kan du give en klar, evidensbaseret historie om de motorer, SDK'er, cloudplatforme og betalingstjenester, der nu definerer din angrebsflade.

Hvis du forbereder dig på ISO 27001:2022-certificering, udvider et eksisterende ISMS til at dække et voksende økosystem af leverandører eller besvarer vanskeligere spørgsmål fra platforme og virksomhedskunder, kan en kort demonstration gøre vejen meget klarere. Du kan se, hvordan leverandørniveauinddeling, vurderinger, godkendelser og klausulbiblioteker fungerer i praksis, og hvordan de linker tilbage til din SoA og centrale risikoregister uden at afspore udgivelsesplaner eller live-drift.

Hvad vil du se i en demo?

I en demo ser du, hvordan leverandørstyring, risikovurdering og Annex A-kontroller samles i et enkelt, spilbevidst ISMS. Fokus er på at vise dig praktiske arbejdsgange snarere end abstrakte funktioner, så du kan forestille dig, hvordan dine egne teams ville bruge dem under virkelige projekter og arrangementer.

En typisk session gennemgår opsætning af en leverandøropgørelse, opdeling af leverandører efter effekt, udførelse af en A.5.21-tilpasset vurdering og sammenkædning af resultater med kontrakter, kontroller og revisioner. Du ser også, hvordan anmeldelser, hændelsesregistreringer og ledelsesrapporter indsamles, så du kan besvare spørgsmål fra revisorer, platforme og virksomhedskunder uden at skulle lede på tværs af værktøjer eller regneark.

Hvordan skal forskellige teams forberede sig til et pilotprojekt?

Du får mest værdi ud af et pilotprojekt, når hver nøgleperson bidrager med ét reelt problem, de ønsker at løse, i stedet for blot en teoretisk ønskeliste. Det kunne være et blokeret ISO 27001-projekt, et skrøbeligt leverandørregneark eller en bølge af nye platformspørgeskemaer, du skal besvare med selvtillid.

Fast-track-brugere, der fokuserer på at opnå ISO 27001 for første gang, kan forberede sig ved at liste en håndfuld kritiske leverandører og de aftaler eller platformrelationer, der afhænger af certificering. Teams, der styrker et eksisterende ISMS, kan inddrage aktuelle risikoregistre, SoA-poster og kontraktskabeloner og derefter teste, hvor godt disse passer ind i en samlet, forsyningskædebevidst model. I begge tilfælde hjælper det at starte med et lille, repræsentativt sæt af cloud-, betalings- og anti-cheat-udbydere dig med hurtigt at bevise tilgangen og generere artefakter, som du kan genbruge i kommende revisioner, sikkerhedsspørgeskemaer og platformgennemgange.

Du kan derefter udvide til andre dele af din gaming-stak, i sikker forvisning om, at din tilgang til IKT-forsyningskædesikkerhed er forholdsmæssig, forklarlig og i overensstemmelse med ISO 27001 A.5.21 og relaterede bilag A-kontroller. Når du er klar til at bevæge dig væk fra skrøbelige regneark og ad hoc-processer, er booking af en demo med ISMS.online et ligetil næste skridt mod en forsyningskædesikkerhedsmodel, som dine leveringsteams, ledelse og revisorer alle kan leve med.

Book en demo

Ofte stillede spørgsmål

Hvordan ændrer ISO 27001 A.5.21 rent faktisk de daglige beslutninger for en spiludbyder?

ISO 27001 A.5.21 ændrer dine daglige beslutninger ved at tvinge dig til at behandle kritiske IKT-leverandører som en del af dit live-spilmiljø, ikke som eksterne sorte bokse. Systemer, SDK'er, cloud, betalinger, anti-cheat, CDN'er, identitet, analyser og build-pipelines bevæger sig alle fra "indkøbsvalg" til "sikkerhedsrelevante aktiver" i dit ISMS.

I praksis betyder det, at du holder op med at godkende leverandører udelukkende på funktioner og pris, og begynder at stille tre disciplinerede spørgsmål hver gang:

Hvad er den reelle indflydelse af denne IKT-leverandør på spillere og indtægter?

Du vurderer, om tjenesten kan:

Stop spillere fra at oprette forbindelse eller forblive forbundet.
Ødelæg eller miste progression eller genstande.
Forvride konkurrencemæssig integritet eller beskyttelse mod svig.
Break platform, gambling eller privatlivsforpligtelser.
Bloker, forsink eller fejlsend betalinger og refusioner.

Hvis nogen af disse gælder, er leverandøren omfattet af A.5.21-anvendelsesområdet og skal være synlig i jeres ISMS, risikoregister og erklæring om anvendelighed.

Hvordan beviser man, at IKT-risici styres aktivt?

Du går fra ad hoc-spørgeskemaer og e-mail-spor til et gentageligt mønster:

En tydelig leverandørhistorik med niveauinddeling og ejerskab.
En kort, struktureret risikovurdering knyttet til dit kernerisikoregister.
Kortlagte bilag A-kontroller (inklusive A.5.21, men også A.5.19, A.5.23, A.8.8 og A.8.20-A.8.22 hvor det er relevant).
Behandlingsbeslutninger, handlinger og evalueringsdatoer, der rent faktisk finder sted.

Når en cloud-region fejler, eller en SDK-opdatering ikke fungerer korrekt, kan du vise præcis, hvad du antog, hvordan du afbødede det, og hvordan du forbedrer dig, i stedet for at rekonstruere beslutninger fra chatlogfiler.

Hvordan viser dette sig i et integreret ISMS- eller Annex L-system?

I et integreret styringssystem, der er tilpasset Annex L, understøtter A.5.21 en fælles leverandørstyringsproces for sikkerhed, privatliv, kontinuitet og snart også AI-styring. I stedet for fire separate leverandørlister og risikoarbejdsgange kører du én A.5.21-forankret arbejdsgang, der understøtter ISO 27001-, ISO 27701-, ISO 22301- og NIS 2 / DORA-lignende forpligtelser.

ISMS.online gør dette konkret ved at samle leverandørregistreringer, risikovurderinger, kontrolkortlægninger og hændelseslinks ét sted. Det giver revisorer, licensgivere og platformspartnere mulighed for at se, at risiko i IKT-forsyningskæden er en del af, hvordan du driver forretningen uge for uge, og ikke noget, du kun tænker på, når et certifikat skal fornyes.

Hvis du vil tjekke din egen situation, så vælg én udbyder af søgemaskiner eller anti-snydemidler og se, om du kan finde en lige linje fra forretningsmæssig påvirkning → risikovurdering → kontroller → kontrakt → gennemgangsnotater. Hvis ikke, har du et klart udgangspunkt for at stramme A.5.21.

Hvordan skal et spilstudie afgøre, hvilke IKT-leverandører der virkelig er omfattet af A.5.21-området?

Du bestemmer omfanget af A.5.21 ved at starte med de rejser, som spillerne er interesserede i, og arbejde dig baglæns til de leverandører, der kan være afgørende for disse øjeblikke. Spørgsmålet er ikke "hvem sender os en faktura?", men "hvem kan væsentligt skade tilliden, hvis de fejler eller opfører sig dårligt?"

Hvordan kortlægger man leverandører ud fra spillernes rejser?

Gå gennem et par konkrete strømme:

Kontooprettelse, login og rettigheder.
Matchmaking og sessionstyring.
Progression og vareopgørelser.
Konkurrencepræget og rangeret spil.
Betalinger, refusioner og tilbageførsler.
Livebegivenheder og økonomier i spillet.
Kundesupport og sikkerhedsrapportering.

For hvert flow skal du angive alle eksterne produkter eller tjenester, der:

Styrer eller gemmer spillets status eller progression.
Behandler eller dirigerer penge eller værdifulde virtuelle genstande.
Træffer håndhævelsesbeslutninger (anti-svindel, bedrageri, moderering).
Håndterer regulerede data (betalingskort, personoplysninger, mindreårige).
Adgang til porte (identitet, licensering, platformcompliance).

Det er dine kandidat A.5.21-leverandørerVærktøjer, der ligger helt uden for de kritiske stier (for eksempel et marketingplugin med lav risiko), kan ofte håndteres med lettere kontroller.

Hvordan kan en simpel tredelt model holde omfanget under kontrol?

De fleste studier får gode resultater med en lean tre-lags model:

Hvordan kan leverandørniveauer på niveau 1-3 fungere i et ISMS for spil?

En klar tredelt model hjælper dig med at vise proportionalitet uden at bruge den samme indsats på hvert SaaS-abonnement.

Niveau 1 – Spiller- og indtægtskritiske IKT-leverandører:

Alt, der kan stoppe tjenesten, korrumpere tilstanden, forvrænge retfærdigheden, lække regulerede data eller bryde platform-/spil-/privatlivsforpligtelser, hører hjemme her.

Niveau 2 – Vigtige, men ikke-kritiske leverandører:

Tjenester, der understøtter drift, analyse eller kommunikation, men som ikke direkte kontrollerer spillets tilstand eller regulerede data.

Niveau 3 – Forsyningsvirksomheder med lav påvirkning:

Værktøjer, der kan svigte uden mærkbar indflydelse på spillerne og med minimal kontraktmæssig eller lovgivningsmæssig eksponering.

Derefter anvender du hele A.5.21-disciplinen på niveau 1 (formelle risikovurderinger, stærkere kontrakter, strammere overvågning), lettere, men stadig strukturerede kontroller på niveau 2 og grundlæggende onboarding-kontroller for niveau 3. I ISMS.online kan du afspejle dette med felter for niveau, ejer, tilknyttede risici og datoer for sidste gennemgang, så når nogen spørger "hvorfor behandles denne udbyder anderledes?", kan du vise, at det var en bevidst, dokumenteret beslutning snarere end et gæt truffet under tidspres.

Hvordan kan vi vurdere leverandører af cloud-, betalings- og SDK-løsninger uden at skabe en administrativ byrde?

Du holder IKT-forsyningskædevurderingen håndterbar ved at standardisere én arbejdsgang og genbruge den på tværs af cloud, betalinger og SDK'er, i stedet for at opfinde et nyt regneark hver gang. Målet er ensartet dybde, minimal friktion.

Hvordan ser et enkelt vurderingsmønster ud?

Et praktisk mønster for hver IKT-leverandør er:

Bekræft, at de er inden for A.5.21-området, og tildel et niveau.
Angiv 3-7 realistiske fejltilstande, der er vigtige for aktører, regulatorer eller indtægter.
Registrer, hvad du og leverandøren allerede gør i disse scenarier.
Aftal eventuelle ekstra behandlinger (tekniske, kontraktlige, overvågningsmæssige) med ejerne og datoer.
Forbind alt med dit ISMS-risikoregister og relevante bilag A-kontroller.

Derefter justerer du spørgsmålene og eksemplerne efter kategori:

Sky: regioner og tilgængelighedszoner, skalering og kapacitet, sikkerhedskopiering og gendannelse, dataopbevaring, lejerisolering, hændelsesrapportering.
Betalinger: svindel og tilbageførsler, PCI DSS-tilpasning, timing af afvikling, håndtering af tvister, platformspecifikke regler (f.eks. appbutikker, spil).
SDK'er: kodeintegritet, indsamlede data, tilladelser, opdateringsmekanismer, rollback-muligheder, kill-switches, virkning af forkert konfiguration.

Metoden forbliver den samme; kun detaljerne ændrer sig.

Hvad tæller som "lige nok" dokumentation for leverandører med stor indflydelse?

For Tier 1-leverandører er "lige tilstrækkelig" dokumentation kort, men sporbar:

En dateret risikovurdering, der opsummerer, hvorfor leverandøren er kritisk, og hvilke scenarier der er vigtige.
Links til de tilsvarende ISMS-risikoposter og bilag A-kontroller (A.5.21 plus andre, der er relevante).
En oversigt over revisionsaktiviteter: certifikater, testrapporter, strukturerede spørgeskemaer, hvis du bruger dem.
En behandlingsbeslutning og klare handlinger med ejere og evalueringsdatoer.

ISMS.online giver dig mulighed for at pakke disse elementer i en enkelt visning pr. leverandør, så når der er en hændelse, ekstern revision eller et platformspørgeskema, opdaterer du en levende registrering i stedet for at genopbygge din logik fra bunden. Hvis din nuværende tilgang ikke kan producere et resumé på én side pr. Tier 1-leverandør efter behov, er det et stærkt signal om, at A.5.21-arbejdet foregår i fragmenter snarere end som en administreret proces.

Hvilke fejl i motorer, SDK'er og anti-cheat-systemer bør vores kontroller forudse først?

De fejl, der betyder noget, er dem, som spillerne oplever, og som tilsynsmyndighederne bekymrer sig om: uspillelige sessioner, urimelige resultater, manglende værdi eller forkert håndterede data. Tekniske grundårsager er vigtige internt, men kontroller til A.5.21 er lettere at designe, hvis man starter med de synlige effekter.

Hvad er realistiske fejlscenarier for leverandører af IKT til spil?

Tænk i kategorier, som spillere og partnere ville genkende:

Motorer og SDK'er:
En opdatering, der introducerer en sikkerhedsfejl eller et lydløst nedbrud.
En ændring i dataindsamlingsadfærd, der overskrider din offentliggjorte privatlivspolitik.
En ødelagt opdateringssti, der gør rollback eller hotfixes langsomme eller usikre.

Anti-svindel og bedrageri:
Regler, der pludselig udelukker en bølge af legitime spillere.
Opdagelse af blinde vinkler, der tillader koordineret snyd eller svindel at trives ubemærket.
Telemetrihuller, der gør undersøgelser langsomme eller ufyldestgørende.

Byg pipelines og værktøj:
Kompromitteret byggeinfrastruktur, der tillader manipulation af aktiver eller kode i live builds.
Fejl ved signering eller implementering, der afbryder opdateringer på tværs af en platform eller i en region.

Licensering, identitet og berettigelse:
Godkendelses- eller berettigelsesafbrydelser, der forhindrer spillere i at starte eller deltage i sessioner.
Forkert anvendt tilbagekaldelse eller områdeindstillinger, der ligner målrettede låsninger.

Hvert scenarie giver dig et anker til designkontroller, der blander styring og teknik.

Hvordan forvandler man disse scenarier til kontroller, der overbeviser revisorer og platformspartnere?

For hver scenariefamilie, parres:

Forvaltning: kriterier for leverandørudvælgelse, minimumsforventninger til sikker udvikling og testning, klausuler om ret til information, krav til underretning om hændelser, gennemgangskades.
Teknisk: sandbox-integrationer og adgang med mindst rettigheder, kodesignering og integritetstjek, kontrollerede udrulnings- og tilbagerulningsmekanismer, telemetri justeret til de specifikke risici, sikkerhedsporte i din CI/CD.

Derefter kortlægger du disse kontroller i dit ISMS og forbinder dem med A.5.21 og andre relevante Annex A-kontroller. I ISMS.online kan du forbinde hver leverandør med stor indflydelse til konkrete fejltilstande, afhjælpende foranstaltninger og hændelser, hvilket gør det meget nemmere at guide en revisor, licensgiver eller platformpartner gennem "sådan tænkte vi om denne motor eller anti-snydeudbyder, og sådan gør vi, når den opfører sig forkert." Den forberedelse betaler sig, når noget går galt; dine teams følger en forudbestemt playbook i stedet for at diskutere grundlæggende ting klokken 3 om natten.

Hvordan viser kontrakter og SLA'er, at risikoen i IKT-forsyningskæden kontrolleres, ikke blot noteres?

Kontrakter, arbejdsbeskrivelser og SLA'er er de steder, hvor dit A.5.21-risikoperspektiv bliver til håndhævelige forpligtelser. De forvandler "vi bekymrer os om dette" til "vores leverandør har indvilliget i at hjælpe os med at håndtere dette".

Hvad bør kontrakter for Tier 1 IKT-leverandører normalt omfatte?

For tjenester, der ligger på kritiske stier – live infrastruktur, betalinger, søgemotorer, anti-cheat, identitet – forventer du typisk at se:

Tydelige forventninger til sikkerhed og privatliv, der stemmer overens med dine egne politikker og rammer.
Definerede oppetid-, RTO/RPO- og supportmål, der afspejler, hvor kritisk tjenesten er i jeres risikoregister.
Tidsrammer for underretning om hændelser, eskaleringsstier og forventninger til informationsdeling.
Regler for datahåndtering, underdatabehandlere og grænseoverskridende overførsel, der respekterer alle relevante jurisdiktioner.
Forholdsmæssige rettigheder til revisionsoplysninger (certificeringer, testresuméer, uafhængige revisionsrapporter).
Specifikke klausuler for fairness-relaterede tjenester (f.eks. telemetri mod snyd, bistand ved efterforskning, opsigelsesrettigheder, hvis integriteten kompromitteres).

Leverandører med mindre indflydelse skal stadig undgå at underminere jeres sikkerhedspolitik, men sproget kan være lettere, og jeres kontroller kan være mere fokuserede på onboarding og grundlæggende overvågning.

Hvordan kan du hurtigt kontrollere, om din kontraktlige position stemmer overens med din risikoposition?

Et simpelt internt evalueringsmønster er:

Vælg et par Tier 1-leverandører: fra dit ISMS.
Sammenlign dit risikoregister med deres kontrakter: Stemmer sikkerheds-, tilgængeligheds- og responsklausuler overens med, hvor "kritiske" du siger, de er?
Tjek privatlivs- og platformforpligtelser: Er deres vilkår for datahåndtering og underdatabehandlere forenelige med jeres forpligtelser over for spillere, platforme og tilsynsmyndigheder?
Se anmeldelser og fornyelser: Bliver performance og hændelser eksplicit diskuteret, og er disse diskussioner synlige i jeres ISMS?

Hvis svarene er uklare, har du fundet en kløft mellem risiko og kontrakt. ISMS.online hjælper dig med at lukke denne kløft ved at forbinde leverandørregistre, risici, vurderinger, anmeldelser og dokumenter, så du kan vise en ren kæde fra "vi identificerede denne risiko" til "vi ændrede, hvordan vi køber og driver tjenesten" og "vi kontrollerer, om den stadig er acceptabel". Det er denne kæde, som eksterne anmeldere kigger efter, når de beslutter, om A.5.21 er reelt integreret eller blot beskrevet i politikerklæringer.

Hvordan kan en ISMS-platform gøre A.5.21 brugbar for ingeniør-, sikkerheds- og live-operationsteams?

En ISMS-platform gør A.5.21 brugbar ved at omdanne forsyningskæderisiko til et fælles sæt rutiner, der passer ind i, hvordan dine teams allerede opbygger og kører spil. I stedet for en separat "compliance-proces" får du et sæt rækværk, der vises på de punkter, hvor beslutninger træffes.

Hvordan ser det ud for forskellige hold i praksis?

Producenter og produktchefer: kan se, om en leverandør allerede findes i lageret, og hvilket niveau den er, før der forpligtes til en ny afhængighed.
Ingeniører og live-operationer: kan følge en velkendt tjekliste til A.5.21-vurderinger i stedet for at gætte på, hvilke "sikkerhedsbehov" der er ud fra dem.
Sikkerheds- og risikoteams: kan opretholde én leverandørrisiko-workflow på tværs af cloud, betalinger, SDK'er og driftsværktøjer, med klare udløsere for dybere due diligence.
Jura og indkøb: har adgang til klausulmønstre og tidligere beslutninger, så de ikke genforhandler fra bunden hver gang.
Ledelse: kan se, hvilke leverandører der understøtter nøgletjenester eller regioner, hvilke der har åbne handlinger, og hvordan leverandørproblemer har bidraget til hændelser eller nærved-uheld.

Når en ekstern revision, platformsgennemgang eller en større hændelse finder sted, er det de samme optegnelser, der fører til fokuserede bevismaterialepakker og forbedringer efter hændelsen i stedet for tidskrævende arkæologi.

Hvordan hjælper ISMS.online dig med at integrere A.5.21 i et integreret system i Annex L-stil?

Fordi ISMS.online er bygget op omkring principperne i bilag L, kan leverandørstyring genbruges på tværs af:

Sikkerhed: ISO 27001 og relaterede rammer.
Privacy: ISO 27701, GDPR og andre regionale love.
kontinuitet: ISO 22301 og robusthedsforpligtelser (herunder NIS 2- og DORA-koncepter, hvor det er relevant).
Ny AI-styring: i takt med at AI-drevne tjenester og modeller bliver reguleret.

Leverandørregistreringer, risikovurderinger, kontroller, hændelser, kontrakter og gennemgangsnotater er samlet ét sted, knyttet til jeres centrale risikoregister og anvendelighedserklæring. Det betyder, at I tænker én gang og anvender det mange gange, i stedet for at køre separate, inkonsistente processer i hvert domæne.

For din organisation er resultatet, at risikoen i IKT-forsyningskæden bliver en del af, hvordan I designer, leverer og driver spil hver uge. Hvis I vil teste, om det er sandt i dag, så stil et simpelt spørgsmål: "Kan en ledende ingeniør eller producent forklare, hvilke leverandører der er Tier 1, og hvordan de bliver evalueret?" Hvis svaret er nej, er det en af de hurtigste måder at afstemme, hvad teams gør, med det, jeres certifikater hævder, at integrere A.5.21 fuldt ud i en ISMS-platform som ISMS.online.

ISO 27001 A.5.21 – Sikkerhed i IKT-forsyningskæden for udbydere af spilteknologi