DORA TLPT-bevismaterial mappat mot ISO 27001-kontroller

Klockan är 07:40 en måndagsmorgon och informationssäkerhetschefen på ett medelstort betalningsinstitut stirrar på tre versioner av samma obekväma fråga.

Styrelsen vill veta om organisationen kan stå emot ett ransomware-drivet avbrott i kundernas betalningsportal. Tillsynsmyndigheten vill se bevis för att testningen av digital operativ motståndskraft inte är en PowerPoint-övning. Internrevision vill se ett tydligt spår från DORA-krav till IKT-risk, ISO 27001-kontroller, testresultat, åtgärdsplaner, leverantörsunderlag och formellt ledningsgodkännande.

Informationssäkerhetschefen har en red team-rapport. SOC har skärmbilder av larm. Infrastrukturteamet har en logg från återställning av säkerhetskopior. Juridik har en spårningslista för DORA-beredskap. Upphandling har intyg från molnleverantörer.

Inget av detta hänger ihop.

Det är här många DORA TLPT- och resilienstestprogram fallerar. Inte för att testningen är svag, utan för att bevismaterialet är fragmenterat. När en revisor frågar: ”Visa hur detta test styrker resiliensen i en kritisk eller viktig funktion” kan svaret inte vara en mapp full av skärmbilder. Det måste vara en försvarbar beviskedja.

Det är i den kedjan som ett ISMS anpassat till ISO/IEC 27001:2022 ISO/IEC 27001:2022 blir kraftfullt. ISO 27001 ger struktur för omfattning, riskbedömning, kontrollurval, tillämpbarhetsförklaring, operativ styrning, internrevision, ledningens genomgång och ständig förbättring. DORA tillför det sektorsspecifika trycket. Clarysecs metodik och verktyg för tvärgående regelefterlevnad kopplar ihop båda till en gemensam, revisionsklar bevismodell.

DORA TLPT är ett styrningstest, inte bara en angreppssimulering

Hotbildsstyrd penetrationstestning, eller TLPT, är lätt att missförstå. Tekniskt kan den likna en avancerad red team-övning: hotinformation, realistiska angreppsvägar, smygtekniker, exploateringsförsök, scenarier för lateral förflyttning och validering av blue team-respons.

För DORA är den djupare frågan digital operativ motståndskraft. Kan den finansiella entiteten stå emot, hantera och återhämta sig från en allvarlig IKT-störning som påverkar verksamhetsprocesser? Kan den visa att kritiska eller viktiga funktioner håller sig inom fastställda toleransnivåer för påverkan? Kan ledningen visa att IKT-risk styrs, finansieras, testas, åtgärdas och förbättras?

DORA Article 1 fastställer ett enhetligt EU-ramverk för säkerheten i nätverks- och informationssystem som stödjer finansiella entiteters verksamhetsprocesser. Det omfattar IKT-riskhantering, rapportering av större IKT-relaterade incidenter, testning av digital operativ motståndskraft, hantering av IKT-tredjepartsrisk, obligatoriska avtalskrav för IKT-leverantörer, tillsyn över kritiska IKT-tredjepartsleverantörer och samarbete mellan tillsynsmyndigheter. DORA gäller från den 17 januari 2025.

För organisationer som även omfattas av NIS2 fungerar DORA som den sektorsspecifika unionsrättsakten för överlappande cybersäkerhetskrav. I praktiken bör finansiella entiteter prioritera DORA för IKT-riskhantering, incidentrapportering, testning och IKT-tredjepartsrisk där regelverken överlappar, samtidigt som de förstår NIS2-förväntningarna för koncernstrukturer, leverantörer och icke-finansiella digitala tjänster.

DORA placerar också ansvarsskyldighet på högsta nivå. Article 5 kräver att ledningsorganet definierar, godkänner, övervakar och genomför arrangemang för IKT-riskhantering. Det omfattar strategin för digital operativ motståndskraft, policy för IKT-verksamhetskontinuitet, respons- och återställningsplaner, revisionsplaner, budgetar, policyer för IKT-tredjeparter, rapporteringskanaler och tillräcklig kunskap om IKT-risk genom regelbunden utbildning.

