Hur ISO 27001 A.5.21 skyddar spelplattformar från risker i IKT-leveranskedjan

Varför är er leveranskedja för spel-IKT nu en del av er attackyta.

Er leveranskedja för spel-IKT är en del av er attackyta eftersom spelare upplever era leverantörers avbrott, buggar och intrång som era misslyckanden. Varje motor, SDK, molntjänst och betalningsleverantör som berör spelardata, spellogik eller intäkter beter sig effektivt som en del av er egen plattform, så svagheter i dessa länkar blir snabbt svagheter i er tjänst.

Dina spel är nu beroende av ett tätt nätverk av spelmotorer, molntjänster, SDK:er och betalningssystem som sträcker sig långt bortom din egen kod och dina egna servrar. En modern spelplattform kan luta sig mot en kommersiell spelmotor, flera SDK:er för analys och annonser, leverantörer av sociala inloggningar, flera betalningsgateways, ett innehållsleveransnätverk, anti-fusktjänster, modereringsverktyg och bygg- eller patchningspipelines som du inte driver. Var och en hanterar spelardata, spellogik, kryptografiska hemligheter eller intäktsflöden, och därför utökar var och en din praktiska attackyta.

Om en partners uppdateringsprocess kapas, ett SDK introducerar en sårbarhet eller en konfigurationsändring skickas utan förvarning, märker du av effekterna som om incidenten inträffade i din egen miljö. Det kan innebära driftstopp under ett liveevenemang, skadade progressionsdata, otillbörligt konkurrensutsatt spel eller direkt ekonomisk förlust. Ur en revisors eller tillsynsmyndighets perspektiv är du ansvarig för att hantera dessa beroenden som en del av ditt informationssäkerhetshanteringssystem (ISMS), inte för att behandla dem som någon annans problem.

Denna information är allmän och utgör inte juridisk eller regulatorisk rådgivning. Du bör alltid bekräfta exakta skyldigheter med kvalificerade yrkespersoner i de jurisdiktioner där du är verksam.

Hur skadar tredjepartsmisslyckanden faktiskt spelplattformar?

Tredjepartsmisslyckanden skadar spelplattformar genom att bryta mot de upplevelser och garantier som spelare, partners och tillsynsmyndigheter bryr sig mest om. Avbrott, dataläckor eller otillbörligt spel orsakat av leverantörer skadar fortfarande ditt rykte, även om din interna kod och infrastruktur förblir säker. Dessa misslyckanden blir snabbt ditt problem i din community och dina kommersiella partners ögon.

Ett stort molnavbrott kan orsaka att matchmaking eller inloggning blir offline i timmar under en viktig händelse. Ett komprometterat analys-SDK kan stjäla inloggningsuppgifter, vilket leder till kontoövertagande, bedrägerier och tvister om återkrav. Ett fel i en fjärransluten anti-fusktjänst kan flagga legitima spelare och förstöra förtroendet för konkurrenskraftiga stegar. I alla dessa fall avgör dina kontrakt, arkitektur och övervakning om problemet är under kontroll och förklarbart, eller om det blir en fullskalig kris som äventyrar certifiering och kommande revisioner.

Varför bryr sig ISO 27001 om detta specifikt inom spel?

ISO 27001 bryr sig om IKT-risker i leveranskedjan inom spel eftersom moderna spel är digitala tjänster vars tillförlitlighet och rättvisa alltid är beroende av ett ekosystem snarare än en enda applikation. Spelplattformar hanterar stora volymer personuppgifter, betalningar och, i vissa fall, reglerade spelaktiviteter, så tillsynsmyndigheter och större plattformar behandlar dem i allt högre grad som kritiska tjänster.

Riktlinjer för informationssäkerhetshantering betonar att organisationer måste behandla externa teknikleverantörer som en del av sitt eget risklandskap. För spel innebär det att bilaga A.5.21 helt och hållet täcker molninfrastruktur, motorer, SDK:er, anti-cheat, identitet och betalningar, samt de pipelines som bygger och distribuerar dina klienter och innehåll. Om du bara kan prata om dina egna servrar och inte om de tjänster som omger dem, kommer din säkerhetshistoria, ditt riskregister och din tillämplighetsförklaring (SoA) att verka ofullständig för revisorer.

Boka demo

Vad kräver egentligen ISO 27001:2022 bilaga A.5.21 av spelleverantörer?

ISO 27001:2022 bilaga A.5.21 kräver att ni definierar och kör repeterbara processer för att identifiera och hantera informationssäkerhetsrisker som uppstår från de IKT-produkter och -tjänster ni är beroende av. I praktiken innebär det att veta vilka leverantörer som är viktiga, förstå hur de kan påverka era spel och spelare, och att kunna visa konsekventa bedömnings- och behandlingsbeslut under hela deras livscykel.

Eftersom hela texten i bilaga A är upphovsrättsskyddad beskriver offentliga sammanfattningar A.5.21 på följande sätt: du bör definiera och implementera processer och procedurer för att hantera informationssäkerhetsrisker i samband med leveranskedjan för IKT-produkter och -tjänster. Standarden föreskriver inte specifika verktyg eller talar om för dig vilka leverantörer du ska välja; den förväntar sig att du har ett strukturerat sätt att förstå och kontrollera den risk som dessa leverantörer introducerar, och att du länkar tillbaka den strukturen till ditt ISMS och din SoA.

För leverantörer av spelteknik innebär det frågor som: vilka tredje parter som kan påverka spelardata eller spelintegritet; vilken lägsta säkerhet ni förväntar er av dem; hur ni kontrollerar detta före och efter kontraktsundertecknande; och hur ni reagerar om något går fel. Bilaga A.5.21 ligger bredvid andra leverantörsfokuserade kontroller för att definiera krav och övervaka leverantörstjänster och bildar ett litet kluster inom bilaga A:s leverantörsrelaterade kontroller som styr hur ni arbetar med extern teknik som en del av er bredare kontrolluppsättning i bilaga A.

Hur passar A.5.21 in i resten av ert ISMS?

Inom ert ISMS är A.5.21 den kontroll som kopplar leverantörsrisker till er huvudsakliga riskhanterings- och styrningsmaskineri. Den länkar er leverantörslista, avtalskontroller, tekniska arkitektur och incidenthanteringsplaner tillbaka till det centrala system som stöder certifiering och ledningsgranskning.

