Att hantera tredjepartsrisker i ett GRC-ramverk kräver fyra grundpelare: en policy med styrelsegodkännande, ett maskinläsbart leverantörsregister med riskklassning, due diligence med bindande kontraktsklausuler inklusive exitstrategi, och löpande övervakning i stället för årliga stickprov. Utan alla fyra blir programmet ett dokument i en pärm, inte ett skydd mot verkliga driftstörningar.
Kort sagt:
- Tredjepartsrisker kräver en riskklassificering och maskinläsbart leverantörsregister för att undvika att programmet blir en tom formalitet.
- Regelverket DORA ställer krav på ett standardiserat, maskinläsbart register med obligatoriska kontraktsklausuler och exitstrategier för kritiska funktioner.
- Löpande övervakning som flaggar SLA-brister och säkerhetsincidenter är avgörande för att identifiera problem i tid, medan exitövningar bör genomföras minst årligen.
- Manuella processer som Excel fungerar för få leverantörer, men saknar spårbarhet och automatiska varningar, vilket kan bli en risk vid större volym och tillsyn.
- Effektivt tredjepartsriskarbete kräver samordning mellan juridik och säkerhet via verktyg som Trustview för att bygga ett hållbart lednings- och kontrollsystem.
Innehållsförteckning
- Vad är tredjepartsrisker i GRC och varför hör de ihop?
- Steg för steg: bygg ett riskbaserat tredjepartsriskprogram
- Styrning, roller och ansvar i GRC för tredjepartsrisker
- Regulatoriska krav: DORA, NIS2 och ISO 27001
- Onboarding, löpande övervakning och exitövning i praktiken
- Excel eller GRC-plattform: när räcker manuella processer?
- Evertrusts perspektiv: därför krävs juridisk och operativ samordning
- Så kan Evertrust stötta ditt tredjepartsriskarbete
- Källor
- Vanliga frågor
Vad är tredjepartsrisker i GRC och varför hör de ihop?
Tredjepartsrisk handlar om skadan en leverantör, molntjänst eller underkonsult kan orsaka din organisation. Det spänner från dataintrång hos en betalningsleverantör till ett driftstopp när ett kritiskt IT-system slutar fungera. I ett GRC-ramverk (governance, risk och compliance) knyts denna risk ihop med informationssäkerhet, dataskydd och regelefterlevnad i stället för att hanteras som en isolerad inköpsfråga.
Skälet är enkelt: en leverantör som läcker personuppgifter skapar samtidigt ett GDPR-ärende, en säkerhetsincident och ofta ett kontraktsbrott. Behandlar man dessa som tre separata processer dubbelarbetar man varje gång något går fel. En samordnad GRC-struktur gör att dokumentation om en leverantör kan återanvändas för flera regelverk samtidigt, vilket DevStrategies beskriver som en förutsättning för att fånga även indirekta beroenden längre ner i leverantörskedjan.
Steg för steg: bygg ett riskbaserat tredjepartsriskprogram
Ett program som faktiskt fungerar byggs i en bestämd ordning. Hoppar man över ett steg, till exempel klassificering före onboarding, hamnar kritiska leverantörer i samma facila process som en kontorsmaterialleverantör.
- Formulera policy och säkra styrelsegodkännande. Policyn ska definiera vad som räknas som tredjepartsrisk, vem som äger processen och vilka mandat inköp respektive säkerhet har att stoppa ett avtal.
- Bygg leverantörsregistret. Registret måste vara maskinläsbart och innehålla de fält DORA:s ITS-format kräver för kritiska ICT-funktioner: kontraktsomfattning, underleverantörer, plats för datalagring och kritikalitetsnivå.
- Skapa riskklassificeringen. Dela in leverantörer i minst tre nivåer utifrån vilken skada ett avbrott eller intrång skulle orsaka, inte utifrån kontraktsvärde.
- Sätt due diligence-krav vid onboarding. Innan avtal skrivs ska säkerhetsfrågeformulär, referenskontroller och granskning av underleverantörskedjan vara klara.
Registret bör innehålla åtminstone dessa uppgifter för varje leverantör:
- Kontraktspart, avtalstyp och löptid
- Kritikalitetsnivå och vilken affärsprocess leverantören stödjer
- Var data lagras och behandlas geografiskt
- Underleverantörer och fjärde-partsberoenden
- Ansvarig kontaktperson internt och externt
- Datum för senaste säkerhetsgranskning
Proffstips: Bygg registret i ett verktyg som kan exportera direkt till DORA:s rapporteringsformat från start. Att migrera ett Excel-ark till strukturerad data under tidspress inför en tillsyn är betydligt dyrare än att göra rätt från dag ett.
Styrning, roller och ansvar i GRC för tredjepartsrisker
Styrelsen bär det yttersta ansvaret för att godkänna riskaptit och strategi för tredjepartsrisk, inte bara ta emot en årsrapport. Ledningen ansvarar för att policyn faktiskt tillämpas i den dagliga verksamheten, medan operativa team sköter granskning och uppföljning.
En tydlig fördelning av ansvar minskar risken att kritiska leverantörer glider mellan stolarna:
- Styrelsen: godkänner riskaptit, policy och större outsourcingbeslut för kritiska funktioner.
- Ledningsgrupp/CISO: äger metodiken för riskklassificering och eskalerar avvikelser till styrelsen.
- Inköp: driver onboarding och kontraktsförhandling enligt fastställda krav.
- Säkerhets- och complianceansvariga: utför due diligence, löpande granskning och incidentuppföljning.
- Verksamhetsägare: rapporterar operativa avvikelser och SLA-brott till riskfunktionen.
Rapporteringsfrekvensen bör spegla kritikalitet: kvartalsvis genomgång för högriskleverantörer, årlig för lågriskleverantörer, och omedelbar eskalering vid SLA-brott eller säkerhetsincident oavsett klassning.
Regulatoriska krav: DORA, NIS2 och ISO 27001
DORA är den förordning som mest konkret formar hur tredjepartsrisk ska hanteras. Den gäller direkt i alla EU-länder och ställer krav på finansiella entiteter kring register, incidentrapportering, testning och tredjepartshantering sedan den 17 januari 2025.
Kärnan i kraven finns i artikel 28, som föreskriver ett maskinläsbart register över alla ICT-tredjepartsarrangemang, obligatoriska kontraktsklausuler för kritiska funktioner och dokumenterade exitstrategier. Registret ska följa ett fastställt ITS-format, inte ett fritt Excel-upplägg.
DORA:s krav på maskinläsbarhet och standardiserade fält skapar samtidigt förutsättningar för automatiserad koncentrationsanalys, alltså att upptäcka om flera kritiska funktioner vilar på samma molnleverantör.
NIS2 och ISO/IEC 27001 kompletterar snarare än konkurrerar med DORA. Kontroll 5.19 i ISO 27001, som handlar om leverantörskontroller, går att använda direkt som operativt ramverk för att möta DORA:s krav praktiskt, medan NIS2 breddar kraven till fler sektorer utanför finans. Praktiska konsekvenser att planera för:
- Registerdata måste kunna exporteras i strukturerat format vid tillsyn.
- Kontrakt för kritiska funktioner måste innehålla revisionsrätt och rätt till incidentrapportering.
- Exitstrategier ska vara dokumenterade, inte bara nämnda som avsikt.
Onboarding, löpande övervakning och exitövning i praktiken
Due diligence före avtal avgör hur mycket arbete som väntar efteråt. En grundlig granskning täcker fyra områden samtidigt, inte ett i taget:
- Juridiskt: ägarstruktur, tvistehistorik och regelefterlevnad i leverantörens hemland.
- Säkerhet: certifieringar, senaste penetrationstest och incidenthistorik.
- Kontinuitet: dokumenterad katastrofplan och testad återställningstid.
- Leveranskedja: vilka underleverantörer och fjärdepartsberoenden som finns bakom huvudleverantören.
Den fjärde punkten missas ofta. DevStrategies påpekar att tredjepartsriskhantering måste omfatta indirekta beroenden, eftersom ett avbrott hos en underleverantör slår igenom lika hårt som ett avbrott hos huvudleverantören.
Löpande övervakning ersätter den årliga granskningen med kontinuerliga signaler: SLA-avvikelser, utgångna certifikat, negativa nyheter om leverantören och faktiska säkerhetsincidenter. Ett system som flaggar dessa automatiskt fångar problem veckor före nästa schemalagda granskning.
Exitövningar är den del som oftast hoppas över helt, trots att den är avgörande. Omförhandling av stora molnkontrakt kan ta flera månader, och full migration av ett kritiskt system kan i värsta fall kräva en längre tidsperiod beroende på systemets komplexitet.
Proffstips: Testa exitplanen för minst en kritisk leverantör per år, precis som du testar en katastrofplan. Ett papper som aldrig testats är en gissning, inte en plan.
Excel eller GRC-plattform: när räcker manuella processer?
Ett kalkylblad fungerar för tio leverantörer. Vid femtio blir det ohanterligt, och vid tillsyn blir det ett bevis på bristande spårbarhet snarare än ett register. Stratsys beskriver hur ett samlat GRC-ramverk minskar fragmenteringen som uppstår när risk, säkerhet och tredjepartsrisk hanteras i separata verktyg.
En plattform ger tre saker Excel aldrig kan leverera fullt ut:
- Automatiska varningar vid utgångna certifikat eller kontrakt.
- Spårbar historik för varje bedömning, redo att visas upp vid tillsyn.
- Direkt koppling mellan leverantörsregister och riskregister, så en incident automatiskt syns i helhetsbilden.
Budgeten bör prioritera integrationsmöjligheter mot befintliga system för inköp och säkerhet, inte enbart antal funktioner i gränssnittet.
Evertrusts perspektiv: därför krävs juridisk och operativ samordning
Det vanligaste misstaget vi ser är att tredjepartsrisk hanteras av juridik och IT-säkerhet i parallella spår som aldrig möts. Kontraktsklausulerna skrivs utan koppling till vad säkerhetsteamet faktiskt kan verifiera, och registret blir en pappersövning.
Extern rådgivning ger störst effekt precis i det gapet, när en organisation redan har ett register men saknar juridisk skärpa i kontraktsklausulerna eller en testad exitplan. Ett pilotprojekt bör starta smalt: ta fem kritiska leverantörer, kör hela cykeln från klassificering till exitövning, och skala sedan upp modellen på resten av registret.
— Jesper
Så kan Evertrust stötta ditt tredjepartsriskarbete
Vi arbetar löpande med organisationer som behöver bygga eller stärka sitt tredjepartsriskprogram utan att det stannar vid ett policydokument. Det handlar om att koppla ihop juridisk kravställning med operativ riskbedömning, från GAP-analys till färdig kontraktsmall.
Genom rollen som externt dataskyddsombud får du löpande stöd i att bedöma leverantörer ur ett dataskyddsperspektiv, medan en DPIA görs där tredjepartsrisken kräver djupare analys. För organisationer som redan har en process men behöver testa den finns Trustview, plattformen som samlar leverantörsregister, riskklassning och dokumentation i ett gemensamt GRC-system. Vill du se var luckor faktiskt ligger, kan en workshop bokas för att gå igenom ett urval av kritiska leverantörskontrakt och identifiera vad som saknas innan nästa tillsyn eller revision.
Källor
Läs mer om DORA-kraven för finanssektorn och om den svenska lagförslaget för DORA för nationell kontext.
- DORA: Digital operativ motståndskraft för svenska finansbolag | CyberKlar
- NIS2 och DORA omdefinierar europeisk regelefterlevnad | Clarysec
- Tredjepartsriskhantering | DevStrategies
Vanliga frågor
Vad menas med tredjepartsrisker i GRC?
Det är risken en leverantör eller underleverantör utsätter organisationen för, hanterad som en integrerad del av styrning, riskhantering och regelefterlevnad snarare än som en separat inköpsfråga.
Vilka krav ställer DORA på tredjepartsregister?
DORA kräver ett maskinläsbart register över alla ICT-tredjepartsarrangemang enligt ett fastställt ITS-format, med obligatoriska kontraktsklausuler och dokumenterade exitstrategier för kritiska funktioner.
Hur ofta ska leverantörer granskas?
Högriskleverantörer bör granskas löpande med regelbunden rapportering, medan lågriskleverantörer kan granskas årligen, med omedelbar eskalering vid SLA-brott eller incident.
Räcker Excel för att hantera tredjepartsrisk?
Excel fungerar för ett litet antal leverantörer men saknar spårbarhet och automatiska varningar, vilket blir en svaghet vid tillsyn när leverantörsantalet växer.
Hur hjälper Evertrust organisationer med tredjepartsrisk?
Evertrust kombinerar juridisk rådgivning, externt dataskyddsombud och DPIA-stöd med praktisk implementering via Trustview för att bygga ett fungerande tredjepartsriskprogram.
