DORA-testprogram: mappa tester mot ISO 27001

Det är februari 2026. Informationssäkerhetschefen på ett medelstort betalningsinstitut har ett styrelsemöte om två dagar, en uppföljande revision enligt ISO/IEC 27001:2022 om sex veckor och en tillsynsbegäran enligt DORA i regelefterlevnadsfunktionens inkorg.

Tillsynsmyndigheten efterfrågar inte en polerad cyberstrategi. Begäran är praktisk:

• Tillhandahåll ert testprogram för digital operativ resiliens 2026.
• Visa vilka tester som omfattar kritiska eller viktiga funktioner.
• Visa hur iakttagelser åtgärdas och omtestas.
• Tillhandahåll underlag för ledningsorganets tillsyn.
• Förklara hur IKT-tredjepartsleverantörer inkluderas.
• Tillhandahåll dokumentation för sårbarhetsbedömningar, scenariobaserade tester, prestanda- och kapacitetstestning samt penetrationstestning.

Informationssäkerhetschefen öppnar fyra mappar. Sårbarhetsskanningar finns i SOC:ens ärendehanteringssystem. Anteckningar från skrivbordsövningar ligger på en delad enhet. Resultat från belastningstester ägs av utvecklingsteamet. Penetrationstestrapporter finns i juridikfunktionens begränsade lagringsyta. Uppföljningen av åtgärder är uppdelad mellan Jira, e-post och ett kalkylblad som skapades inför förra årets ISO-revision.

Inget är fabricerat. Mycket är bra arbete. Men det är ännu inte ett styrt DORA-testprogram för digital operativ resiliens. Det är en samling tester.

Den skillnaden är viktig 2026. DORA gäller från den 17 januari 2025 och etablerar ett enhetligt EU-ramverk för digital operativ resiliens inom IKT-riskhantering, incidentrapportering, resiliensprovning, informationsdelning om cyberhot och sårbarheter, IKT-tredjepartsriskhantering, avtalskrav och tillsyn över kritiska IKT-tredjepartsleverantörer. Förordningen omfattar ett brett spektrum av finansiella entiteter, inklusive kreditinstitut, betalningsinstitut, värdepappersföretag, leverantörer av kryptotillgångstjänster, försäkringsföretag och andra reglerade entiteter. DORA fungerar också som den sektorsspecifika unionsrättsakten för finansiella entiteter som annars skulle omfattas av motsvarande cybersäkerhetsskyldigheter enligt NIS2.

Den praktiska frågan för styrelser, informationssäkerhetschefer, regelefterlevnadsansvariga och IKT-leverantörer är inte längre om testning sker. Frågan är om testningen är planerad, riskbaserad, styrkt med underlag, åtgärdad, granskad och återanvändbar över DORA och ISO/IEC 27001:2022.

Clarysecs operativa modell är byggd för just detta problem. Med Zenith Blueprint: En revisors 30-stegs färdplan, Clarysecs ISO-anpassade policysvit och Zenith Controls: Vägledning för tvärgående regelefterlevnad kan organisationer omvandla utspridda resiliensaktiviteter till en kontrollerad årlig testkatalog som uppfyller krav från tillsynsmyndigheter, revisorer, kunder och styrelser.

Varför DORA gör testning till en styrningsfråga

DORA är tydlig med ledningens ansvar. Article 5 lägger ansvaret för IKT-riskhantering på ledningsorganet. Article 6 kräver ett sunt, heltäckande och väldokumenterat ramverk för IKT-riskhantering som är integrerat i organisationens övergripande riskhanteringssystem. Article 4 tillför proportionalitet, vilket innebär att kraven ska tillämpas utifrån storlek, samlad riskprofil samt tjänsternas, aktiviteternas och verksamhetens art, skala och komplexitet.

Detta gör testning av digital operativ resiliens till mer än en teknisk uppgift. Den blir underlag för att ledningsorganet förstår risk, har godkänt en strategi, får meningsfull rapportering och driver åtgärdande.