I en typisk implementering kommer du att:

Referera till A.5.21 i ert SoA, där ni anger hur det tillämpas och motiveras.
Registrera risker inom IKT-leveranskedjan i ert centrala riskregister, snarare än i separata kalkylblad.
Visa hur leverantörsbedömningar, kontraktsklausuler och övervakningsrapporter bidrar till ledningens granskningar och interna revisioner.

Andra kontroller i bilaga A hanterar sedan detaljerade åtgärder: kontroller för leverantörsrelationer styr förväntningar och granskningar; kontroller för säker utveckling och ändringshantering styr hur motorer och SDK:er integreras; kontroller för loggning, övervakning och incidenthantering täcker detektering och respons. När du har definierat din A.5.21-process blir den ytterdörren genom vilken risker i IKT-leveranskedjan kommer in i den bredare kontrolluppsättningen.

Vad omfattar ”IKT-leveranskedja” i ett spelsammanhang?

I ett spelsammanhang omfattar "IKT-leveranskedja" alla externa produkter eller tjänster som väsentligt kan förändra konfidentialitet, integritet, tillgänglighet eller efterlevnad för dina spel och plattform. Det är bredare än klassisk outsourcing och inkluderar uttryckligen programvara, moln och byggpipelineberoenden som ligger bakom dina releasecykler och live-drift.

Detta inkluderar normalt molninfrastruktur och hanterade databaser; spelmotorer och kärnbibliotek; identitets- och åtkomsttjänster; verktyg för anti-fusk, bedrägeriupptäckt och riskhantering; SDK:er för analys, annons och attribution; innehållsleveransnätverk och patchsystem; backoffice-tjänster som påverkar rättigheter eller betalningar; och supporttjänster som kundsupportplattformar som kan återställa konton. Komponenter med öppen källkod och byggpipelines är också en del av bilden, även om du inte betalar en leverantör direkt för dem, eftersom de fortfarande formar hur säkra och förutsägbara dina utgåvor och e-sportsäsonger är.

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

ISO 27001 på ett enkelt sätt

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

Att börja

Hur avgränsar ni er leveranskedja för spel-IKT för A.5.21 utan att gå vilse?

Du granskar din leveranskedja för spel-IKT enligt A.5.21 genom att bestämma vilka leverantörer och komponenter som verkligen motiverar strukturerad riskhantering, och vilka som säkert kan följa lättare kontroller. Ett praktiskt sätt att behålla kontrollen är att bygga en nivåindelad inventering som återspeglar hur mycket skada varje leverantör kan orsaka om den misslyckas eller komprometteras, och sedan anpassa dina ISO 27001-processer till dessa nivåer.

Istället för att försöka täcka alla molnkonton eller mindre verktyg lika mycket, börjar du med att identifiera vilka leverantörer som är avgörande för att hålla spelen igång, skydda spelarnas tillgångar och uppfylla regulatoriska förväntningar. Dessa blir ditt högsta fokus för A.5.21, och de bör ha en framträdande plats i ditt riskregister och din motivering för SoA. Allt annat kan utvärderas mot tydliga tröskelvärden så att ditt teams tid spenderas där den betyder mest och du fortfarande kan förklara omfattningsbeslut för revisorer och större partners.

Vilket är ett förnuftigt sätt att bygga upp det leverantörslagret?

Ett klokt sätt att bygga upp ditt lager är att utgå från de system och upplevelser som aktörer och kunder bryr sig om, och sedan arbeta bakåt till de underliggande leverantörerna. Detta är ofta mer effektivt än att enbart börja med fakturor eller inköpslistor, eftersom det speglar hur avbrott och incidenter faktiskt ser ut i den faktiska driften.

Du kan till exempel lista kärntjänster i spelet, såsom inloggning, matchmaking, progression, lager, betalningar, chatt, topplistor och support. För varje tjänst, identifiera vilka externa parter som bidrar med teknik eller operativ kontroll, och gruppera sedan leverantörer i kategorier som molnhotell, motorer, SDK:er, betalningar, identitet, anti-cheat, innehållsleverans och backoffice. När du ser vilka leverantörer som befinner sig i gränslandet mellan spelare, data och pengar kan du tilldela kritiskhets- och känslighetspoäng till var och en, och kontrollera att de leverantörer som har störst påverkan tydligt faller inom A.5.21:s omfattning.

Hur avgör man vad som verkligen hör hemma i A.5.21-omfånget?

Du bestämmer vad som ingår i kriterierna genom att kombinera teknisk påverkan, affärspåverkan och regelverksmässig exponering till enkla kriterier som kan tillämpas konsekvent. Några fokuserade frågor hjälper dig att bedöma om en leverantör motiverar fullständig A.5.21-behandling eller en lättare strategi.

Användbara tester inkluderar:

Bearbetar eller påverkar denna leverantör personliga, ekonomiska eller på annat sätt reglerade spelardata?
Kan ett fel eller en kompromiss hindra spelare från att logga in, betala, gå vidare eller tävla rättvist?
Förväntar sig tillsynsmyndigheter, plattformsinnehavare eller viktiga företagskunder uttryckligen att du ska styra denna relation?
Skulle det vara svårt att snabbt byta ut denna leverantör utan driftsmässiga eller kommersiella störningar?

Om svaret är "ja" på något av dessa är leverantören en stark kandidat för att inkluderas i era A.5.21-processer och riskregister. Samtidigt bör ni vara medvetna om att vissa interna verktyg med låg risk kanske inte förtjänar den fulla tyngden av era leveranskedjeprocedurer. Att tillämpa väsentlighetströsklar och dokumentera beslut om avgränsning hjälper er att förbli proportionerliga, undvika att förlama spelleveranser och förbli redo för förklaringar inför certifiering eller plattformsbedömningar.

Tydliga beslut om omfattning och enkla nivåer gör leveranskedjesäkerhet till en process som team faktiskt kan köra.

Vilka styrnings- och livscykelprocesser behöver ni kring IKT-leverantörer?

Ni behöver styrnings- och livscykelprocesser som gör leverantörsrisker från ad hoc-samtal till en repeterbar, granskningsbar del av hur ni väljer, driver och lämnar IKT-tjänster. Det innebär att definiera vem som kan godkänna vilka typer av leverantörer, på vilka bevis och hur beslut och undantag registreras så att ni kan visa kontroll under revisioner och plattformsgranskningar.