Revisionsfrågan är därför inte bara: ”Genomförde ni en TLPT?”

Den är:

• Var TLPT kopplad till kritiska eller viktiga funktioner?
• Var den godkänd, avgränsad, säker och riskbedömd?
• Inkluderades leverantörer, molnberoenden och outsourcade IKT-tjänster där det var relevant?
• Genererade testet bevismaterial för detektering, respons, återställning och erfarenhetsåterföring?
• Omvandlades iakttagelser till riskbehandling, uppföljt åtgärdande, omtestning och ledningsrapportering?
• Förklarade tillämpbarhetsförklaringen vilka ISO 27001-kontroller i bilaga A som valdes för att hantera risken?

Därför behandlar Clarysec DORA TLPT-bevismaterial som en ISMS-fråga om bevismaterial, inte enbart som en leverans från penetrationstestning.

Bygg ISO 27001-ryggraden för bevismaterial innan testet startar

ISO 27001 kräver att en organisation etablerar, inför, underhåller och ständigt förbättrar ett ISMS som bevarar konfidentialitet, riktighet och tillgänglighet genom en riskhanteringsprocess. Avsnitt 4.1 till 4.4 kräver att organisationen förstår interna och externa frågor, intressenter, rättsliga och regulatoriska skyldigheter, gränssnitt och beroenden, och därefter dokumenterar ISMS-omfattningen.

För en DORA-reglerad entitet bör detta omfattningssteg uttryckligen fånga kritiska eller viktiga funktioner, IKT-tillgångar, molnplattformar, outsourcad drift, betalningssystem, kundportaler, identitetstjänster, loggningsplattformar, återställningsmiljöer och IKT-tredjepartstjänsteleverantörer. Om TLPT-omfattningen inte kan mappas tillbaka till ISMS-omfattningen är revisionsspåret redan svagt.

ISO 27001 avsnitt 6.1.1, 6.1.2 och 6.1.3, tillsammans med avsnitt 8.2 och 8.3, kräver en process för riskbedömning och riskbehandling. Risker ska identifieras mot konfidentialitet, riktighet och tillgänglighet. Riskägare ska utses. Sannolikhet och konsekvens ska bedömas. Kontroller ska väljas och jämföras mot bilaga A. Kvarstående risk ska accepteras av riskägare.

Detta är bryggan mellan DORA och revisionsklar testning.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, i fasen Riskhantering, Step 13, beskriver denna spårbarhetsroll tydligt:

SoA är i praktiken ett bryggdokument: det kopplar din riskbedömning/riskbehandling till de faktiska kontroller du har. Genom att fylla i det dubbelkontrollerar du också om du har missat några kontroller.

För DORA TLPT ska tillämpbarhetsförklaringen inte vara en statisk certifieringsartefakt. Den ska förklara varför kontroller såsom leverantörssäkerhet, incidenthantering, IKT-beredskap för verksamhetskontinuitet, loggning, övervakning, teknisk sårbarhetshantering, säkerhetskopiering, säker utveckling och säkerhetstestning är tillämpliga på resiliensscenariot.

Ett praktiskt riskscenario kan formuleras så här:

”Kompromettering av privilegierade autentiseringsuppgifter hos en identitetsleverantör gör att en angripare kan nå administrationssystem för betalningshantering, ändra routningskonfigurationer och störa en kritisk betalningsfunktion, vilket orsakar tjänsteavbrott, regulatoriska rapporteringsskyldigheter, kundskada och anseendeskada.”

Detta enda scenario kan styra TLPT-omfattningen, detekteringsfall, leverantörsmedverkan, återställningsövning, styrelserapportering och bevismaterial.

Zenith Blueprint rekommenderar också att regulatorisk spårbarhet görs explicit:

Korsreferera regelverk: Om vissa kontroller införs specifikt för att uppfylla GDPR, NIS2 eller DORA kan du notera detta antingen i Riskregistret (som en del av motiveringen av riskkonsekvens) eller i SoA-kommentarerna.