ISO/IEC 27001:2022 använder en liknande ledningssystemlogik. Avsnitten 4.1 till 4.4 kräver att organisationen förstår kontext, intressenter, rättsliga och avtalsmässiga skyldigheter, omfattning, gränssnitt och beroenden. Avsnitten 5.1 till 5.3 kräver ledarskap, policyanpassning, resurser, kommunikation, tilldelat ansvar och rapportering till högsta ledningen. Avsnitt 6.1 kräver riskbedömning och riskbehandling för informationssäkerhet.

Ett DORA-testprogram bör därför koppla samman:

• Verksamhetstjänster och kritiska eller viktiga funktioner
• IKT-tillgångar, data och tredjepartsberoenden
• Riskbedömning, riskägare och riskbehandlingsplaner
• Testtyper, frekvens och utlösande händelser
• Auktorisation, oberoende och spelregler
• Iakttagelser, tidsfrister för åtgärder och omtestning
• Bevarande av underlag och åtkomstkontroll
• Ledningsrapportering och ständig förbättring

För mindre eller lägre riskutsatta finansiella entiteter ger Article 16 ett förenklat ramverk för IKT-riskhantering, men förenklat betyder inte informellt. Även skalade program behöver dokumenterad IKT-riskhantering, övervakning, resilienta system, identifiering av IKT-riskkällor och avvikelser, centrala IKT-tredjepartsberoenden, kontinuitets- och återställningsåtgärder, regelbunden testning och erfarenhetsåterföring.

Med andra ord belönar DORA inte testvolym. DORA belönar styrd, riskbaserad testning som visar resiliens för de tjänster som betyder mest.

Vad hör hemma i ett DORA-testprogram 2026?

Ett moget DORA-testprogram bör fungera som en årlig testkatalog. Det ska inte begränsas till ett årligt penetrationstest eller en bunt exporter från sårbarhetsskanningar. Det bör omfatta grundläggande och avancerade tester, planerade utifrån risk, tjänsternas kritikalitet, regulatoriska skyldigheter, leverantörsberoenden, större förändringar och tidigare iakttagelser.

DORA Article 24 etablerar testprogrammet för digital operativ resiliens. Article 25 beskriver flera typer av tester, inklusive sårbarhetsbedömningar och skanningar, analyser av öppen källkod, nätverkssäkerhetsbedömningar, gap-analyser, granskningar av fysisk säkerhet, frågeformulär, skanningslösningar, kodgranskningar där det är möjligt, scenariobaserade tester, kompatibilitetstestning, prestandatestning, end-to-end-testning och penetrationstestning. Article 26 lägger till hotbildsstyrd penetrationstestning för finansiella entiteter som identifieras av behöriga myndigheter.

För de flesta organisationer byggs den praktiska katalogen kring fyra testfamiljer.

Clarysecs Policy för säkerhetstestning och red teaming ger en stark policygrund för denna katalog:

“Typer av tester: Säkerhetstestningsprogrammet ska som minst omfatta: (a) sårbarhetsskanning, bestående av automatiserade veckovisa eller månatliga skanningar av nätverk och applikationer för att identifiera kända sårbarheter; (b) penetrationstestning, bestående av manuell djupgående testning av specifika system eller applikationer av kvalificerade testare för att identifiera komplexa svagheter; och (c) red team-övningar, bestående av scenariobaserade simuleringar av verkliga angrepp, inklusive social manipulation och andra taktiker, för att testa organisationens samlade detekterings- och responsförmåga.”

Samma policy kräver regelbunden schemaläggning:

“Testschema: Organisationen ska genomföra säkerhetstestning enligt ett regelbundet schema. Centrala internetexponerade system och kritiska interna applikationer ska genomgå penetrationstestning minst årligen. Högriskändringar, såsom driftsättning av ett nytt kritiskt system eller större uppgraderingar, kräver ad hoc-testning före och/eller kort efter att de tas i produktion.”