Styrningen för A.5.21 kräver inte en ny kommitté för varje leverantör, men det kräver tydlighet. Utan den tydligheten lägger utvecklare till SDK:er under tidspress, upphandling förhandlar kontrakt enbart baserat på kostnad, och säkerheten ser bara leverantörer när något redan har gått sönder. För en spelorganisation med frekventa utgåvor och liveevenemang dyker det ofta upp vid de värsta tänkbara tillfällena. A.5.21 driver dig mot en samordnad livscykelhantering som passar befintliga leveransrytmer, och ett sätt att uppnå det är att definiera en enkel, delad livscykel som varje viktig leverantör går igenom.

Hur ser en A.5.21-anpassad leverantörslivscykel ut?

En A.5.21-anpassad livscykel följer vanligtvis fem steg som du kan beskriva, tilldela och bevisa. Varje steg bör ha tydliga aktiviteter, ägare och resultat som kopplas tillbaka till ditt ISMS.

Steg 1 – Urval

Definiera kategorispecifika säkerhets- och motståndskraftskrav och granska kandidatleverantörer mot dem innan den tekniska integrationen påbörjas.

Steg 2 – Onboarding

Genomför en strukturerad riskbedömning, kom överens om avtalsenliga kontroller, tilldela internt ägarskap och registrera resultaten i era ISMS och SoA.

Steg 3 – Drift

Övervaka prestanda, incidenter och efterlevnad av överenskomna skyldigheter, och håll leverantörsregister aktuella allt eftersom funktioner och säsonger ändras.

Steg 4 – Förändring

Omvärdera risken när leverantören eller din användning av dem förändras väsentligt, till exempel hantering av ny data eller högre transaktionsvolymer.

Steg 5 – Avsluta

Planera dataåterlämning eller radering, nyckelöverlämning och driftsövergång för att undvika okontrollerad exponering eller driftstopp när kontrakten löper ut.

Genom att utforma din livscykel på detta sätt kan du visa revisorer, plattformar och företagskunder att leverantörsrisker hanteras som en kontinuerlig process, inte en engångsföreteelse vid kontraktsundertecknandet.

Hur integrerar man dessa processer utan att lamslå spelleveransen?

Du integrerar dem genom att anpassa kontroller till beslutspunkter som redan finns: finansieringsgodkännanden, grönt ljus för funktioner, större innehållsuppdateringar, esportsäsonger och kontraktsförnyelser. Målet är att få in A.5.21-frågor i stunder där lag redan saktar ner för att göra val, snarare än att införa nya begränsningar överallt och fördröja releasecykler.

Om till exempel en ny anti-fusk- eller betalningsintegration är avgörande för en funktion, bör beslutet att fortsätta inkludera en bekräftelse på att grundläggande leverantörskontroller har gjorts och viktiga klausuler har överenskommits. Om en befintlig leverantör uppgraderas för att hantera nya typer av spelardata eller högre transaktionsvolymer, bör den förändringen utlösa en kort omvärdering av risken och, om nödvändigt, justeringar av övervakning eller kontrakt. Styrning blir ett tunt men konsekvent lager över befintliga arbetsflöden, inte ett hinder.

En plattform som ISMS.online kan hjälpa till genom att tillhandahålla en enda miljö där leverantörsregister, A.5.21-anpassade riskbedömningar, godkännanden och övervakningsloggar finns tillsammans med era ISO 27001-kontroller. Det minskar frestelsen att skapa separata, kortlivade kalkylblad för varje ny relation och gör det enklare att demonstrera livscykeldisciplin under revisioner.

När grunderna i styrning och livscykel är på plats kan du titta mer konkret på de specifika hoten inom IKT-leveranskedjan som är mest relevanta för dina spel.

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

Boka din demo

Vilka hot inom IKT-leveranskedjan drabbar spel hårdast, och hur hjälper A.5.21?

De hot inom IKT-leveranskedjan som drabbar spelbranschen hårdast är de som bryter mot tillgänglighet, rättvisa, betalningsintegritet eller spelarnas förtroende genom svagheter som du inte helt kontrollerar. Med en definierad A.5.21-process på plats kan du fokusera den styrningen på de leverantörer och scenarier som utgör de största riskerna för dina spelare och intäkter.

Vanliga exempel inkluderar kontoövertagande genom komprometterade partners, skadlig kod inbäddad i SDK:er, manipulation av topplistor eller matchmaking via leverantörsåtkomst och falska eller manipulerade betalningsintegrationer. Var och en av dessa utnyttjar gapet mellan hur mycket förtroende du ger en leverantör och hur mycket trygghet du har om deras beteende och säkerhet. För en spelleverantör leder det ofta till störningar, toxiska communityreaktioner och obekväma samtal om huruvida dina kontroller verkligen är effektiva.

Hur kopplas dessa hot till praktiska kontroller?

Du kan kartlägga hot mot praktiska kontroller genom att para ihop varje scenario med specifika förebyggande, detektiv- och avtalsmässiga åtgärder, och sedan registrera den kartläggningen i ditt ISMS. Tabellen nedan illustrerar en enkel metod för fyra framträdande hottyper.

Innan tabellen visas är det värt att notera att A.5.21 inte föreskriver exakta kontrolluppsättningar för varje scenario. Istället förväntas det att du visar att du har tänkt igenom hur leverantörer kan missbrukas och valt rimliga kontroller för att minska dessa risker till en acceptabel nivå i din miljö.

Hotscenario	Exempel på påverkan inom spel	Viktiga A.5.21-anpassade kontroller
Kontoövertagande via partners	Spelare förlorar åtkomst och värde; bedrägerier och supportökningar	Starka krav på identitetsleverantörer, övervakning av delade sessioner, tydliga incidentuppgifter
Skadlig kod i SDK:er eller motorer	Klienter exfiltrerar data eller kör dold kod	Leverantörsgranskning, kodintegritetskontroller, sandlådor, snabba kill-switch-vägar
Riggade topplistor eller matchmaking	Tävlingsscener och spelekonomier förlorar trovärdighet	Segregering av arbetsuppgifter för databehandlingspartners, styrning mot fusk, revisionsloggar
Falska eller komprometterade betalningsflöden	Stulen kortdata, feldirigerade intäkter, återkrav	Certifierade betalningsleverantörer, säkert integrationsmönster, bedrägeriövervakning, avtalsskydd

