Hur fördelar man ansvaret? Hur undviker man att DORA-arbetet lever i ett kalkylark som ingen uppdaterar? Hur ser man till att ledningen och styrelsen kan visa upp vad som faktiskt görs?
Det är de frågorna den här artikeln handlar om.
DORA är inte ett projekt — det är ett styrningsprogram
Den vanligaste fallgropen är att behandla DORA-efterlevnad som ett engångsprojekt med ett slutdatum. Det är förståeligt: regelverket trädde i kraft vid ett specifikt datum, och många organisationer mobiliserade för att "bli klara" till januari 2025.
Men DORA är konstruerat som ett löpande styrningsprogram. Kraven på incidentrapportering, tredjepartsövervakning och informationsregistret är inte bockar man kryssar i en gång — de är processer som måste fungera kontinuerligt, uppdateras när förutsättningarna förändras och kunna verifieras av tillsynsmyndigheten när som helst.
Det betyder att organisationer som byggde sin DORA-efterlevnad som ett projekt nu ofta sitter med ett resultat som inte är hållbart. Dokumentationen finns, men ingen äger den. Registret skapades, men uppdateras inte. Incidentprocessen är beskriven, men inte testad.
De fem pelarna — och var arbetet faktiskt fastnar
DORA är uppbyggt kring fem områden: ICT-riskhantering, incidentrapportering, resilienstestar, tredjepartsrisk och informationsdelning. De flesta organisationer har en rimlig bild av vad varje område kräver. Det som är svårare är att få dem att hänga ihop i praktiken.
Det vi ser organisationer fastna på är framför allt tre saker.
Tredjepartsregistret. Informationsregistret (Register of Information) är tekniskt sett ett dokumentationskrav, men i praktiken är det ett datakvalitetsproblem. Registret ska spegla verkligheten — vilka leverantörer som används, vilka funktioner de stödjer, hur beroendena ser ut. Det kräver att inköp, IT, juridik och verksamheten talar med varandra och att informationen hålls uppdaterad när avtal tecknas, ändras eller avslutas. Det fungerar inte som en årlig övning.
Incidentklassificering. DORA kräver att organisationen kan avgöra om en incident är "major" inom mycket snäva tidsfönster — den initiala notifieringen ska ske inom fyra timmar från klassificering. Det förutsätter att klassificeringskriterierna är kända, att processen är definierad i förväg och att rätt personer kan aktiveras snabbt. En process som bara finns i ett dokument håller inte under press.
Ansvarsfördelning. DORA lägger ett tydligt ansvar på ledningsnivå. Det räcker inte att compliance-funktionen äger programmet — ledningen ska kunna visa att de förstår och styr ICT-riskerna. Det ställer krav på rapporteringsstrukturer, eskaleringsvägar och hur information presenteras uppåt i organisationen.
Vad ett strukturerat program faktiskt innebär
Ett hållbart DORA-program har tre egenskaper som skiljer det från ett engångsprojekt.
Tydligt ägarskap. Varje kravområde har en namngiven ägare med mandat att driva arbetet. Det gäller inte bara compliance-funktionen — tredjepartsregistret ägs ofta bäst av inköp eller IT, incidentprocessen av säkerhetsfunktionen, med compliance som koordinerande part.
Processer kopplade till händelser, inte till kalendern. Uppdateringar av registret sker när avtal tecknas, inte en gång om året. Incidentprocessen aktiveras av faktiska händelser, inte av en årsrapport. Det kräver att DORA-kraven är inbyggda i befintliga arbetsflöden, inte parallella med dem.
Dokumentation som kan visas upp. Tillsynsmyndigheten kan begära att se hur organisationen arbetar med DORA-efterlevnad. Det innebär att dokumentationen måste vara aktuell, spårbar och begriplig — inte bara existerande. En revisionslogg som visar vem som ändrade vad och när är mer värdefull än ett perfekt dokument utan historik.
Vad ledningen behöver kunna visa
En fråga som återkommer i våra kunddialoger är hur man presenterar DORA-status för styrelsen. Tillsynsmyndigheten förväntar sig att ledningen aktivt styr ICT-riskerna, inte bara delegerar dem. Det innebär att styrelsen behöver en löpande bild av efterlevnadsstatus, öppna åtgärdspunkter och hur organisationen hanterar sina kritiska leverantörsberoenden.
Det är svårt att leverera från ett kalkylark. Det kräver en struktur som producerar den bilden kontinuerligt, inte bara inför ett styrelsemöte.
Vill du se hur ett strukturerat DORA-program ser ut i praktiken?
Hy5 operationaliserar DORA-efterlevnad i ett sammanhållet system — från tredjepartsregistret och incidenthantering till löpande statusrapportering för ledning och styrelse. Används av svenska finansiella organisationer för att hantera DORA utan parallella manuella processer.
Boka en demonstration av hur Hy5 strukturerar DORA-efterlevnad
Hy5 kan drastiskt öka effektivitet och precision för compliancearbete.