Detta är avgörande för DORA. En statisk årsplan räcker inte om entiteten driftsätter en ny betalningsgateway, migrerar ett centralt system till en molnmiljö, byter leverantör av hanterade tjänster eller lanserar ett nytt flöde för kundautentisering. Högriskändringar ska utlösa ytterligare testning.

Bygg den årliga testkatalogen som en enda källa till sanning

Det mest effektiva sättet att uppfylla DORA och ISO/IEC 27001:2022 är att skapa en kontrollerad årlig testkatalog. Den kan ligga i en GRC-plattform, ett ärendeflöde eller ett kontrollerat kalkylblad. Formatet är mindre viktigt än spårbarheten.

Varje test bör besvara fem revisionsfrågor:

1. Vilken tjänst, tillgång, leverantör, applikation eller process testades?
2. Vilken risk, skyldighet eller vilket kontrollkrav utlöste testet?
3. Vem auktoriserade och utförde testet?
4. Vilka iakttagelser identifierades, accepterades, åtgärdades eller sköts upp?
5. Vilket underlag visar att testet genomfördes och att utfallet granskades?

En praktisk katalog enligt Clarysecs modell innehåller dessa fält.

Clarysecs Policy för revision och övervakning av regelefterlevnad – SME ger en koncis styrningsregel som passar denna struktur:

“Varje revision ska ha definierad omfattning, mål, ansvarig personal och erforderligt underlag.”

Även om regeln är skriven för revisioner ska samma princip gälla för resiliensprovningar. Om en sårbarhetsskanning, skrivbordsövning, failover-simulering eller ett penetrationstest saknar definierad omfattning, mål, ägare och erforderligt underlag blir det svagt under både DORA- och ISO-revision.

Samma policy anger:

“Underlag ska bevaras i minst två år, eller längre om certifiering eller kundavtal kräver det.”

För DORA-reglerade finansiella entiteter och IKT-leverantörer bör två år betraktas som en miniminivå. Avtalsförpliktelser, tillsynsförväntningar, certifieringscykler och incidentutredningar kan kräva längre bevarande.

Mappa DORA-testtyper mot ISO 27001-underlag

Styrkan i ett integrerat program är att ett test kan uppfylla flera skyldigheter. Nyckeln är att tagga underlaget korrekt och koppla det till ISMS.

Zenith Blueprint förklarar detta i fasen Audit, Review & Improvement, Step 24:

“Din SoA bör vara förenlig med ditt Riskregister och din Riskbehandlingsplan. Dubbelkontrollera att varje kontroll som du valde som riskbehandling är markerad som "Tillämplig" i SoA.”

För ett DORA-testprogram blir testkatalogen bryggan mellan riskbehandling och operativt underlag. Tillämplighetsförklaringen ska inte säga att en kontroll är tillämplig samtidigt som testunderlaget ligger någon annanstans, omappat och utan styrning.

Den här tabellen hjälper en informationssäkerhetschef att besvara vd:ns vanliga fråga: “Räcker våra ISO-penetrationstester och sårbarhetsskanningar för DORA?”

Svaret är: de kan vara en del av DORA-efterlevnad, men bara om de är riskbaserade, kopplade till kritiska eller viktiga funktioner, styrda av policy, uppföljda genom åtgärder och rapporterade till ledningen.

Sårbarhetsbedömningar: kontinuerligt underlag, inte bara skanningsresultat

Sårbarhetsbedömning är ofta den enklaste testaktiviteten att genomföra och den enklaste att hantera fel. Många organisationer kan ta fram skanningsrapporter. Färre kan visa att skanningarna omfattar rätt tillgångar, prioriterar kritiska tjänster, leder till åtgärder i tid och matar in beslut om riskbehandling.

Clarysecs Policy för sårbarhets- och patchhantering – SME börjar med rätt mål:

“Identifiera och bedöma kända sårbarheter i alla IT-tillgångar på ett snabbt och konsekvent sätt”