Dessa kontrolluppsättningar förlitar sig ofta på andra kontroller i bilaga A för åtkomstkontroll, övervakning, säker utveckling och incidenthantering, men er A.5.21-process tillhandahåller styrningsramen som säger: ”Vi funderade på detta beroende; här är varför vi litar på det och hur vi fortsätter att övervaka det.” Varje scenario kan omvandlas till ett kort, återanvändbart kontrollmönster i ert ISMS som länkar synliga spelarresultat tillbaka till tydliga, granskningsbara mått.

Finns det andra ISO 27001-kontroller som stöder A.5.21 i spel?

Ja. Medan A.5.21 fokuserar på styrning av IKT-leveranskedjan, är flera andra kontroller i bilaga A vanligtvis kopplade till samma risker i spelmiljöer och bör refereras till i er SoA och interna rutiner.

Leverantörsrelationskontroller kräver att du definierar säkerhetsförväntningar och granskar leverantörernas prestanda. Kontroller för säker utveckling, teknisk härdning och konfigurationshantering hjälper dig att integrera motorer, SDK:er och tjänster på ett säkert sätt. Loggnings- och övervakningskontroller stöder detektering av ovanligt beteende kopplat till leverantörer. Incidenthantering och kontroller för affärskontinuitet säkerställer att du kan reagera och återställa när en tredje part misslyckas, inklusive kring viktiga händelser och säsongsbetonade toppar.

Tillsammans bildar dessa kontroller ett nätverk: A.5.21 uppmanar dig att bry dig om IKT-leveranskedjan som helhet; andra kontroller i bilaga A ger dig verktygen för att göra något åt specifika svagheter. När du dokumenterar dessa kopplingar tydligt gör du det enklare för revisorer, plattformspartners och företagskunder att följa hur leverantörsrisker löper igenom ditt ISMS och varför ditt tillvägagångssätt är proportionerligt.

Hur kan man utforma en praktisk A.5.21-riskbedömningsprocess för spelleverantörer?

Du kan utforma en praktisk riskbedömningsprocess enligt A.5.21 genom att följa en kort, repeterbar sekvens: bygg upp en inventering, klassificera leverantörer efter kritiskhet, identifiera relevanta hot, poängsätt risker, välj behandlingar och registrera resultat i ditt ISMS. Nyckeln är att hålla metoden tillräckligt enkel för att teamen ska använda den, men tillräckligt strukturerad för att revisorer och partners kan se att du är konsekvent och att viktiga leverantörer verkligen behandlas mer noggrant än mindre verktyg.

För spelleverantörer måste den här processen hantera snabba förändringar. Nya leverantörer, SDK:er och tjänster dyker upp ständigt; er process bör hantera den takten utan att behöva uppfinna sig själv varje gång. Ett gott tecken är när utvecklare eller producenter kan besvara de viktigaste riskfrågorna med minimalt stöd från specialister, eftersom kriterierna och mallarna är tydliga, och när ni kan ta fram en liten uppsättning representativa bedömningar som bevis för ISO 27001-revisioner och SoA-granskningar.

Hur ser en stegvis A.5.21-bedömning ut?

En stegvis A.5.21-bedömning kan delas upp i ett antal tydliga steg som är anpassade till din leverantörs livscykel och riskaptit.

Steg 1 – Bekräfta omfattning och kritiskhet

Tillämpa dina kriterier för att avgöra om leverantören omfattas av A.5.21:s omfattning och bedöm sedan kritiskhet baserat på de tjänster och data den berör.

Steg 2 – Identifiera hot och fellägen

Lista rimliga sätt som konfidentialitet, integritet, tillgänglighet eller efterlevnad kan skadas, såsom avbrott, dataläckor, missbruk av privilegier, fusk eller bedrägeri.

Steg 3 – Utvärdera risk och befintliga kontroller

Poängsätt sannolikhet och påverkan med hjälp av din organisations standardskalor och kartlägg nuvarande kontroller såsom certifieringar, tekniska skyddsåtgärder och intern övervakning.

Steg 4 – Bestäm behandlingar och ägare

Där den kvarvarande risken är för hög, definiera åtgärder som starkare integrationsmönster, striktare avtalsvillkor, förbättrad övervakning eller leverantörsbyte, och tilldela sedan ägare och granskningsdatum.

När dessa steg är dokumenterade och kopplade till specifika leverantörer kan du visa att beslut om sökmotorer, molnplattformar eller betalningsleverantörer är grundade på en konsekvent metod snarare än informella intryck.

Hur gör man att bedömningarna är lätta men trovärdiga?

Ni håller bedömningarna enkla men trovärdiga genom att nivåindela leverantörer och skräddarsy bedömningsdjupet därefter, samtidigt som ni återanvänder mallar och skalor så att liknande situationer ger liknande resultat. Högriskleverantörer kan motivera detaljerade frågeformulär, granskning av oberoende revisionsrapporter och gemensamma testplaner, medan lågriskverktyg kanske bara behöver en kort checklista och snabb bekräftelse på att de inte hanterar känsliga uppgifter.

För att skydda trovärdigheten bör du:

Använd standardiserade bedömningsmallar och poängmodeller i alla team.
Säkerställ att resultaten matas direkt in i kontrakt, onboardinguppgifter, övervakningsplaner och incidentplaner.
Granska högriskbedömningar regelbundet, inte bara vid kontraktsförnyelse.

En plattform som ISMS.online kan centralisera dessa bedömningar, länka dem till kontroller och leverantörer, och avslöja var granskningar är försenade. Det gör det enklare att upprätthålla processen över tid, även när teamen är under press från releasecykler, live-evenemang eller nya plattformskrav.

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

Boka din demo

Hur omvandlar man A.5.21 till konkreta kontrakt, SLA:er och operativa kontroller?

Ni omvandlar A.5.21 till konkreta kontrakt, servicenivåer och operativa kontroller genom att integrera era riskbaserade förväntningar i den juridiska och tekniska strukturen i varje relation. Standarden förväntar sig att ni inte bara förstår riskerna utan också agerar utifrån dem på sätt som leverantörer kan se, acceptera och mätas mot, så att ni kan framlägga tydliga bevis på dessa förväntningar under ISO 27001-revisioner och kundkontroll.