Rådet är enkelt, men det förändrar revisionsdialogen. I stället för att säga till en revisor att DORA har beaktats kan organisationen visa var DORA förekommer i riskregistret, SoA, testprogrammet, policyuppsättningen och ledningens genomgång.

Mappa DORA-testning mot ISO 27001-kontroller som revisorer känner igen

DORA Article 6 förväntar sig ett dokumenterat ramverk för IKT-riskhantering som är integrerat i den övergripande riskhanteringen. ISO 27001 bilaga A ger den kontrollkatalog som gör detta operativt.

För DORA TLPT och resilienstestning är följande ISO/IEC 27001:2022-kontroller i bilaga A särskilt viktiga:

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls hjälper organisationer att undvika att behandla dessa kontroller som isolerade checklistpunkter. Den mappar ISO/IEC 27002:2022-kontroller till attribut, domäner, operativa förmågor, revisionsförväntningar och mönster för tvärgående ramverk.

Till exempel klassificerar Zenith Controls ISO/IEC 27002:2022-kontroll 5.30, IKT-beredskap för verksamhetskontinuitet, som ”Korrigerande”, kopplad till ”Tillgänglighet”, associerad med cybersäkerhetsbegreppet ”Respond” och placerad i domänen ”Resiliens”. Den klassificeringen är användbar när man förklarar för revisorer varför en återställningsövning inte bara är en IT-driftaktivitet, utan en resilienskontroll med en definierad roll i kontrollmiljön.

Zenith Controls klassificerar också kontroll 8.29, säkerhetstestning vid utveckling och acceptans, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, med operativa förmågor inom applikationssäkerhet, informationssäkringsarbete och system- och nätverkssäkerhet. För TLPT-iakttagelser som kan spåras tillbaka till svagheter i applikationsdesign, osäkert API-beteende, bristfälligt autentiseringsflöde eller otillräcklig validering är detta kontrollvägen in i styrningen av säker utveckling.

Kontroll 5.35, oberoende granskning av informationssäkerhet, är också viktig. Den stödjer oberoende ifrågasättande, styrningssäkring och korrigerande förbättring. Interna team kan samordna testning, men revisionsklart bevismaterial kräver granskning, eskalering och tillsyn bortom de personer som byggde eller driftade de testade systemen.

Skydda systemet medan det testas

Ett farligt antagande vid resilienstestning är att testning automatiskt är bra. I verkligheten kan intrusiv testning orsaka avbrott, exponera känsliga data, förorena loggar, utlösa automatiserade försvar, bryta kundsessioner eller få leverantörer att aktivera akuta rutiner.

Clarysecs Policy för säkerhetstestning och Red Teaming Policy för säkerhetstestning och Red Teaming ger organisationer ett styrningsmönster för säkert genomförande. Avsnitt 6.1 anger:

Testtyper: Säkerhetstestprogrammet ska 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 förmåga till detektering och respons.

För TLPT är red team-elementet uppenbart, men revisionsvärdet kommer från programutformningen. Sårbarhetsskanning, penetrationstestning, red team-övningar, resiliensövningar och omtestning ska bilda en cykel, inte en samling frikopplade tester.

Avsnitt 6.2 i samma policy behandlar säkert genomförande:

Omfattning och spelregler: För varje test eller övning ska STC definiera omfattningen, inklusive system och IP-intervall som ingår, tillåtna testmetoder, mål, tidpunkt och varaktighet. Spelregler ska dokumenteras. Exempelvis kan driftskänsliga system anges som undantagna från aktiv påverkan och endast övervakas för att undvika störning, och all testning i produktion ska omfatta återgångs- och stopprutiner. Säkerhetsåtgärder, såsom definierade tidsfönster och kommunikationskanaler, ska etableras för att förhindra oavsiktliga tjänsteavbrott.