För DORA stödjer detta identifiering av IKT-riskkällor, resilienta och uppdaterade system, övervakning, anomalidetektering och ständig förbättring. För ISO/IEC 27001:2022 mappar det direkt till 8.8 Hantering av tekniska sårbarheter, och det bygger även på 5.9 Förteckning över information och andra tillhörande tillgångar, 8.16 Övervakningsaktiviteter och 8.32 Ändringshantering.

En stark post för sårbarhetsbedömning bör innehålla:

• Ögonblicksbild av tillgångsförteckningen som användes för avgränsning
• Skanningsdatum, verktyg och autentiserad eller icke-autentiserad metod
• Undantag och verksamhetsmässig motivering
• Iakttagelser per allvarlighetsgrad, exploaterbarhet och verksamhetstjänst
• Mappning mot kritiska eller viktiga funktioner och datatyper
• Ärendereferenser och riskägare
• SLA för åtgärdande och förfallodatum
• Omtestningsresultat
• Undantag med godkännande av kvarstående risk

Zenith Controls positionerar 8.8 Hantering av tekniska sårbarheter som ett centralt underlagsområde för identifiering, bedömning, prioritering och uppföljning av åtgärder. Det visar också varför revisorer kommer att testa angränsande processer. Om tillgångsförteckningen är ofullständig är sårbarhetstäckningen ofullständig. Om ändringshantering kringgås kan patchdriftsättning skapa ny operativ risk. Om övervakningen är svag kan exploateringsförsök förbli oupptäckta.

Scenariotester: visa beslutsförmåga före den verkliga incidenten

Scenariotester är där operativ resiliens blir synlig för ledningen. En skrivbordsövning för ransomware, en simulering av avbrott i en molnregion, en övning för kompromettering av privilegierad åtkomst eller ett scenario för fel hos en kritisk IKT-leverantör kommer att avslöja svagheter som en skanning inte kan visa.

DORA Articles 17 till 20 kräver en formell livscykel för IKT-relaterade incidenter: upptäcka, hantera, underrätta, registrera, övervaka, behandla, följa upp, dokumentera rotorsak, åtgärda, klassificera allvarlighetsgrad, tilldela roller, eskalera allvarliga incidenter och rapportera genom föreskrivna steg. När kunders finansiella intressen påverkas ska kunder informeras utan onödigt dröjsmål.

NIS2 har liknande skyndsamhetskrav för entiteter inom sitt tillämpningsområde, inklusive tidig varning, anmälan, delrapportering och slutrapportering. För finansiella entiteter inom tillämpningsområdet är DORA den sektorsspecifika rättsakten för motsvarande skyldigheter avseende cybersäkerhetsriskhantering och rapportering. IKT-leverantörer, SaaS-plattformar, MSP:er och MSSP:er behöver fortfarande kontrollera om de direkt omfattas av NIS2 eller avtalsmässigt dras in i DORA-säkring av reglerade kunder.

Zenith Blueprint, fasen Controls in Action, Step 23, ger den praktiska underlagsmodellen:

“Välj en nyligen inträffad händelse eller genomför en skrivbordsövning för att validera din plan. Fånga och logga alla beslut, roller och all kommunikation (5.26), och uppdatera planen med erfarenhetsåterföring (5.27).”

Ett DORA-scenariotest bör producera granskningsbara poster, inte bara mötesanteckningar:

• Scenariobeskrivning och mål
• Deltagare och roller, inklusive juridik, kommunikation, IT, SOC, verksamhetsägare och leverantörskontakter
• Tidslinje över inspel och beslut
• Klassificeringsbeslut och analys av rapporteringströsklar
• Utkast till intern och extern kommunikation
• Åtgärder för bevarande av bevismaterial
• Erfarenhetsåterföring
• Åtgärdsägare och förfallodatum
• Uppdaterade incident-, kontinuitets- eller kommunikationsrutiner

Clarysecs Policy för verksamhetskontinuitet och katastrofåterställning – SME förstärker kravet på årlig testning:

“Organisationen ska testa både sin BCP- och DR-förmåga minst årligen. Tester ska omfatta:”

Testkatalogen bör omsätta den skyldigheten i specifika övningar, såsom skrivbordsövning för krisledning, återställningstest av säkerhetskopior, failover-test i molnmiljö, test av kontaktträd och simulering av leverantörsstörning.

Prestanda-, kapacitets- och återställningstester: det förbisedda resiliensunderlaget

Prestandatestning behandlas ofta som en ingenjörsfråga. Enligt DORA blir den resiliensunderlag.

En handelsplattform, betaltjänst, skadesystem, identitetsplattform eller kundportal behöver inte utsättas för en cyberattack för att svika kunderna. Kapacitetsuttömning, kömättnad, flaskhalsar i databaser, felkonfigurerad autoskalning eller trasig failover kan skapa samma operativa störning som en säkerhetsincident.

ISO/IEC 27001:2022 Annex A 8.6 Kapacitetshantering är det primära ankaret. Underlaget kan omfatta belastningstestning, stresstestning, testning av tjänstedegradering, validering av infrastrukturtrösklar, återställningstester av säkerhetskopior och failover-simuleringar.

En bra post för prestanda- och kapacitetstest bör fånga:

• Baslinjeantaganden för normal belastning och toppbelastning
• Kritiska transaktionsflöden som testats
• Infrastruktur- och molngränser som testats
• Övervakningspaneler och larmtrösklar
• Fellägen, såsom kömättnad eller flaskhalsar i databaser
• Relevans för RTO och RPO där failover eller återställning testas
• Verksamhetspåverkan om trösklar överskrids
• Åtgärder, skalningsbeslut eller arkitekturändringar
• Ledningens acceptans av kvarstående kapacitetsrisk

Zenith Blueprint, Step 23, kopplar återställningsförväntningar till underlag:

“Verifiera att Recovery Time Objective (RTO) och Recovery Point Objective (RPO) för kritiska system är anpassade till förväntningar på verksamhetskontinuitet (5.30). Genomför minst ett tekniskt återställningstest eller en failover-simulering och dokumentera resultaten.”

Det är skillnaden mellan att säga “vi har säkerhetskopior” och att visa att en kritisk tjänst återställdes inom överenskommen tolerans, med dokumenterade resultat och synlighet för ledningen.

Penetrationstestning och red teaming: starkt underlag kräver stark styrning

Penetrationstestning är mycket värdefullt underlag, men medför också operativ risk. Bristfälligt styrd testning kan påverka produktionssystem, exponera känsliga data, utlösa okontrollerade larm, skapa rättsliga problem eller störa kunder.

Policy för applikationssäkerhetskrav – SME anger en tydlig releasegrind:

“Före driftsättning ska alla applikationer genomgå säkerhetstestning för att verifiera de basfunktioner som anges ovan.”

För kritiska applikationer bör detta matas in i DORA-katalogen som säkerhetstestning i förproduktion, validering efter produktionssättning för högriskändringar och periodisk penetrationstestning baserad på exponering och kritikalitet.

Policy för säkerhetstestning och red teaming stärker åtgärdskedjan:

“Åtgärdande av iakttagelser: Alla identifierade sårbarheter eller svagheter ska dokumenteras i en rapport över iakttagelser med allvarlighetsklassning. Efter mottagande av rapporten ansvarar systemägare för att ta fram en åtgärdsplan med förfallodatum; exempelvis ska kritiska iakttagelser åtgärdas inom 30 dagar och iakttagelser med hög allvarlighetsgrad inom 60 dagar, i enlighet med organisationens policy för sårbarhets- och patchhantering. STC ska följa upp framdriften i åtgärdandet. Omtestning ska utföras för att bekräfta att kritiska problem har lösts eller reducerats på ett tillräckligt sätt.”

Samma policy definierar rapporteringsförväntningar:

“Rapportering: En formell rapport ska utfärdas vid avslut av varje test. För penetrationstestning ska rapporten innehålla en sammanfattning för ledningen, metodik och detaljerade iakttagelser med stödjande underlag och rekommendationer.”

Zenith Blueprint, Step 21, lyfter även skydd vid revision och testning:

“Inget test eller ingen revision bör genomföras utan dokumenterat godkännande från systemägare eller relevanta intressenter.”

Spelregler, testfönster, nödkontakter, tillfällig åtkomst, datahantering, loggning, rollback-rutiner och juridiska godkännanden är inte byråkrati. De är resiliensskydd.

Inkludera IKT-tredjepartsleverantörer innan testet fallerar

DORA gör IKT-tredjepartsrisk till en central resiliensfråga. Article 28 kräver att finansiella entiteter hanterar IKT-tredjepartsrisk inom ramverket för IKT-riskhantering, behåller ansvaret när de använder IKT-tjänster, upprätthåller ett informationsregister, rapporterar vissa arrangemang, genomför förhandsbedömningar före avtal och använder leverantörer som uppfyller lämpliga informationssäkerhetsstandarder. Articles 29 och 30 behandlar koncentrationsrisk, underleverantörer, dataåterställning, avtalsmässiga skydd, servicenivåer, incidentstöd, revisionsrätt, leverantörers kontinuitetstestning, deltagande i testning där det är relevant och exit-arrangemang.

ISO/IEC 27001:2022 Annex A tillhandahåller stödjande leverantörskontroller, inklusive 5.19 Informationssäkerhet i leverantörsrelationer, 5.20 Hantering av informationssäkerhet i leverantörsavtal, 5.21 Hantering av informationssäkerhet i IKT-leveranskedjan, 5.22 Övervakning, granskning och ändringshantering av leverantörstjänster och 5.23 Informationssäkerhet vid användning av molntjänster.

En DORA-testkatalog bör identifiera vilka tester som kräver leverantörsmedverkan eller leverantörsunderlag. Exempel är:

• Antaganden om failover hos molnleverantör
• Eskalering från hanterad SOC och bevarande av bevismaterial
• Incidentkommunikation för central bankplattform
• Avbrottsscenario hos betalningsförmedlare
• Återställningstest hos identitetsleverantör
• Intyg om penetrationstestning från SaaS-leverantör
• Konsekvensbedömning av kritisk underleverantörskedja

Ett program som exkluderar kritiska IKT-leverantörer kommer att falla på verklighetstestet. Den kundvända tjänsten kan vara er, men resiliensberoendet kan finnas i en molnregion, outsourcad SOC, identitetsleverantör, programvaruleverantör, betalningsförmedlare eller datacenter.

Mappning för tvärgående regelefterlevnad: ett underlag, många skyldigheter

Ett väl utformat DORA-testprogram minskar revisionsutmattning. Samma underlag kan stödja DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 och COBIT 2019-styrningsgranskningar om det taggas, bevaras och rapporteras korrekt.

GDPR får inte glömmas bort. Om resiliensprovningar omfattar personuppgifter, loggar, kundregister, identitetsdata, HR-register, biometriska uppgifter eller särskilda kategorier av personuppgifter måste organisationen följa GDPR-principerna, inklusive laglighet, korrekthet, öppenhet, uppgiftsminimering, lagringsminimering, riktighet, konfidentialitet och ansvarsskyldighet. Kopior av testdata, exporterade loggar och underlag från penetrationstester kan bli reglerade datalager. Testprogrammet bör definiera vem som får åtkomst till dem, hur länge de bevaras och hur de avvecklas säkert.

Hur revisorer kommer att testa samma program

En DORA-tillsynsmyndighet, ISO-revisor, NIST-baserad bedömare, COBIT-granskare och kundrevisor kan granska samma underlag genom olika perspektiv.