Detta innebär vanligtvis att utveckla standardiserade säkerhetsscheman för olika leverantörskategorier, definiera tidslinjer för incidentanmälningar, specificera revisions- och rapporteringsrättigheter och beskriva minimikraven för tekniska skyddsåtgärder. Det innebär också att komma överens om hur data ska hanteras, var de ska finnas, hur länge de ska behållas och hur de ska returneras eller raderas när relationen upphör. Exemplen i det här avsnittet är illustrativa; du bör alltid söka din egen juridiska rådgivning när du utarbetar eller förhandlar om specifik avtalstext.

Vad ska man leta efter i avtal med spelleverantörer?

I avtal med spelleverantörer bör ni leta efter tydliga formuleringar gällande säkerhetsansvar, tjänstekontinuitet, incidenthantering och datastyrning, anpassade till leverantörens risknivå. Ju mer en leverantör berör spelardata, spelsaldo eller intäkter, desto mer explicita och krävande bör era klausuler vara.

För kritiska leverantörer som sökmotorer, anti-fusktjänster, molnplattformar och betalningsgateways kan ni förvänta er åtaganden att upprätthålla erkända säkerhetscertifieringar, att meddela er om relevanta incidenter inom specifika tidsramar, att delta i gemensamma utredningar där så är lämpligt och att stödja rimliga säkerhetsåtgärder. Ni kan också kräva begränsningar för användningen av underleverantörer, tydliga regler för telemetri och data om spelarbeteende, samt robusta bestämmelser för återlämnande eller radering av data vid kontraktets slut.

För leverantörer med lägre risk kan ni förlita er mer på standardvillkor och branschtypiska säkerhetsbestämmelser, förutsatt att de fortfarande överensstämmer med era policyer och riskbenägenhet. Det viktiga är att era kontrakt återspeglar resultaten av era A.5.21-riskbedömningar, så att ni kan visa en tydlig linje från riskidentifiering till avtalskontroll.

Hur kopplas dessa skyldigheter tillbaka till ISO 27001-bevis?

Dessa skyldigheter kopplas tillbaka till ISO 27001-bevis genom att ge er konkreta bevis att visa revisorer, plattformar och företagskunder. Er A.5.21-process är lättare att demonstrera när ni kan peka på specifika klausuler, överenskomna servicenivåer och register över incidentrapporter eller säkerhetsgranskningar som motsvarar högriskleverantörer i ert lager.

Revisionsklara bevis inkluderar ofta:

Standardavtalsmallar och säkerhetsscheman för viktiga leverantörskategorier.
Utdrag ur undertecknade avtal för kritiska leverantörer som visar säkerhets- och incidentanmälningsklausuler.
Ändringsloggar som visar när säkerhetsrelevanta villkor har uppdaterats eller granskats.
Register över regelbundna granskningar, servicerapporter eller gemensamma incidentövningar.

När dessa dokument är kopplade till era riskbedömningar och leverantörsinventeringar bildar de en tydlig berättelse: ni identifierade en risk, satte förväntningar, fick garantier och justerade efter behov. En ISMS-centrerad plattform som ISMS.online kan hjälpa till genom att lagra dessa artefakter tillsammans med relevanta kontroller och risker, och genom att tillhandahålla enkla dashboards för att besvara frågor som "vilka högriskleverantörer saknar en överenskommen klausul om incidentmeddelande" eller "vilka granskningar är försenade", utan att ni behöver leta igenom spridda mappar.

Boka en demo med ISMS.online idag

ISMS.online hjälper dig att förvandla ISO 27001 A.5.21 från ett oroande krav till ett praktiskt, dagligt sätt att hantera risker i IKT-leveranskedjan över hela din spelplattform. Genom att hålla leverantörsinventeringar, riskbedömningar, kontrakt, kontroller och övervakning i en och samma miljö kan du få en tydlig, evidensbaserad bild av de motorer, SDK:er, molnplattformar och betaltjänster som nu definierar din attackyta.

Om ni förbereder er för ISO 27001:2022-certifiering, utökar ett befintligt ISMS för att omfatta ett växande ekosystem av leverantörer, eller svarar på svårare frågor från plattformar och företagskunder, kan en kort demonstration göra vägen mycket tydligare. Ni kan se hur leverantörsnivåer, bedömningar, godkännanden och klausulbibliotek fungerar i praktiken, och hur de länkar tillbaka till er SoA och centrala riskregister utan att störa publiceringsscheman eller live-drift.

Vad kommer du att se i en demo?

I en demo ser du hur leverantörsstyrning, riskbedömning och kontroller enligt bilaga A samlas i ett enda, spelmedvetet ISMS. Fokus ligger på att visa dig praktiska arbetsflöden snarare än abstrakta funktioner, så att du kan föreställa dig hur dina egna team skulle använda dem under verkliga projekt och evenemang.

En typisk session går igenom hur man konfigurerar en leverantörsinventering, nivåindelar leverantörer efter påverkan, kör en A.5.21-anpassad bedömning och kopplar resultat till kontrakt, kontroller och revisioner. Du ser också hur granskningar, incidentregister och ledningsrapporter samlas in, så att du kan svara på frågor från revisorer, plattformar och företagskunder utan att behöva leta bland verktyg eller kalkylblad.

Hur bör olika team förbereda sig inför ett pilotprojekt?

Du får ut mest värde av ett pilotprojekt när varje nyckelperson har ett verkligt problem de vill lösa, snarare än bara en teoretisk önskelista. Det kan vara ett blockerat ISO 27001-projekt, ett skört leverantörskalkylblad eller en våg av nya plattformsfrågeformulär som du behöver besvara med tillförsikt.

Snabbanpassade leverantörer som fokuserar på att uppnå ISO 27001 för första gången kan förbereda sig genom att lista ett antal kritiska leverantörer och de avtal eller plattformsrelationer som är beroende av certifiering. Team som stärker ett befintligt ISMS kan ta med sig aktuella riskregister, SoA-poster och kontraktsmallar, och sedan testa hur väl dessa kartläggs i en enhetlig, leveranskedjemedveten modell. I båda fallen hjälper det att börja med en liten, representativ uppsättning moln-, betalnings- och anti-fuskleverantörer er att snabbt bevisa tillvägagångssättet och generera artefakter som ni kan återanvända i kommande revisioner, säkerhetsfrågeformulär och plattformsgranskningar.