Detta mappar direkt till Zenith Blueprint, fasen Controls in Action, Step 21, som fokuserar på ISO 27001-kontroll A.8.34, skydd av informationssystem vid revisionstestning. Zenith Blueprint varnar för att revisioner, penetrationstester, forensiska granskningar och operativa utvärderingar kan omfatta privilegierad åtkomst, intrusiva verktyg eller tillfälliga ändringar av systembeteende. Den betonar godkännande, omfattning, tidsfönster, godkännande från systemägare, återgång, övervakning och säker hantering av testdata.

Det revisionsklara bevispaketet bör omfatta:

• TLPT-instruktion och mål
• Sammanfattning av hotinformation och scenariomotivering
• Kritiska eller viktiga funktioner inom omfattningen
• System, IP-intervall, identiteter, leverantörer och miljöer inom omfattningen
• Undantag och system som endast övervakas
• Spelregler
• Riskbedömning för produktionstestning
• Återgångs- och stopprutiner
• Modell för SOC-avisering, inklusive vad som lämnas ut och vad som undanhålls
• Godkännanden från juridik, dataskydd och leverantörer
• Bevismaterial för skapande och återkallelse av testkonton
• Säker lagringsplats för testartefakter och loggar

En DORA TLPT som inte kan visa säkert godkännande och kontroll över testaktivitet kan avslöja resiliensluckor, men den skapar också styrningsluckor.

Omvandla TLPT-resultat till riskbehandling

Det vanligaste felet efter test är problemet med red team-rapporten som hamnar på hyllan. En högkvalitativ rapport levereras, cirkuleras, diskuteras och tappar sedan långsamt fart. Iakttagelser förblir öppna. Kompenserande kontroller dokumenteras inte. Accepterade risker är informella. Omtestning sker aldrig.

Policy för säkerhetstestning och Red Teaming gör detta oacceptabelt. Avsnitt 6.6 anger:

Åtgärdande av iakttagelser: Alla identifierade sårbarheter eller svagheter ska dokumenteras i en rapport över iakttagelser med allvarlighetsgrader. När rapporten mottagits ansvarar systemägare för att ta fram en åtgärdsplan med förfallodagar; kritiska iakttagelser ska exempelvis å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 åtgärdsarbetets status. Omtestning ska genomföras för att bekräfta att kritiska problem har lösts eller reducerats på ett tillräckligt sätt.

Avsnitt 6.7 lägger till styrningslagret:

Rapportering: En formell rapport ska utfärdas vid avslut av varje test. För penetrationstestning ska rapporten omfatta en sammanfattning för ledningen, metodik och detaljerade iakttagelser med stödjande underlag och rekommendationer. För red team-övningar ska rapporten beskriva scenarierna, vilka angreppsvägar som lyckades, vad som upptäcktes av Blue Team och erfarenhetsåterföring avseende luckor i detektering och respons. Informationssäkerhetschefen ska presentera sammanfattade resultat och åtgärdsstatus för högsta ledningen och, där det är relevant, inkludera dem i den årliga säkerhetsrapporten till styrelsen.

Detta ligger i linje med vägledningen för riskbehandling i ISO/IEC 27005:2022: välj behandlingsalternativ, fastställ kontroller från ISO 27001 bilaga A och sektorsspecifika krav, bygg en riskbehandlingsplan, tilldela ansvariga personer, definiera tidsramar, följ status, inhämta godkännande från riskägare och dokumentera acceptans av kvarstående risk.

Varje väsentlig TLPT-iakttagelse ska bli en av fyra saker: en avhjälpande åtgärd, en kontrollförbättring, en formell riskacceptans eller ett krav på omtestning.

Målet är inte att producera fler dokument. Målet är att varje dokument ska förklara nästa beslut.

Resilienstestning måste styrka återställning, inte bara detektering

En lyckad TLPT kan visa att SOC upptäckte trafik till kommando- och kontrollinfrastruktur, blockerade lateral förflyttning och eskalerade korrekt. Det är värdefullt, men DORA-resilienstestning går längre. Den frågar om organisationen kan fortsätta eller återställa verksamhetstjänster.