Zenith Controls är användbart här som en kompass för tvärgående regelefterlevnad. För DORA-testning lyfter Clarysec 5.35 Oberoende granskning av informationssäkerhet, 8.8 Hantering av tekniska sårbarheter och 8.6 Kapacitetshantering som särskilt viktiga ankare i ISO/IEC 27001:2022 Annex A. De hjälper kontrollägare att koppla testning till oberoende säkerhetsförsäkran, sårbarhetshantering och operativ kapacitet.

Clarysecs Informationssäkerhetspolicy stödjer också revisionsspår:

“Kontrollägare ska bevara testresultat, loggar och granskningsprotokoll för att stödja periodiska revisioner.”

Den meningen bör bli en operativ regel. Varje testägare ska veta vad som ska bevaras, var det ska bevaras, hur det ska skyddas och hur det kopplas till risk- och kontrollunderlag.

Bygg ett DORA-till-ISO-underlagspaket på en vecka

En finansiell entitet eller IKT-leverantör kan göra betydande framsteg på fem arbetsdagar.

Dag 1: Definiera omfattning och kritikalitet

Använd tänkesättet i ISO/IEC 27001:2022 avsnitten 4.1 till 4.4. Identifiera intressenter, regulatoriska skyldigheter, avtalsförpliktelser, gränssnitt och beroenden. Lista verksamhetstjänster, kritiska eller viktiga funktioner, nyckeltillgångar, datatyper och IKT-leverantörer.

Resultat: register över omfattning för DORA-testning.

Dag 2: Skapa den årliga testkatalogen

Använd de fyra testfamiljerna: sårbarhet, scenario, prestanda och penetration. För varje tjänst definieras vilka tester som gäller, frekvens, ägare, oberoendenivå och utlösare. Inkludera utlösare för högriskändringar.

Resultat: testkatalog för digital operativ resiliens 2026.

Dag 3: Mappa kontroller och skyldigheter

Mappa varje test till ISO/IEC 27001:2022 Annex A, riskregistret, SoA, DORA-artiklar, leverantörsförpliktelser och relevanta Zenith Controls-poster. Exempelvis mappar månatliga externa sårbarhetsskanningar till 8.8 Hantering av tekniska sårbarheter, riskbehandling, övervakning, DORA:s IKT-riskhantering och NIST CSF-resultat för sårbarheter.

Resultat: kontrollmappningsmatris.

Dag 4: Standardisera underlagsmappar

Skapa en kontrollerad underlagsstruktur:

• 01 Plan och auktorisation
• 02 Omfattning och spelregler
• 03 Råresultat
• 04 Slutrapport
• 05 Register över iakttagelser
• 06 Åtgärdsärenden
• 07 Omtestningsunderlag
• 08 Ledningsrapportering
• 09 Erfarenhetsåterföring och policyuppdateringar

Resultat: underlagsarkiv med regler för bevarande.

Dag 5: Granska iakttagelser och rapportering

Konsolidera öppna iakttagelser efter allvarlighetsgrad, tjänst, riskägare och förfallodatum. Identifiera försenat åtgärdande, accepterade risker och luckor i omtestning. Förbered en ledningspanel för ledningsorganet som visar testtäckning, större iakttagelser, försenade åtgärder, tredjepartsfrågor och kvarstående risk.

Resultat: styrelsefärdig DORA- och ISO-testpanel.

Vanliga fallgropar i DORA-testprogram

Det vanligaste felet är inte brist på testning. Det är brist på styrning.

Var uppmärksam på följande problem:

• Penetrationstester genomförs årligen, men iakttagelser följs inte upp till stängning
• Sårbarhetsskanningar körs ofta, men kritiska tillgångar saknas i omfattningen
• Skrivbordsövningar genomförs, men det finns ingen beslutslogg eller åtgärdsplan för erfarenhetsåterföring
• Återställningstester av säkerhetskopior genomförs, men mappas inte mot RTO och RPO
• Belastningstester körs av utvecklingsteamet, men rapporteras inte till risk eller regelefterlevnad
• IKT-leverantörer exkluderas från scenario- och återställningstester
• Underlag lagras i personliga mappar, chattrådar eller ohanterade enheter
• Styrelserapporter fokuserar på aktivitetsvolymer snarare än olösta resiliensrisker
• SoA anger att en kontroll är tillämplig, men inget testunderlag finns
• Testning skapar produktionsrisk eftersom auktorisation och gränser är otydliga