Ni kan sedan expandera till andra delar av er spelstack, säker på att er strategi för IKT-leveranskedjans säkerhet är proportionerlig, förklarlig och i linje med ISO 27001 A.5.21 och relaterade kontroller i bilaga A. När ni är redo att gå ifrån bräckliga kalkylblad och ad hoc-processer är det ett enkelt nästa steg mot en leveranskedjans säkerhetsmodell som era leveransteam, ledning och revisorer kan leva med.

Boka demo

Vanliga frågor om partihandel med mat och dryck

Hur förändrar ISO 27001 A.5.21 egentligen de dagliga besluten för en spelleverantör?

ISO 27001 A.5.21 förändrar dina dagliga beslut genom att tvinga dig att behandla kritiska IKT-leverantörer som en del av din live-spelmiljö, inte som externa svarta lådor. Leverantörer, SDK:er, moln, betalningar, anti-cheat, CDN:er, identitet, analys och byggpipelines går alla från "upphandlingsval" till "säkerhetsrelevanta tillgångar" inom ditt ISMS.

I praktiken innebär det att du slutar godkänna leverantörer enbart baserat på funktioner och pris, och börjar ställa tre disciplinerade frågor varje gång:

Vilken är den verkliga effekten av denna IKT-leverantör på spelare och intäkter?

Du bedömer om tjänsten kan:

Förhindra att spelare ansluter eller förblir anslutna.
Korrumpera eller förlora progression eller föremål.
Snedvränga konkurrensintegriteten eller skyddet mot bedrägerier.
Bryt plattform, spel eller integritetsskyldigheter.
Blockera, försena eller feldirigera betalningar och återbetalningar.

Om något av dessa gäller omfattas leverantören av A.5.21-tillämpningsområdet och måste synas i ert ISMS, riskregister och tillämplighetsförklaring.

Hur bevisar man att IKT-risker hanteras aktivt?

Du går från ad hoc-frågeformulär och e-postspår till ett upprepningsbart mönster:

En tydlig leverantörshistorik med nivåindelning och ägarskap.
En kort, strukturerad riskbedömning kopplad till ert kärnriskregister.
Kartlagda kontroller i bilaga A (inklusive A.5.21, men även A.5.19, A.5.23, A.8.8 och A.8.20–A.8.22 där så är relevant).
Behandlingsbeslut, åtgärder och granskningsdatum som faktiskt sker.

När en molnregion misslyckas eller en SDK-uppdatering inte fungerar korrekt kan du visa exakt vad du antog, hur du åtgärdade det och hur du förbättrar dig, istället för att rekonstruera beslut från chattloggar.

Hur syns detta i ett integrerat ISMS- eller Annex L-system?

I ett integrerat ledningssystem i linje med bilaga L, ligger A.5.21 till grund för en gemensam leverantörsstyrningsprocess för säkerhet, integritet, kontinuitet och, snart, AI-styrning. Istället för fyra separata leverantörslistor och riskarbetsflöden kör ni ett A.5.21-förankrat arbetsflöde som uppfyller kraven i ISO 27001, ISO 27701 , ISO 22301 och NIS 2/DORA-liknande bestämmelser.

ISMS.online konkretiserar detta genom att samla leverantörsuppgifter, riskbedömningar, kontrollmappningar och incidentlänkar på ett ställe. Det låter revisorer, licensgivare och plattformspartners se att risker i IKT-leveranskedjan är en del av hur ni driver verksamheten vecka för vecka, inte något ni bara tänker på när det är dags för ett certifikatförnyelse.

Om du vill kontrollera din egen situation, välj en sökmotor eller leverantör av fuskskydd och se om du kan spåra en rak linje från affärspåverkan → riskbedömning → kontroller → kontrakt → granskningsanteckningar. Om inte, har du en tydlig utgångspunkt för att skärpa A.5.21.

Hur ska en spelstudio avgöra vilka IKT-leverantörer som verkligen omfattas av A.5.21?

Du bestämmer A.5.21:s omfattning genom att börja med de resor som spelarna bryr sig om och arbeta dig bakåt till de leverantörer som kan avgöra om dessa ögonblick är avgörande eller förstörande. Frågan är inte "vem skickar oss en faktura?" utan "vem kan väsentligt skada förtroendet om de misslyckas eller beter sig illa?"

Hur kartlägger ni leverantörer från spelarnas upplevelse?

Gå igenom några konkreta flöden:

Skapande av konto, inloggning och rättigheter.
Matchmaking och sessionshantering.
Progression och inventeringar.
Tävlingsmässigt och rankat spel.
Betalningar, återbetalningar och chargebacks.
Liveevenemang och ekonomier i spelet.
Kundsupport och säkerhetsrapportering.

För varje flöde, lista alla externa produkter eller tjänster som:

Styr eller lagrar spelets status eller progression.
Bearbetar eller dirigerar pengar eller värdefulla virtuella föremål.
Fattar beslut om verkställighet (anti-fusk, bedrägerier, moderering).
Hanterar reglerade uppgifter (betalkort, personuppgifter, minderåriga).
Åtkomst via grindar (identitet, licensiering, plattformsefterlevnad).

Det är dina kandidatleverantörer enligt A.5.21 . Verktyg som ligger helt utanför de kritiska vägarna (till exempel ett marknadsföringsplugin med låg risk) kan ofta hanteras med enklare kontroller.

Hur kan en enkel trenivåmodell hålla omfattningen under kontroll?

De flesta studior får bra resultat från en slimmad trenivåmodell:

Hur kan leverantörsnivåer på nivå 1–3 fungera i ett spel-ISMS?

En tydlig trenivåmodell hjälper dig att visa proportionalitet utan att lägga ner samma ansträngning på varje SaaS-prenumeration.

Nivå 1 – Spelar- och intäktskritiska IKT-leverantörer:

Allt som kan stoppa tjänsten, korrumpera tillstånd, snedvrida rättvisa, läcka reglerad data eller bryta mot plattforms-/spel-/sekretessskyldigheter hör hemma här.