Zenith Blueprint, fasen Controls in Action, Step 23, förklarar kontroll 5.30, IKT-beredskap för verksamhetskontinuitet, med ett språk varje informationssäkerhetschef bör använda med styrelsen:

Ur ett revisionsperspektiv testas denna kontroll ofta med en enda fras: Visa mig. Visa mig det senaste testresultatet. Visa mig återställningsdokumentationen. Visa mig hur lång tid det tog att växla över och tillbaka. Visa mig bevismaterialet för att det som utlovats kan levereras.

Denna ”Visa mig”-standard är skillnaden mellan policymognad och operativ resiliens.

Clarysecs Policy för verksamhetskontinuitet och katastrofåterställning – SME Policy för verksamhetskontinuitet och katastrofåterställning – SME, från avsnittet ”Krav för genomförande av policyn”, avsnitt 6.4.1, anger:

Organisationen ska testa både sina BCP- och DR-förmågor minst årligen. Tester ska omfatta:

Samma policys avsnitt om tillämpning, avsnitt 8.5.1, gör ansvarsskyldigheten för bevismaterial explicit:

VD ska säkerställa att följande upprätthålls och är revisionsklart:

För en DORA-reglerad finansiell entitet kan årlig testning vara golvet, inte ambitionen. Kritiska eller viktiga funktioner med högre risk ska testas oftare, särskilt efter arkitekturändringar, molnmigrering, större incidenter, nya IKT-leverantörer, väsentliga applikationsreleaser eller förändrad hotexponering.

Ett starkt bevispaket för resilienstest bör omfatta:

• Konsekvensanalys för verksamheten (BIA) som mappar den kritiska eller viktiga funktionen
• RTO och RPO godkända av verksamhetsägare
• Systemberoendekarta, inklusive identitet, DNS, nätverk, moln, databas, övervakning, säkerhetskopiering och tredjepartstjänster
• Testresultat för säkerhetskopiering och återställning
• Tidsstämplar för övergång och återgång
• Bevismaterial för att säkerhetskontroller fungerade under störning
• Mallar för kund-, myndighets- och intern kommunikation
• Deltagarloggar för incidentledare och krisledningsgrupp
• Erfarenhetsåterföring och förbättringsåtgärder
• Bevismaterial från omtestning av tidigare återställningsluckor

Det är också här GDPR kommer in i bilden. GDPR Articles 2 och 3 för in de flesta SaaS- och fintech-behandlingar av personuppgifter inom EU i tillämpningsområdet. Article 4 definierar personuppgifter, behandling, personuppgiftsansvarig, personuppgiftsbiträde och personuppgiftsincident. Article 5 kräver riktighet, konfidentialitet och ansvarsskyldighet, vilket innebär att organisationen måste kunna visa efterlevnad. Om TLPT eller återställningstestning använder produktionsdata med personuppgifter, kopierar loggar som innehåller identifierare eller validerar respons vid personuppgiftsincident, måste dataskyddsåtgärder dokumenteras.

Leverantörsunderlag är DORA-blindpunkten som revisorer inte kommer att ignorera

Moderna finansiella tjänster byggs av molnplattformar, SaaS-applikationer, hanterade säkerhetsleverantörer, betalningsförmedlare, dataplattformar, identitetsleverantörer, observerbarhetsverktyg, outsourcade utvecklingsteam och leverantörer av säkerhetskopiering.

DORA Article 28 kräver att finansiella entiteter hanterar IKT-tredjepartsrisk som en del av ramverket för IKT-riskhantering och förblir fullt ansvariga även när IKT-tjänster outsourcas. Article 30 kräver skriftliga IKT-tjänsteavtal med tjänstebeskrivningar, villkor för underleverantörer, behandlingsplatser, dataskydd, åtkomst och återställning, servicenivåer, incidentstöd, samarbete med myndigheter, rätt att säga upp avtalet, starkare villkor för kritiska eller viktiga funktioner, revisionsrätt, säkerhetsåtgärder, TLPT-medverkan där det är relevant och exitarrangemang.

