Nej, er befintliga ISO 27001-certifiering gör er inte automatiskt DORA-compliant
ISO 27001 är en av de mest erkända standarderna inom informationssäkerhet. Men en certifiering eller hög efterlevnadsgrad räcker inte för att uppnå DORA-kraven. I denna artikel presenterar vi vad som faktiskt saknas.
Många organisationer som arbetat hårt för att uppnå ISO 27001-certifiering möter nu en ny fråga: räcker det som vi har byggt för att även uppfylla DORA? Svaret är att certifieringen ger en solid grund men räcker inte hela vägen. DORA ställer sektorsspecifika krav på finansiella aktörer som går längre än vad ISO 27001-standarden täcker, och de skillnaderna behöver hanteras metodiskt inför nästa revision.
Den här artikeln beskriver var gapen vanligtvis uppstår, vad som konkret behöver anpassas i ert ledningssystem, och hur ni strukturerar arbetet för att kunna bevisa efterlevnad mot båda regelverken.
ISO 27001 är en bra start, men inte ett fullständigt svar
ISO 27001 definierar krav på ett ledningssystem för informationssäkerhet (ISMS) och ger organisationer en beprövad struktur för riskhantering, kontrollimplementation och kontinuerlig förbättring. Ramverket täcker informationssäkerhetens pelare: konfidentialitet, integritet/riktighet och tillgänglighet och det är just den bredd som gör det värdefullt som bas.
Men DORA, som trädde i kraft den 17 januari 2025, är sektorspecifik lagstiftning med rättslig bindning för finansiella entiteter i EU. Förordningen ställer bindande krav på flera områden som ISO 27001 inte täcker: styrelsens direkta ansvar för IKT-risker, specifika tidsramar för incidentrapportering till tillsynsmyndigheter, obligatorisk hotbildsbaserad penetrationstestning (TLPT) för utpekade aktörer samt detaljerade kontraktuella minimikrav för IKT-tredjepartsleverantörer.
ISO 27001-certifiering är med andra ord ett starkt argument inför en DORA-granskning, men det ersätter inte DORA-efterlevnad.
De fem pelarna i DORA och var ISO 27001 lämnar glapp
DORA bygger på fem strukturella pelare. Nedan beskrivs respektive pelare och de vanligaste gapen för en ISO 27001-certifierad organisation.
IKT-riskhantering
ISO 27001 kräver riskidentifiering, riskbehandling och en riskhanteringsprocess. DORA specificerar dock att riskhanteringsramverket ska vara dokumenterat på ett sätt som gör det direkt adresserbart för styrelsen, med tydliga risktoleransnivåer, specificerade nyckeltal och en IKT-risktoleranspolicy som godkänns på lednings- och styrelsenivå.
Gap: Om er befintliga riskhantering lever i ett ISMS utan formell styrelsegodkänd IKT-risktolerans behöver detta formaliseras och dokumenteras separat.
Incidentrapportering
ISO 27001 (Annex A, kontroll 5.24–5.28) kräver att ni hanterar säkerhetsincidenter, men ger inga bindande tidsramar för extern rapportering. DORA kräver att betydande IKT-incidenter rapporteras till behörig myndighet inom strikta tidsgränser: initial anmälan inom 24 timmar, mellanrapport inom 72 timmar, och slutrapport inom en månad.
Gap: Er incidenthanteringsprocess behöver anpassas med klassificeringskriterier för vad som utgör en “betydande IKT-incident” enligt DORA:s definition, samt (automatiserade) rutiner som möjliggör rapportering inom dessa tidsramar.
Testning av digital operativ motståndskraft
ISO 27001 kräver sårbarhetshantering men föreskriver inte specifika testmetoder. DORA inför ett strukturerat testprogram som inkluderar grundläggande testning för alla aktörer, exempelvis, sårbarhetsbedömningar, nätverkssäkerhetstester, penetrationstester, scenarier för affärskontinuitet, samt hotbildsbaserad penetrationstestning (TLPT) minst vart tredje år för de aktörer som identifieras som signifikanta av behörig myndighet.
Gap: Era testplaner behöver utvidgas med ett formellt testprogram i enlighet med DORA (och om tillämpligt TLPT-beredskapen) behöver kartläggas och dokumenteras.
IKT-tredjepartsriskhantering
Detta är ett av de mest uttalade gapområdena. ISO 27001 kräver att ni bedömer leverantörers säkerhet, men DORA specificerar exakta kontraktuella krav för alla IKT-avtal som stödjer viktiga eller kritiska funktioner. Kontrakten ska bland annat innehålla rätt till revision, krav på säkerhetsnivåer, beskrivning av stödda tjänster, SLA-krav för tillgänglighet samt exitstrategier.
Gap: Befintliga IKT-leverantörsavtal behöver ses över mot DORA:s kontraktuella minimikrav, och ett informationsregister (Register of Information) behöver upprättas för alla IKT-tredjepartsleverantörer.
Informationsdelning
Den femte pelaren i DORA, som inte är obligatorisk, kräver att finansiella aktörer deltar i arrangemang för informationsdelning om cyberhot. ISO 27001 berör inte detta explicit.
Gap: Identifiera lämpliga sektoriella informationsdelningsarrangemang och dokumentera ert deltagande eller ert ställningstagande kring deltagande.
Från gapanalys till en DORA-compliant ISMS
Den praktiska vägen framåt består av tre faser.
Fas 1: Genomför en strukturerad DORA-gapanalys
Mappa era befintliga ISO 27001-kontroller mot DORA:s krav pilare för pilare. Utgå från att ert ISMS är ett underlag, inte ett slutresultat. Dokumentera var nuläget är otillräckligt, var dokumentation saknas, och var processer behöver skärpas eller kompletteras.
En gapanalys bör resultera i en prioriterad åtgärdsplan — inte en generisk lista utan konkreta ägarskap, tidsplaner och tydliga definitioner av vad som räknas som tillräcklig evidens inför en revision.
Fas 2: Uppdatera styrdokument och processer
De vanligaste dokumenten som behöver uppdateras eller skapas:
- IKT-risktoleranspolicy – formellt godkänd av styrelsen
- Incidentklassificeringsprocedur – med DORA-specifika kriterier och rapporteringstidsramar
- Teststrategi – med testtyper, frekvens och ansvar
- Leverantörsregister (Register of Information) – kategoriserat per kritikalitet
- Uppdaterade IKT-avtal med DORA-obligatoriska kontraktuella klausuler
- Business continuity och disaster recovery-planer – validerade och testade mot DORA-scenarion
Om era befintliga dokument är kopplade till ISO 27001-strukturen kan de flesta av dessa integreras i ISMS:et som kompletterande procedurer eller bilagor, vilket minimerar dubbelarbete.
Fas 3: Bygg evidens för dubbel efterlevnad
ISO 27001-certifieringen kräver att ni kan bevisa att kontrollerna fungerar. DORA kräver att ni kan bevisa att de finansiella enhetsspecifika kraven uppfylls. De två bevisbörderrana är kompletterande men inte identiska.
Skapa en kontrollmappning som visar var ett och samma kontrollbevis täcker båda regelverken, och var separata bevis krävs. Det minskar revisionsarbetsbördan avsevärt och gör er beredda för både ISO-revisorn och en tillsynsmyndighetsgranskning.
Styrelsens roll: ett krav som DORA skärper
En av de tydligaste skillnaderna mot ISO 27001 är styrelseansvaret. Copla:s analys från 2026 konstaterar att ISO 27001 förväntar sig att ledningen etablerar och övervakar ISMS:et, medan DORA gör styrelseledamöterna personligt ansvariga för IKT-riskhanteringen.
Det innebär att ni behöver dokumentera att styrelsen:
- Har godkänt strategin för digital motståndskraft
- Mottar regelbunden rapportering om IKT-risker och incidenter
- Besitter tillräcklig kompetens inom IKT-riskhantering, alternativt säkerställer att rätt kompetens finns tillgänglig
Om dessa formaliteter saknas i dag, behöver de inrättas och dokumenteras innan nästa revision, helst med protokoll och rollbeskrivningar som direkt refererar till DORA-kraven.
Vanliga misstag att undvika
Att behandla ISO 27001 och DORA som separata projekt.
Det ökar kostnaden, skapar inkonsistens och riskerar att evidens för det ena regelverket motverkar det andra. Integrera kraven i ett och samma styrningssystem.
Att underskatta tredjepartsarbetet.
Register of Information och uppdaterade avtal kräver tid, intern koordination och ibland omförhandling med leverantörer. Starta tidigt.
Att anta att sårbarhetsskanningar räcker som testning.
DORA:s krav på resiliensprovning är bredare. Etablera ett formellt testprogram med dokumenterade resultat.
Att inte förankra arbetet hos styrelsen.
Styrelseprotokollet som bekräftar godkänd risktolerans och resiliensstrategi är ett centralt bevis för DORA-efterlevnad.
Inför nästa ISO 27001-revision
När revisorn går igenom era kontroller och er efterlevnad av standarden, bör ni kunna presentera ett ISMS som inte bara uppfyller Annex A utan även visar hur DORA-specifika krav är integrerade i er styrning. Det handlar inte om att duplicera dokumentation — det handlar om att visa att er riskhanteringsstruktur är tillräckligt mogen för att hantera sektorsspecifik reglering utan att tappa sammanhang.
En revisor som ser ett välstrukturerat ISMS med tydlig DORA-mappning, bevisad incidentklassificeringsprocess och ett dokumenterat testprogram har ett starkt underlag att arbeta med. Det gör revisionen enklare och utfallet mer förutsägbart.
5 åtgärder att ta direkt
- Genomför en strukturerad DORA-gapanalys mot era befintliga ISO 27001-kontroller
- Formalisera en IKT-risktoleranspolicy som godkänns av styrelsen
- Uppdatera er incidenthanteringsprocess med DORA:s rapporteringstidsramar
- Se över alla IKT-leverantörsavtal mot DORA:s kontraktuella minimikrav
- Etablera ett formellt resiliensteststrategi med dokumenterade testplaner
För organisationer som vill ha stöd med detta arbete från gapanalys och dokumentutveckling till revisionsförberedelse erbjuder Seadot tjänster inom DORA-implementering och internrevision, ISO 27001-rådgivning och IT Risk & Assurance. Målet är ett integrerat ledningssystem som håller under granskning, inte ett som ser bra ut på papper men brister i praktiken.