Nivå 2 – Viktiga men icke-kritiska leverantörer.

Tjänster som stöder drift, analys eller kommunikation, men som inte direkt kontrollerar spelets tillstånd eller reglerade data.

Nivå 3 – Energi med låg påverkan.:

Verktyg som kan misslyckas utan märkbar påverkan på spelarna och med minimal kontraktuell eller regulatorisk exponering.

Sedan tillämpar du hela A.5.21-disciplinen på nivå 1 (formella riskbedömningar, starkare kontrakt, stramare övervakning), lättare men fortfarande strukturerade kontroller på nivå 2 och grundläggande onboardingkontroller för nivå 3. I ISMS.online kan du återspegla detta med fält för nivå, ägare, kopplade risker och senaste granskningsdatum, så när någon frågar "varför behandlas denna leverantör annorlunda?" kan du visa att det var ett medvetet, dokumenterat beslut snarare än en gissning gjord under tidspress.

Hur kan vi utvärdera moln-, betalnings- och SDK-leverantörer utan att skapa en administrativ börda?

Du håller IKT-leveranskedjans bedömning hanterbar genom att standardisera ett arbetsflöde och återanvända det i molnet, betalningar och SDK:er, istället för att uppfinna ett nytt kalkylblad varje gång. Målet är konsekvent djup och minimal friktion.

Hur ser ett enda bedömningsmönster ut?

Ett praktiskt mönster för varje IKT-leverantör är:

Bekräfta att de ingår i A.5.21-omfattningen och tilldela en nivå.
Lista 3–7 realistiska fellägen som är viktiga för aktörer, tillsynsmyndigheter eller intäkter.
Sammanfatta vad du och leverantören redan gör åt dessa scenarier.
Bestäm eventuella extra behandlingar (tekniska, avtalsmässiga, övervakningsmässiga) med ägarna och datum.
Koppla allt till ert ISMS-riskregister och relevanta kontroller i bilaga A.

Sedan justerar du frågorna och exemplen efter kategori:

Cloud: regioner och tillgänglighetszoner, skalning och kapacitet, säkerhetskopiering och återställning, datalagring, isolering av hyresgäster, incidentrapportering.
betalningar: bedrägerier och återkrav, PCI DSS-anpassning, tidpunkt för förlikning, tvisthantering, plattformsspecifika regler (t.ex. appbutiker, spel).
SDK:er: kodintegritet, insamlad data, behörigheter, uppdateringsmekanismer, återställningsalternativ, kill-switchar, effekter av felkonfiguration.

Metoden förblir densamma; bara detaljerna ändras.

Vad räknas som ”precis tillräcklig” dokumentation för leverantörer med stor inverkan?

För Tier 1-leverantörer är "precis tillräcklig" dokumentation kort men spårbar:

En daterad riskbedömning som sammanfattar varför leverantören är kritisk och vilka scenarier som är viktiga.
Länkar till motsvarande ISMS-riskposter och kontroller i bilaga A (A.5.21 plus andra som är tillämpliga).
En förteckning över kvalitetssäkringsaktiviteter: certifikat, testrapporter, strukturerade frågeformulär om du använder dem.
Ett behandlingsbeslut och tydliga åtgärder, med ägare och granskningsdatum.

Med ISMS.online kan du paketera dessa element i en enda vy per leverantör, så när det inträffar en incident, extern revision eller plattformsfrågeformulär uppdaterar du en levande post istället för att bygga om din logik från grunden. Om din nuvarande metod inte kan producera en sammanfattning på en sida per nivå 1-leverantör på begäran, är det en stark signal om att A.5.21-arbetet sker i fragment snarare än som en hanterad process.

Vilka fel i motorer, SDK:er och anti-fusksystem bör våra kontroller förutse först?

De fel som spelar roll är de som spelarna upplever och som tillsynsmyndigheterna bryr sig om: ospelbara sessioner, orättvisa resultat, värdelöshet eller felaktigt hanterad data. Tekniska grundorsaker är viktiga internt, men kontroller för A.5.21 är enklare att utforma om man utgår från de synliga effekterna.

Vilka är realistiska misslyckandescenarier för leverantörer av IKT-teknik inom spel?

Tänk i kategorier som spelare och partners skulle känna igen:

Motorer och SDK:er:
En uppdatering som introducerar en säkerhetsbrist eller en tyst kraschloop.
En förändring i datainsamlingsbeteende som överskrider din publicerade integritetspolicy.
En trasig uppdateringssökväg som gör återställning eller snabbkorrigeringar långsamma eller osäkra.

Anti-fusk och bedrägeri:
Regler som plötsligt förbjuder en våg av legitima spelare.
Upptäcka blinda fläckar som gör att samordnat fusk eller bedrägeri kan frodas obemärkt.
Telemetriluckor som gör undersökningar långsamma eller ofullständiga.

Bygga pipelines och verktyg:
Komprometterad bygginfrastruktur som tillåter manipulerade tillgångar eller kod i live-byggen.
Felaktig signering eller distributionsfel som orsakar problem med uppdateringar på en plattform eller i en region.

Licensiering, identitet och behörighet:
Autentiserings- eller behörighetsavbrott som hindrar spelare från att starta eller gå med i sessioner.
Felaktigt tillämpade återkallelser eller regioninställningar som ser ut som riktade utelåsningar.

Varje scenario ger dig ett förankringspunkt för att designa kontroller som blandar styrning och teknik.

Hur omvandlar man dessa scenarier till kontroller som övertygar revisorer och plattformspartners?

För varje scenariofamilj, para ihop:

styrning: kriterier för leverantörsurval, minimiförväntningar för säker utveckling och testning, klausuler om rätt till information, krav på incidentanmälan, granskningskadens.
Teknisk: sandlådeintegrationer och åtkomst med lägsta behörighet, kodsignering och integritetskontroller, kontrollerade utrullnings- och återställningsmekanismer, telemetri anpassad till specifika risker, säkerhetsgrindar i er CI/CD.

