DORA och tredjepartsrisker: vad kräver regelverket egentligen?

En fråga som återkommer i våra kunddialoger är inte "måste vi hantera tredjepartsrisker?" utan "vad innebär det i praktiken, och hur strukturerar vi det utan att det blir ett separat projekt som ingen äger?" De flesta organisationer som kommer till oss vet att de har leverantörsberoenden att hantera. Frågan är hur — och vad regelverket faktiskt kräver när man läser det noggrant.

DORA:s krav på tredjepartshantering är det område som skapar mest operationell förvirring. Inte för att kraven är otydliga, utan för att de förutsätter en kontinuitet i arbetet som de flesta organisationer inte är vana vid.

Vad räknas som en ICT-leverantör enligt DORA?

DORA gäller alla avtal med tredjepartsleverantörer av ICT-tjänster — inte bara de uppenbara, som molntjänster och datacenter, utan även mjukvaruleverantörer, telekomoperatörer och i vissa fall underleverantörer i leverantörskedjan.

Det som avgör hur noggrant en leverantör behöver hanteras är om tjänsten stödjer en kritisk eller viktig funktion i organisationen. Den klassificeringen är inte trivial. Den påverkar direkt vilka avtalskrav som gäller, hur djup due diligence som krävs och hur leverantören ska hanteras i informationsregistret.

En vanlig missuppfattning är att klassificeringen är en engångsbedömning. I praktiken behöver den ses över löpande — en leverantör som tidigare hanterade en stödprocess kan bli kritisk om organisationens beroende av tjänsten förändras.

Informationsregistret: ett levande dokument, inte en årsrapport

DORA kräver att finansiella företag upprättar och underhåller ett register över alla avtalade ICT-tjänster — det som kallas register of information (RoI). Registret ska innehålla uppgifter om leverantörens identitet, vilka tjänster som levereras, vilka funktioner i organisationen som berörs och om tjänsten klassificeras som kritisk eller viktig.

Det är här systemdesignen spelar roll. Registret behöver vara ett levande dokument, inte en fil som uppdateras inför den årliga inlämningen. Det kräver att uppdateringar triggas automatiskt vid kontraktshändelser — nya avtal, förlängningar, ändringar — och att det finns tydligt ägarskap för varje post.

I praktiken är detta ett datakvalitetsproblem lika mycket som ett regelefterlevnadsproblem. Registret involverar flera avdelningar: inköp, IT, juridik, risk. Utan en strukturerad process för insamling och validering blir det snabbt inkonsekvent.

Koncentrationsrisk: vad tillsynsmyndigheterna faktiskt letar efter

DORA adresserar explicit koncentrationsrisk — det vill säga risken att en organisation är alltför beroende av ett fåtal ICT-leverantörer, eller att hela den finansiella sektorn är beroende av samma kritiska aktörer.

På organisationsnivå innebär det att finansiella företag behöver kartlägga sina beroenden och kunna visa att de förstår var koncentrationer finns. Det räcker inte att ha en lista över leverantörer. Tillsynsmyndigheten vill se att organisationen aktivt analyserar vad som händer om en kritisk leverantör fallerar.

Det är ett område där tillsynsmyndigheterna ännu inte har gett fullständig vägledning om exakt hur bedömningen ska dokumenteras. Det rådet vi ger är att börja med att kartlägga vilka leverantörer som stödjer kritiska funktioner och analysera substituerbarhet — hur snabbt och till vilken kostnad kan tjänsten ersättas?

Löpande övervakning kontra periodisk genomgång

Missuppfattning: DORA kräver en grundlig leverantörsgranskning en gång om året.

Verkligheten: DORA kräver löpande övervakning av tredjepartsleverantörer. Det innebär att förändringar i en leverantörs säkerhetsläge, finansiella stabilitet eller underleverantörsstruktur behöver fångas upp kontinuerligt — inte vid nästa schemalagda genomgång.

Det ställer krav på hur organisationen hämtar och bearbetar information om sina leverantörer. Manuella processer håller inte. En leverantör som drabbas av ett säkerhetsintrång i dag kan vara relevant för DORA:s incidentrapportering redan i morgon.

Exitstrategier: ett krav som ofta underskattas

För tjänster som stödjer kritiska eller viktiga funktioner kräver DORA att organisationen har en trovärdig exitstrategi. Det innebär en dokumenterad plan för hur tjänsten kan avslutas eller migreras om leverantören fallerar, om kvaliteten försämras eller om avtalet sägs upp.

En exitstrategi som bara existerar på papper uppfyller inte kravet. Tillsynsmyndigheten förväntar sig att planen är operationellt genomförbar — att organisationen faktiskt kan genomföra den inom rimlig tid utan att kritiska funktioner slås ut.

Vad det innebär för hur arbetet organiseras

Tredjepartshantering enligt DORA är inte ett projekt med ett slutdatum. Det är ett löpande styrningsprogram som kräver tydligt ägarskap, integrerade processer och dokumentation som håller vid en tillsynsgranskning.

Det vanligaste problemet vi ser är inte att organisationer saknar information om sina leverantörer — det är att informationen finns utspridd i kontrakt, kalkylblad och mejlkonversationer utan en sammanhållen struktur. Det är den strukturen DORA kräver.

Nästa steg med Hy5

Behöver din organisation ett strukturerat sätt att hantera DORA:s tredjepartskrav?

Hy5 underhåller ditt register of information kontinuerligt och kopplar leverantörsberoenden direkt till dina kritiska funktioner och compliance-status. Används av svenska finansiella organisationer för att operationalisera DORA utan manuell administration.

Boka en demonstration av Hy5:s tredjepartsregister

Hy5 kan drastiskt öka effektivitet och precision för compliancearbete.

DORA Compliance lösningar