Det innebär att ett TLPT-scenario inte kan stanna vid organisationens brandvägg om den kritiska funktionen är beroende av en leverantör.

Clarysecs Policy för leverantörssäkerhet och tredjepartssäkerhet – SME Policy för leverantörssäkerhet och tredjepartssäkerhet – SME, från avsnittet ”Krav för genomförande av policyn”, avsnitt 6.3.1, anger:

Kritiska eller högriskleverantörer ska granskas minst årligen. Granskningen ska verifiera:

Policy för säkerhetstestning och Red Teaming lägger till ett testspecifikt leverantörskrav i avsnitt 6.9:

Samordning av tredjepartstestning: När en kritisk leverantör eller tjänsteleverantör ingår i omfattningen för organisationens övergripande säkerhet ska organisationen, i enlighet med policy för leverantörssäkerhet och tredjepartssäkerhet, där det är möjligt inhämta försäkran om deras säkerhetstestningspraxis eller samordna gemensam testning. Om exempelvis en molnleverantör (CSP) används kan organisationen förlita sig på dess penetrationstestrapporter eller inkludera den i samverkande red team-scenarier, med beaktande av avtalsvillkor.

För revisionsklart DORA-bevismaterial bör leverantörssäkring kopplas till samma riskscenario som TLPT. Om identitetsleverantören är avgörande för återställning av betalningar bör bevispaketet omfatta leverantörsgranskning, avtalsmässiga säkerhetskrav, villkor för incidentstöd, testsamordning, försäkransrapporter, underlag för servicenivåer, exitstrategi och begränsningar för testning.

NIS2 Article 21 är också relevant för SaaS, moln, hanterade tjänster, hanterad säkerhet, datacenter, CDN, betrodda tjänster, DNS, TLD, marknadsplatser online, sökfunktioner och sociala nätverksleverantörer. Den kräver en allriskansats som omfattar riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, bedömning av effektivitet, utbildning, kryptografi, åtkomstkontroll, tillgångshantering, MFA och säker kommunikation.

Det praktiska resultatet är enkelt: finansiella entiteter bör bygga en bevismodell som först uppfyller DORA och därefter korsrefererar NIS2-förväntningar där leverantörer, koncernentiteter eller icke-finansiella digitala tjänster är berörda.

En praktisk Clarysec-liggare för TLPT-bevismaterial

Anta att scenariot är:

”En hotaktör komprometterar ett administratörskonto i en SaaS-supportplattform, förflyttar sig in i betalningsdriftsmiljön, ändrar konfiguration och stör transaktionshanteringen.”

Skapa en bevisliggare med en rad per bevisobjekt. Vänta inte tills testet är slut. Fyll i den under planering, genomförande, åtgärdande och avslut.

Använd därefter Zenith Blueprint Step 13 för att lägga till spårbarhet i riskregistret och tillämpbarhetsförklaringen. Varje bevisobjekt bör kopplas till ett riskscenario, en riskägare, vald kontroll, riskbehandlingsplan och beslut om kvarstående risk.

Om en iakttagelse avser en programvarubrist, hänvisa till kontroller för säker utveckling och testning. Clarysecs Policy för säker utveckling – SME Policy för säker utveckling – SME, från avsnittet ”Krav för genomförande av policyn”, avsnitt 6.5.2, kräver:

Testning ska dokumenteras med:

Om en iakttagelse genererar forensiskt material ska beviskedjan bevaras. Clarysecs Policy för bevisinsamling och forensik – SME Policy för bevisinsamling och forensik – SME, från avsnittet ”Styrningskrav”, avsnitt 5.2.1, anger:

Varje objekt av digital bevisning ska loggas med:

Detta är punkten som många team missar. Bevismaterial är inte bara slutrapporter. Det är det kontrollerade underlaget över vem som godkände, vem som genomförde, vad som hände, vad som upptäcktes, vad som återställdes, vad som ändrades, vad som fortsatt är exponerat och vem som accepterade den exponeringen.

Hur revisorer granskar samma TLPT-bevismaterial