Varje lucka går att åtgärda. Lösningen är inte mer slumpmässig testning. Lösningen är ett kontrollerat program som kopplar samman risk, testaktivitet, åtgärdande, underlag och ledningens tillsyn.

Vad styrelsen faktiskt bör se

DORA gör IKT-resiliens till ett ansvar för ledningsorganet. En användbar styrelserapport ska inte innehålla varje teknisk iakttagelse. Den ska besvara om organisationen är tillräckligt resilient i förhållande till sin riskaptit och störningstolerans.

En stark kvartalsvis eller halvårsvis rapport innehåller:

• Testtäckning mot kritiska eller viktiga funktioner
• Genomförda jämfört med planerade tester
• Kritiska och höga iakttagelser per tjänst
• Försenat åtgärdande per ägare
• Godkännandegrad vid omtestning
• Leverantörsrelaterade iakttagelser och koncentrationsfrågor
• Erfarenheter från scenariotester som påverkar kris- eller incidentplaner
• Kapacitetsrisker i förhållande till verksamhetstillväxt och toppperioder
• Kvarstående risker som kräver ledningens acceptans
• Begränsningar i budget, resurser eller verktyg

Denna rapport blir underlag till ledningens genomgång enligt ISO, DORA-styrningsunderlag och ett praktiskt beslutsverktyg.

Från utspridda tester till strategisk resiliens

Informationssäkerhetschefens ursprungliga problem var inte att testning saknades. Organisationen hade skanningar, skrivbordsövningar, belastningsrapporter och PDF:er från penetrationstester. Problemet var att dessa aktiviteter ännu inte berättade en sammanhållen underlagshistoria.

Ett enhetligt testprogram för DORA och ISO/IEC 27001:2022 ändrar detta. Riskbedömningen driver katalogen. Katalogen driver auktoriserad testning. Testning producerar iakttagelser. Iakttagelser driver åtgärdande och omtestning. Resultaten matar in i ledningsrapportering. Erfarenhetsåterföring uppdaterar policyer, rutiner, avtal och kontroller.

Det är så en efterlevnadsbörda blir en strategisk förmåga.

Clarysec hjälper organisationer att undvika parallella efterlevnadsprogram. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 och COBIT 2019 behöver inte separata underlagsuniversum. De behöver en enda, styrd operativ modell som kan presenteras genom olika revisionsperspektiv.

Vår metod kombinerar:

• Zenith Blueprint för stegvis ISO-införande och revisionsberedskap
• Zenith Controls för mappning av tvärgående regelefterlevnad mellan kontroller, ramverk och revisionsförväntningar
• Policyer för större organisationer och små och medelstora företag avseende säkerhetstestning, revisionsövervakning, sårbarhetshantering, applikationssäkerhet, kontinuitet och informationssäkerhet
• Praktiska register, underlagsstrukturer och mallar för ledningsrapportering

Om ert DORA-testunderlag för 2026 är utspritt över skanningsverktyg, utvecklingsmappar, anteckningar från skrivbordsövningar och PDF:er från penetrationstester är det nu dags att konsolidera det.

Börja med en årlig testkatalog som är mappad mot riskbehandling enligt ISO/IEC 27001:2022, er SoA, kritiska eller viktiga funktioner, IKT-tredjeparter och ledningsrapportering. Använd därefter Clarysecs Zenith Blueprint, Zenith Controls och policyverktygslåda för att göra katalogen till försvarbara revisionsbevis.

Clarysec kan hjälpa er att utforma programmet, mappa kontrollerna, strukturera underlagspaketet och förbereda resiliensrapporten på styrelsenivå innan nästa tillsynsbegäran landar.