Sedan mappar du dessa kontroller in i ditt ISMS och länkar dem till A.5.21 och andra relevanta kontroller i bilaga A. I ISMS.online kan du koppla varje leverantör med stor påverkan till konkreta fellägen, riskreducerande åtgärder och incidenter, vilket gör det mycket enklare att guida en revisor, licensgivare eller plattformspartner genom "så här tänkte vi kring den här motorn eller anti-fuskleverantören, och så här gör vi när den beter sig fel". Den förberedelsen lönar sig när något går fel; dina team följer en i förväg överenskommen handbok istället för att diskutera grunderna klockan 3 på morgonen.

Hur visar kontrakt och servicenivåavtal att risker inom IKT-leveranskedjan kontrolleras, inte bara noteras?

Kontrakt, arbetsbeskrivningar och SLA:er är de ställen där din A.5.21-risksyn blir verkställbara åtaganden. De förvandlar "vi oroar oss för detta" till "vår leverantör har gått med på att hjälpa oss att hantera detta".

Vad bör kontrakt för Tier 1 ICT-leverantörer vanligtvis omfatta?

För tjänster som ligger på kritiska vägar – liveinfrastruktur, betalningar, sökmotorer, anti-cheat, identitet – förväntar man sig vanligtvis att se:

Tydliga säkerhets- och integritetsförväntningar som överensstämmer med era egna policyer och ramverk.
Definierade mål för drifttid, RTO/RPO och support som återspeglar hur kritisk tjänsten är i ert riskregister.
Tidsramar för incidentanmälan, eskaleringsvägar och förväntningar på informationsdelning.
Regler för datahantering, underbiträden och gränsöverskridande överföringar som respekterar alla relevanta jurisdiktioner.
Proportionella rättigheter till revisionsinformation (certifieringar, testsammanfattningar, oberoende revisionsrapporter).
Specifika klausuler för rättviserelaterade tjänster (t.ex. telemetri mot fusk, utredningshjälp, uppsägningsrättigheter om integriteten äventyras).

Leverantörer med mindre påverkan behöver fortfarande undvika att undergräva er säkerhetsställning, men språket kan vara lättare och era kontroller mer fokuserade på onboarding och grundläggande övervakning.

Hur kan du snabbt kontrollera om din avtalsställning överensstämmer med din riskställning?

Ett enkelt internt granskningsmönster är:

Välj några Tier 1-leverantörer: från ditt ISMS.
Jämför ditt riskregister med deras kontrakt: Stämmer säkerhets-, tillgänglighets- och svarsklausulerna överens med hur "kritiska" du säger att de är?
Kontrollera sekretess- och plattformsskyldigheter: Är deras villkor för datahantering och underbiträden förenliga med era åtaganden gentemot spelare, plattformar och tillsynsmyndigheter?
Titta på recensioner och förnyelser: Diskuteras prestanda och incidenter explicit, och är dessa diskussioner synliga i ert ISMS?

Om svaren är oklara har du hittat ett gap mellan risk och kontrakt. ISMS.online hjälper dig att täppa till det gapet genom att länka leverantörsregister, risker, bedömningar, granskningar och dokument, så att du kan visa en tydlig kedja från "vi identifierade denna risk" till "vi ändrade hur vi köper och driver tjänsten" och "vi kontrollerar om den fortfarande är acceptabel". Det är den kedjan som externa granskare letar efter när de avgör om A.5.21 verkligen är inbäddad eller bara beskrivs i policyuttalanden.

Hur kan en ISMS-plattform göra A.5.21 användbar för teknik-, säkerhets- och live-operationsteam?

En ISMS-plattform gör A.5.21 praktiskt genomförbar genom att omvandla risk i leveranskedjan till en gemensam uppsättning rutiner som passar in i hur era team redan bygger och driver spel. Istället för en separat "efterlevnadsprocess" får ni en uppsättning skyddsräcken som visas vid de punkter där beslut fattas.

Hur ser detta ut för olika lag i praktiken?

Producenter och produktchefer: kan se om en leverantör redan finns i inventeringen och vilken nivå den är innan man binder sig till ett nytt beroende.
Ingenjörer och live-operationer: kan följa en välbekant checklista för A.5.21-bedömningar istället för att gissa vilka "säkerhetsbehov" som finns utifrån dem.
Säkerhets- och riskteam: kan upprätthålla ett arbetsflöde för leverantörsrisk över moln, betalningar, SDK:er och driftsverktyg, med tydliga utlösare för djupare due diligence.
Juridik och upphandling: ha tillgång till klausulmönster och tidigare beslut, så att de inte behöver omförhandla från grunden varje gång.
Ledarskap: kan se vilka leverantörer som ligger till grund för viktiga tjänster eller regioner, vilka som har öppna åtgärder och hur leverantörsproblem har bidragit till incidenter eller tillbud.

När en extern revision, plattformsgranskning eller större incident inkommer, driver samma register fokuserade bevispaket och förbättringar efter incidenten istället för tidskrävande arkeologi.

Hur hjälper ISMS.online dig att integrera A.5.21 i ett integrerat system i Annex L-stil?

Eftersom ISMS.online är byggt kring principerna i bilaga L kan leverantörsstyrning återanvändas inom:

Säkerhet: ISO 27001 och relaterade ramverk.
Sekretess: ISO 27701, GDPR och andra regionala lagar.
Kontinuitet: ISO 22301 och skyldigheter avseende motståndskraft (inklusive NIS 2- och DORA-koncept där så är relevant).
Framväxande AI-styrning: i takt med att AI-drivna tjänster och modeller blir reglerade.

Leverantörsposter, riskbedömningar, kontroller, incidenter, kontrakt och granskningsanteckningar finns på ett ställe, kopplade till ert centrala riskregister och tillämplighetsförklaring. Det innebär att ni tänker en gång och tillämpar det många gånger, snarare än att köra separata, inkonsekventa processer inom varje domän.

För er organisation blir resultatet att risken i IKT-leveranskedjan blir en del av hur ni designar, levererar och driver spel varje vecka. Om ni vill testa om det stämmer idag, ställ en enkel fråga: ”Kan någon senior ingenjör eller producent förklara vilka leverantörer som är nivå 1 och hur de granskas?” Om svaret är nej, är det ett av de snabbaste sätten att anpassa vad team gör till vad era certifikat anger att integrera A.5.21 fullt ut i en ISMS-plattform som ISMS.online.

ISO 27001 A.5.21 – Säkerhet i IKT-leveranskedjan för leverantörer av spelteknik