DORA TLPT-bevismaterial kommer att läsas olika beroende på revisorns bakgrund. Clarysec utformar bevispaket så att varje perspektiv kan hitta det som behövs utan att tvinga team att duplicera arbete.

COBIT 2019 förekommer i Zenith Blueprint som referens för tvärgående regelefterlevnad vid säker revision och testgenomföring, inklusive DSS05.03 och MEA03.04. Relevansen är inte att COBIT ersätter DORA eller ISO 27001, utan att ISACA-orienterade säkerhetsgranskare kommer att söka efter kontrollerat genomförande, övervakning, utvärdering och underlag för regelefterlevnad.

Styrelseberättelsen: vad ledningen måste godkänna

Styrelserapportering bör undvika teknisk teater. Styrelsen behöver inte exploit-payloads. Den behöver beslutsmässigt underlag:

• Vilken kritisk eller viktig funktion testades?
• Vilket hotscenario simulerades och varför?
• Fungerade detekteringen?
• Fungerade responseskaleringen?
• Uppfyllde återställningen RTO och RPO?
• Vilka leverantörer var involverade eller begränsade?
• Vilka väsentliga svagheter kvarstår?
• Vilken är åtgärdskostnaden, ägaren och tidslinjen?
• Vilka kvarstående risker kräver formell acceptans?
• Vad ska omtestas?

Det är här ISO 27001 avsnitt 5 blir viktig. Högsta ledningen ska säkerställa att informationssäkerhetspolicyn och målen är etablerade, anpassade till strategisk inriktning, integrerade i verksamhetsprocesser, resurssatta, kommunicerade och föremål för ständig förbättring. Roller och ansvar ska tilldelas. Mål ska vara mätbara där det är praktiskt möjligt och ta hänsyn till tillämpliga krav och resultat från riskbehandling.

Om TLPT identifierar att återställningstiden är sex timmar mot en verksamhetstolerans på fyra timmar är detta inte bara en post i infrastrukturens backlogg. Det är ett ledningsbeslut som omfattar riskaptit, budget, kundåtaganden, regulatorisk exponering, avtal, arkitektur och operativ kapacitet.

Vanliga brister i bevismaterial vid DORA-resilienstestning

Clarysecs granskningar hittar ofta samma bevisluckor hos finansiella entiteter och IKT-tjänsteleverantörer som förbereder sig för DORA.

För det första mappar TLPT-omfattningen inte mot kritiska eller viktiga funktioner. Testet kan vara tekniskt imponerande, men det styrker inte resiliensen i den verksamhetsprocess som tillsynsmyndigheter bryr sig om.

För det andra erkänns leverantörsberoenden men styrks inte med bevismaterial. Team säger att molnleverantören, den hanterade SOC-funktionen eller SaaS-plattformen ingår i omfattningen, men avtal, revisionsrätt, testtillstånd, villkor för incidentstöd och exitplaner saknas.

För det tredje skapar testning bevismaterial men ingen behandling. Iakttagelser ligger kvar i en red team-rapport i stället för att omvandlas till uppdateringar av riskregister, kontrolländringar, ägare, datum, omtestning och beslut om kvarstående risk.

För det fjärde antas återställning i stället för att demonstreras. Policyer för säkerhetskopiering finns, men ingen kan visa tidsstämplar för övergång, integritetskontroller av återställning, åtkomstvalidering eller bekräftelse från verksamhetsägare.

För det femte är dataskydds- och forensiskt bevismaterial okontrollerat. Loggar och skärmbilder innehåller personuppgifter, testartefakter lagras på delade enheter, tillfälliga konton förblir aktiva och dokumentationen av beviskedjan är ofullständig.

För det sjätte är ledningsrapporteringen för teknisk. Högsta ledningen kan inte se om resiliensen förbättrades, om risk ligger inom riskaptit eller vilka investeringsbeslut som behövs.

Var och en av dessa luckor kan lösas genom att behandla DORA TLPT som ett strukturerat ISO 27001-arbetsflöde för bevismaterial.

Clarysecs integrerade arbetssätt för revisionsklar resiliens

Clarysecs arbetssätt kombinerar tre lager.

Det första lagret är Zenith Blueprint, en 30-stegs färdplan för genomförande. För detta ämne bygger Step 13 spårbarhet för riskbehandling och SoA, Step 21 skyddar system vid revisionstestning och Step 23 validerar IKT-beredskap för verksamhetskontinuitet. Dessa steg omvandlar TLPT från en teknisk händelse till en dokumenterad styrningscykel.

Det andra lagret är Clarysecs policybibliotek. Policy för säkerhetstestning och Red Teaming definierar testtyper, omfattning, spelregler, åtgärdande, rapportering och leverantörssamordning. Policy för verksamhetskontinuitet och katastrofåterställning – SME anger förväntningar för årlig BCP- och DR-testning och revisionsklart kontinuitetsunderlag. Policy för leverantörssäkerhet och tredjepartssäkerhet – SME stödjer leverantörssäkring. Policy för säker utveckling – SME säkerställer att säkerhetstestning dokumenteras. Policy för bevisinsamling och forensik – SME stödjer disciplin i bevisloggning och beviskedja.

Det tredje lagret är Zenith Controls, Clarysecs guide för tvärgående regelefterlevnad. Den hjälper till att mappa ISO/IEC 27002:2022-kontroller mot attribut, domäner, operativa förmågor och förväntningar i andra ramverk. För DORA TLPT är det viktigaste mönstret inte en enskild kontroll. Det är relationen mellan testning, kontinuitet, incidenthantering, leverantörshantering, loggning, övervakning, säker utveckling, oberoende granskning och styrning.

När dessa lager fungerar tillsammans förändras informationssäkerhetschefens måndagsmorgonproblem. I stället för tre frikopplade frågor från styrelsen, tillsynsmyndigheten och internrevision har organisationen en sammanhållen bevisberättelse:

”Vi identifierade den kritiska funktionen. Vi bedömde IKT-risken. Vi valde och motiverade kontroller. Vi godkände och genomförde TLPT säkert. Vi upptäckte, svarade och återställde. Vi involverade leverantörer där det krävdes. Vi dokumenterade bevismaterial. Vi åtgärdade iakttagelser. Vi omtestade. Ledningen granskade och accepterade den kvarstående risken.”

Det är revisionsklar resiliens.

Nästa steg

Om ert DORA TLPT-program fortfarande är organiserat kring rapporter i stället för beviskedjor, börja med en Clarysec-genomgång av bevismaterialet.

Använd Zenith Blueprint Zenith Blueprint Step 13 för att koppla TLPT-scenarier till risker, kontroller och tillämpbarhetsförklaringen. Använd Step 21 för att verifiera säkert godkännande, spelregler, återgång, övervakning och rensning. Använd Step 23 för att styrka IKT-beredskap för verksamhetskontinuitet med återställningsunderlag.

Anpassa därefter era operativa dokument till Clarysecs Policy för säkerhetstestning och Red Teaming Policy för säkerhetstestning och Red Teaming, Policy för verksamhetskontinuitet och katastrofåterställning – SME Policy för verksamhetskontinuitet och katastrofåterställning – SME, Policy för leverantörssäkerhet och tredjepartssäkerhet – SME Policy för leverantörssäkerhet och tredjepartssäkerhet – SME, Policy för säker utveckling – SME Policy för säker utveckling – SME och Policy för bevisinsamling och forensik – SME Policy för bevisinsamling och forensik – SME.

Använd slutligen Zenith Controls Zenith Controls för att korsmappa ert DORA TLPT-bevismaterial mot ISO 27001-kontroller, NIS2, GDPR, COBIT 2019 och revisorsförväntningar.

Om ni vill att nästa resilienstest ska producera mer än iakttagelser, använd Clarysec för att omvandla det till en försvarbar beviskedja. Ladda ner verktygspaketen, boka en bedömning av bevisberedskap eller begär en genomgång av hur Clarysec mappar DORA TLPT mot ISO 27001:2022-kontroller från planering till styrelsegodkännande.