Revisionsklar gendannelsestest for ISO 27001, NIS2 og DORA

Klokken er 07:40 en mandag morgen, og Sarah, CISO i en hurtigt voksende fintech-virksomhed, ser en krise udvikle sig i realtid. CFO’en kan ikke åbne platformen til godkendelse af betalinger. Servicedesken tror, det er et lagringsproblem. Infrastrukturteamet mistænker ransomware, fordi flere fællesdrev nu viser krypterede filnavne. CEO’en vil vide, om lønudbetalingen er sikker. Juridisk afdeling spørger, om tilsynsmyndigheder skal underrettes.

Sarah åbner backupdashboardet. Det er fyldt med grønne flueben.

Det burde være beroligende, men det er det ikke. Et vellykket backupjob er ikke dokumentation for en vellykket gendannelse. Det svarer til at se en brandslukker på væggen uden at vide, om den er tryksat, tilgængelig og kan bruges under pres.

Sarahs virksomhed er omfattet af ISO 27001:2022, anses for at være en vigtig enhed under NIS2 og er underlagt DORA som finansiel enhed. Spørgsmålet er ikke længere, om organisationen tager backups. Spørgsmålet er, om den kan gendanne de rigtige systemer til det rigtige tidspunkt inden for godkendte Recovery Time Objectives og Recovery Point Objectives med bevismateriale, der er stærkt nok til en revisor, tilsynsmyndighed, kunde, forsikringsgiver og bestyrelse.

Det er her, mange backupprogrammer fejler. De har backupjob. De har dashboards. De har snapshots. De har måske endda cloudlagring. Men når presset opstår, kan de ikke dokumentere, at kritiske systemer kan gendannes, at gendannelsestest er udført, at mislykkede test har udløst korrigerende handlinger, og at bevismaterialet kan kortlægges klart til forventningerne i ISO 27001:2022, NIS2, DORA, NIST og COBIT 2019.

Backup- og gendannelsestest er blevet et bestyrelsesrelevant spørgsmål om operationel robusthed. NIS2 skærper forventningerne til styring af cybersikkerhedsrisici og forretningskontinuitet. DORA gør IKT-operationel robusthed til en central forpligtelse for finansielle enheder og deres kritiske IKT-tjenesteudbydere. ISO 27001:2022 giver ledelsessystemstrukturen for omfang, risiko, kontroludvælgelse, bevismateriale, revision og løbende forbedring.

Den praktiske udfordring er at gøre en teknisk gendannelsestest til revisionsklart bevismateriale.

Backup er ikke bevismateriale, før gendannelse er dokumenteret

Et backupjob, der gennemføres korrekt, er kun et delvist signal. Det fortæller, at data blev kopieret et sted hen. Det dokumenterer ikke, at data kan gendannes, at applikationsafhængigheder er intakte, at krypteringsnøgler er tilgængelige, at identitetstjenester stadig fungerer, eller at det gendannede system understøtter reelle forretningsaktiviteter.

Revisorer ved det. Tilsynsmyndigheder ved det. Angribere ved det.

En teknisk moden revisor stopper ikke ved et skærmbillede, der viser en succesrate på 97 procent for backupjob. Revisoren vil spørge:

• Hvilke systemer er kritiske eller har høj konsekvens?
• Hvilke RTO og RPO gælder for hvert system?
• Hvornår blev den seneste gendannelsestest udført?
• Var testen fuld, delvis, på applikationsniveau, databaseniveau eller filniveau?
• Hvem validerede forretningsprocessen efter gendannelsen?
• Blev fejl registreret som afvigelser eller forbedringstiltag?
• Hvor længe opbevares logfiler og registreringer af gendannelsestest?
• Er backupkopier adskilt på tværs af lokationer?
• Hvordan kortlægges bevismaterialet til risikoregisteret og Anvendelseserklæringen?

Derfor er Clarysecs politikkrav bevidst formuleret direkte. Politik for backup og gendannelse for SME’er [BRP-SME], afsnit Styringskrav, politikklausul 5.3.3, kræver:

Gendannelsestest gennemføres mindst kvartalsvist, og resultaterne dokumenteres for at verificere gendannelsesevnen

Den ene sætning ændrer revisionsdialogen. Den flytter organisationen fra “vi har backups” til “vi verificerer gendannelsesevnen efter en fast kadence og opbevarer resultaterne.”

Den samme Politik for backup og gendannelse for SME’er, afsnit Håndhævelse og efterlevelse, politikklausul 8.2.2, styrker kravet om bevismateriale:

Logfiler og registreringer af gendannelsestest opbevares til revisionsformål

Den klausul forhindrer, at gendannelsestest bliver udokumenteret erfaringsviden. Hvis en infrastrukturtekniker siger: “Det testede vi i marts,” men der ikke findes nogen registrering, er det ikke revisionsklart bevismateriale.

Den samme politik adresserer også overlevelsesevne gennem diversitet i lagringen. I afsnit Krav til implementering af politikken, politikklausul 6.3.1.1, skal backups være:

Opbevaret på mindst to lokationer (lokalt og i cloud)

Det er en praktisk baseline. Den erstatter ikke en risikovurdering, men reducerer sandsynligheden for, at ét fysisk eller logisk fejldomæne ødelægger både produktionsdata og backupdata.

ISO 27001:2022-beviskæden starter før testen

Organisationer behandler ofte backup-efterlevelse som et emne for IT-drift. Set med ISO 27001:2022-terminologi er det for snævert. Backup- og gendannelsestest bør være indarbejdet i ledelsessystemet for informationssikkerhed og forbundet med omfang, risiko, kontroludvælgelse, overvågning, intern revision og løbende forbedring.

Clarysecs Zenith Blueprint: En revisors 30-trins køreplan [ZB] starter denne beviskæde, før en gendannelsestest udføres.

I fasen ISMS-grundlag og ledelse, trin 2, interessentbehov og ISMS-omfang, instruerer Zenith Blueprint organisationer i at definere, hvad der er omfattet af ISMS:

Handlingspunkt 4.3: Udarbejd et udkast til en ISMS-omfangserklæring. Angiv, hvad der er inkluderet (forretningsenheder, lokationer, systemer), og eventuelle undtagelser. Del dette udkast med øverste ledelse med henblik på input – de skal acceptere, hvilke dele af forretningen der skal være omfattet af ISMS. Det er også fornuftigt at kvalitetssikre dette omfang mod den tidligere liste over interessentkrav: Dækker omfanget alle de områder, der er nødvendige for at opfylde disse krav?

For gendannelsestest definerer omfanget gendannelsesuniverset. Hvis betalingsplatformen, identitetsudbyderen, ERP-databasen, serveren til styring af endepunkter og cloud object storage er omfattet, skal gendannelsesbevismaterialet omfatte dem eller begrunde, hvorfor det ikke gør. Hvis et system er undtaget, skal undtagelsen kunne forsvares over for interessentkrav, kontraktlige forpligtelser, regulatoriske pligter og behov for forretningskontinuitet.

Det næste led er risiko. I fasen Risikostyring, trin 11, opbygning og dokumentation af risikoregisteret, beskriver Zenith Blueprint risikoregisteret som hovedregistreringen af risici, aktiver, trusler, sårbarheder, eksisterende kontroller, ejere og behandlingsbeslutninger.

En backuprelateret risikoregistrering bør være praktisk, ikke teoretisk.

Det er her, backup bliver revisionsbar. Det er ikke længere “vi har backups.” Det er “vi har identificeret en forretningsrisiko, valgt kontroller, tildelt ejerskab, testet kontrollen og opbevaret bevismateriale.”

Zenith Blueprint, fasen Risikostyring, trin 13, planlægning af risikobehandling og Anvendelseserklæringen, lukker sporbarhedssløjfen:

Kortlæg kontroller til risici og klausuler (sporbarhed)

Nu hvor du har både risikobehandlingsplanen og SoA:

✓ Kortlæg kontroller til risici: I behandlingsplanen i dit risikoregister har du angivet bestemte kontroller for hver risiko. Du kan tilføje en kolonne “Annex A-kontrolreference” til hver risiko og angive kontrolnumrene.

For backup- og gendannelsestest bør Anvendelseserklæringen forbinde risikoscenariet med ISO/IEC 27001:2022 Annex A-kontroller, især 8.13 Information backup, 5.30 ICT readiness for business continuity, 8.14 Redundancy of information processing facilities og 5.29 Information security during disruption.

SoA bør ikke blot markere disse kontroller som anvendelige. Den bør forklare, hvorfor de er anvendelige, hvilket implementeringsbevismateriale der findes, hvem der ejer kontrollen, og hvordan undtagelser håndteres.

Det kontrolkort, revisorer forventer at se

Clarysecs Zenith Controls: Vejledning til tværgående efterlevelse [ZC] opretter ikke separate eller proprietære kontroller. Den organiserer officielle standarder og frameworks i et praktisk tværgående efterlevelsesoverblik, så organisationer kan forstå, hvordan én operationel praksis, såsom gendannelsestest, understøtter flere forpligtelser.

For ISO/IEC 27002:2022 control 8.13 Information backup klassificerer Zenith Controls kontrollen som korrigerende, knyttet til integritet og tilgængelighed, tilpasset cybersikkerhedskonceptet Recover, understøttende den operationelle kapacitet kontinuitet og placeret i sikkerhedsdomænet beskyttelse. Den profil omdefinerer backups som en gendannelseskapacitet, ikke blot en lagringsproces.

For ISO/IEC 27002:2022 control 5.30 ICT readiness for business continuity klassificerer Zenith Controls kontrollen som korrigerende, med fokus på tilgængelighed, tilpasset Respond, understøttende kontinuitet og placeret i sikkerhedsdomænet robusthed. Det er her, gendannelsestest forbindes direkte med operationel robusthed.

For ISO/IEC 27002:2022 control 8.14 Redundancy of information processing facilities identificerer Zenith Controls en forebyggende kontrol med fokus på tilgængelighed, tilpasset Protect, understøttende kontinuitet og asset management samt forbundet med domænerne beskyttelse og robusthed. Redundans og backups er ikke det samme. Redundans hjælper med at forhindre afbrydelser. Backups muliggør genopretning efter tab, korruption eller angreb.

For ISO/IEC 27002:2022 control 5.29 Information security during disruption viser Zenith Controls en bredere profil: forebyggende og korrigerende, dækkende fortrolighed, integritet og tilgængelighed, tilpasset Protect og Respond, understøttende kontinuitet og forbundet med beskyttelse og robusthed. Det er væsentligt under genopretning efter ransomware, fordi gendannelse ikke må skabe nye sikkerhedssvigt, såsom gendannelse af sårbare images, omgåelse af logning eller genaktivering af for omfattende rettigheder.

Den praktiske pointe er enkel. En gendannelsestest er ikke én isoleret kontrol. Den er bevismateriale på tværs af en robusthedskæde.

Det skjulte revisionshul: RTO og RPO uden dokumentation

En af de mest almindelige revisionskonstateringer inden for kontinuitet er afstanden mellem dokumenterede RTO/RPO og reel gendannelsesevne.

Planen for forretningskontinuitet kan angive, at kundeportalen har en RTO på fire timer og en RPO på én time. Backupplatformen kan køre hver time. Men under den første realistiske gendannelsesøvelse opdager teamet, at databasegendannelsen tager tre timer, DNS-ændringer kræver endnu en time, applikationscertifikatet er udløbet, og identitetsintegrationen aldrig blev medtaget i runbooken. Den reelle gendannelsestid er otte timer.

Den dokumenterede RTO var fiktion.

Clarysecs Politik for forretningskontinuitet og katastrofeberedskab for SME’er [BCDR-SME], afsnit Styringskrav, politikklausul 5.2.1.4, gør kontinuitetskravet eksplicit:

Recovery Time Objectives (RTO’er) og Recovery Point Objectives (RPO’er) for hvert system

Det er vigtigt, fordi “gendan kritiske tjenester hurtigt” ikke er målbart. “Gendan databasen til betalingsgodkendelse inden for fire timer med højst én times datatab” er målbart.

Den samme Politik for forretningskontinuitet og katastrofeberedskab for SME’er, afsnit Krav til implementering af politikken, politikklausul 6.4.2, gør test til forbedring:

Alle testresultater skal dokumenteres, og læringspunkter skal registreres og bruges til at opdatere BCP.

En mislykket gendannelse er ikke automatisk en revisionskatastrofe. Det er en mislykket gendannelse uden dokumenteret læring, ejer, korrigering og gentest.

For enterprise-miljøer giver Clarysecs Politik for backup og gendannelse [BRP] mere formel styring. I afsnit Styringskrav, politikklausul 5.1, står der:

En Master Backup Schedule skal vedligeholdes og gennemgås årligt. Den skal angive:

Dette indledende krav etablerer det centrale styringsartefakt. En Master Backup Schedule bør identificere systemer, datasæt, backupfrekvens, opbevaring, lokation, ejerskab, klassificering, afhængigheder og testkadence.

Den samme Politik for backup og gendannelse, afsnit Styringskrav, politikklausul 5.2, forbinder backupforventninger med forretningsmæssig konsekvens:

Alle systemer og applikationer, der er klassificeret som kritiske eller med høj konsekvens i forretningskonsekvensanalysen (BIA), skal:

Det er her, BIA og backupstyring mødes. Kritiske systemer og systemer med høj konsekvens kræver stærkere sikkerhed for gendannelse, hyppigere test, bedre kortlægning af afhængigheder og mere disciplineret bevismateriale.

Én bevismodel for ISO 27001:2022, NIS2, DORA, NIST og COBIT 2019

Compliance-teams kæmper ofte med overlap mellem frameworks. ISO 27001:2022 kræver risikobaseret kontroludvælgelse og bevismateriale. NIS2 forventer foranstaltninger til styring af cybersikkerhedsrisici, herunder forretningskontinuitet. DORA forventer IKT-operationel robusthed, respons og genopretning, backup- og gendannelsesprocedurer samt test af digital operationel robusthed. NIST og COBIT 2019 bruger igen andre begreber.

Løsningen er ikke at opbygge separate backupprogrammer for hvert framework. Løsningen er at opbygge én bevismodel, der kan ses gennem flere revisionslinser.

For NIS2 er den mest direkte reference Article 21 om foranstaltninger til styring af cybersikkerhedsrisici. Article 21(2)(c) omfatter specifikt forretningskontinuitet, såsom backup management, katastrofeberedskab og krisestyring. Article 21(2)(f) er også relevant, fordi den omhandler politikker og procedurer til vurdering af effektiviteten af foranstaltninger til styring af cybersikkerhedsrisici. Gendannelsestest er netop dette: bevismateriale for, at foranstaltningen virker.

For DORA er de stærkeste koblinger Article 11 om respons og genopretning, Article 12 om backuppolitikker og -procedurer, restaurerings- og gendannelsesprocedurer og -metoder samt Article 24 om generelle krav til test af digital operationel robusthed. For finansielle enheder kan en isoleret databasegendannelsestest være utilstrækkelig, hvis forretningstjenesten afhænger af cloudidentitet, forbindelse til betalingsgateway, outsourcet hosting eller managed monitoring. DORA-orienteret bevismateriale bør være på tjenesteniveau, ikke kun på serverniveau.

Det er effektiviteten i en samlet efterlevelsesstrategi. En kvartalsvis gendannelsestest for et betalingssystem kan understøtte ISO 27001:2022 Annex A-bevismateriale, NIS2-kontinuitetsforventninger, DORA-krav til IKT-gendannelse, NIST CSF Recover-resultater og COBIT 2019-styringsrapportering, hvis bevismaterialet struktureres korrekt.

En praktisk gendannelsestest, der bliver til revisionsklart bevismateriale

Vend tilbage til Sarahs mandag morgen-scenarie, men forestil dig, at hendes organisation har forberedt sig med Clarysecs toolkit.

Platformen til godkendelse af betalinger er klassificeret som kritisk i BIA. Den godkendte RTO er fire timer. Den godkendte RPO er én time. Platformen afhænger af en databaseklynge, identitetsudbyder, nøgleboks til hemmeligheder, logningspipeline, DNS, certifikater og udgående e-mail-relay.

Sarahs team opbygger en kvartalsvis gendannelsestest omkring seks trin.

Trin 1: Bekræft omfang og afhængigheder

Ved brug af Zenith Blueprint trin 2 bekræfter Sarah, at betalingsplatformen, databasen, identitetsintegrationen, backupinfrastrukturen og gendannelsesmiljøet er inden for ISMS-omfanget. Juridisk afdeling bekræfter regulatorisk relevans. Finans bekræfter forretningsmæssig konsekvens. IT bekræfter afhængigheder.

Det undgår den klassiske fejl, hvor kun databasen gendannes, mens den autentifikationstjeneste, der kræves for at tilgå applikationen, ignoreres.

Trin 2: Forbind testen med risikoregisteret

Ved brug af Zenith Blueprint trin 11 indeholder risikoregisteret scenariet: “Tab eller kryptering af data i platformen til godkendelse af betalinger forhindrer betalingsaktiviteter og skaber regulatorisk eksponering.”

De eksisterende kontroller omfatter daglige backups, immutable cloudlagring, backupkopier på flere lokationer, kvartalsvis gendannelsestest og dokumenterede gendannelses-runbooks. Risikoejeren er lederen af infrastruktur. Forretningsejeren er Finance Operations. Behandlingsbeslutningen er afbødning.

Trin 3: Kortlæg behandlingen til SoA

Ved brug af Zenith Blueprint trin 13 kortlægger SoA risikoen til ISO/IEC 27001:2022 Annex A-kontrollerne 8.13, 5.30, 8.14 og 5.29. SoA forklarer, at backuptest giver korrigerende gendannelseskapacitet, IKT-kontinuitetsprocedurer understøtter forretningskontinuitet, redundans reducerer sandsynligheden for nedbrud, og sikkerhed under driftsforstyrrelser forhindrer usikre genveje under gendannelse.

Trin 4: Brug politikklausuler som testkriterier

Teamet bruger Politik for backup og gendannelse for SME’er klausul 5.3.3 for kvartalsvis gendannelsestest, klausul 8.2.2 for opbevaring af bevismateriale og klausul 6.3.1.1 for lagring på flere lokationer. Det bruger Politik for forretningskontinuitet og katastrofeberedskab for SME’er klausul 5.2.1.4 for RTO/RPO-mål og klausul 6.4.2 for læringspunkter og BCP-opdateringer.

Trin 5: Udfør gendannelsen og registrér fakta

Gendannelsen udføres i et isoleret gendannelsesmiljø. Teamet registrerer tidsstempler, identifikatorer for backupsæt, gendannelsestrin, fejl, valideringsresultater og godkendelser.

En stærk registrering af gendannelsestest bør indeholde:

Under testen opdager teamet ét problem. Den gendannede applikation kan ikke sende notifikations-e-mails, fordi e-mail-relayets tilladelsesliste ikke omfatter gendannelsesundernettet. Kernefunktionen for betalingsgodkendelse virker, men arbejdsgangen er degraderet.

Trin 6: Registrér læringspunkter og korrigerende handling

Det er her, mange organisationer stopper for tidligt. Clarysecs tilgang flytter problemet ind i forbedringssystemet.

I fasen Revision, gennemgang og forbedring, trin 29, løbende forbedring, bruger Zenith Blueprint en CAPA-log til at spore problembeskrivelse, rodårsag, korrigerende handling, ejer, måldato og status.

Denne ene gendannelsestest producerer nu en revisionsklar beviskæde: politikkrav, bekræftelse af omfang, risikokortlægning, SoA-kortlægning, testplan, udførelsesregistrering, forretningsvalidering, sikkerhedsvalidering, problemregistrering, korrigerende handling og BCP-opdatering.

Hvordan forskellige revisorer undersøger det samme bevismateriale

En stærk pakke med bevismateriale foregriber revisors perspektiv.

En ISO 27001:2022-revisor vil normalt starte med ledelsessystemet. Revisoren vil spørge, om backup- og gendannelseskrav er omfattet, risikobaserede, implementerede, overvågede, internt reviderede og forbedrede. Revisoren vil forvente sporbarhed fra risikoregister til SoA til operationelle registreringer. Revisoren kan også forbinde mislykkede test og korrigerende handlinger til ISO/IEC 27001:2022 clause 10.2 om afvigelse og korrigerende handling.

En DORA-gennemgang vil fokusere på IKT-operationel robusthed for kritiske eller vigtige funktioner. Den vil forvente gendannelse på tjenesteniveau, tredjeparts IKT-afhængigheder, scenariebaseret test, tilsyn fra ledelsesorganet og bevismateriale for, at restaureringsprocedurerne er effektive.

Et NIS2-tilsynsperspektiv vil se efter passende og forholdsmæssige foranstaltninger til styring af cybersikkerhedsrisici. Bevismateriale for backup og katastrofeberedskab bør vise, at væsentlige eller vigtige tjenester kan opretholde eller gendanne driften efter hændelser, og at ledelsen er bekendt med restrisikoen.

En NIST-orienteret assessor vil fokusere på cybersikkerhedsresultater på tværs af Identify, Protect, Detect, Respond og Recover. De kan spørge om immutable backups, privilegeret adgang til backuprepositories, gendannelse i rene miljøer, kommunikation og læringspunkter.

En COBIT 2019- eller ISACA-orienteret revisor vil lægge vægt på styring, procesejerskab, metrikker, ledelsesrapportering og problemsporing. En teknisk elegant gendannelse imponerer mindre, hvis ejerskab og rapportering er uklare.

Det samme bevismateriale kan opfylde alle disse perspektiver, men kun hvis det er fuldstændigt.

Almindelige fejl i gendannelsestest, der skaber revisionskonstateringer

Clarysec ser igen og igen de samme forebyggelige huller i bevismaterialet.

Målet er ikke bureaukrati. Målet er pålidelig gendannelse under pres og bevismateriale, der kan forsvares under revision.

Opbyg en gendannelsespakke til bestyrelsesniveau

Topledere har ikke brug for rå backuplogfiler. De har brug for sikkerhed for, at kritiske tjenester kan gendannes, at undtagelser er kendte, og at forbedringstiltag skrider frem.

For hver kritisk tjeneste bør der rapporteres:

• Tjenestenavn og forretningsejer
• Kritikalitet fra BIA
• Godkendt RTO og RPO
• Dato for seneste gendannelsestest
• Opnået RTO og RPO
• Testresultat
• Åbne korrigerende handlinger
• Tredjepartsafhængigheder, der påvirker gendannelse
• Erklæring om restrisiko
• Næste planlagte test

Denne rapporteringsform bygger bro mellem tekniske teams, revisorer og ledelse. Den understøtter også ISMS-ledelsens gennemgang og robusthedstilsyn under NIS2 og DORA.

Praktisk revisionstjekliste for de næste 30 til 90 dage

Hvis revisionen nærmer sig, så start med det bevismateriale, I allerede har, og luk først de højeste risikohuller.

• Identificér alle kritiske systemer og systemer med høj konsekvens fra BIA.
• Bekræft RTO og RPO for hvert kritisk system.
• Verificér, at hvert kritisk system fremgår af Master Backup Schedule.
• Bekræft backuplokationer, herunder lokale, cloudbaserede, immutable eller adskilte repositories.
• Vælg mindst én nylig gendannelsestest pr. kritisk tjeneste, eller planlæg straks en test.
• Sørg for, at registreringer af gendannelsestest viser omfang, tidsstempler, backupsæt, resultat, opnået RTO/RPO og validering.
• Indhent godkendelse fra forretningsejer for gendannelse på applikationsniveau.
• Validér sikkerhed efter gendannelse, herunder adgangsstyring, logning, overvågning, hemmeligheder, certifikater og sårbarhedseksponering.
• Kortlæg bevismateriale til risikoregisteret og SoA.
• Registrér problemer i CAPA, tildel ejere, og spor gentest.
• Opsummér resultater til ledelsens gennemgang.
• Forbered et tværgående efterlevelsesoverblik til revisionsdialoger om ISO 27001:2022, NIS2, DORA, NIST CSF og COBIT 2019.

Hvis I ikke kan gennemføre alle punkter før revisionen, så vær transparente. Revisorer reagerer som regel bedre på et dokumenteret hul med en plan for korrigerende handling end på vage påstande om modenhed.

Gør gendannelsestest til jeres stærkeste robusthedsbevis

Backup- og gendannelsestest er en af de klareste måder at dokumentere operationel robusthed på. Det er konkret, målbart, forretningsrelevant og direkte forbundet med ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, bestyrelsesrapportering, kundedokumentation og forsikringsgiveres forventninger.

Men kun hvis det dokumenteres korrekt.

Clarysec hjælper organisationer med at gøre backupdrift til revisionsklart bevismateriale gennem Politik for backup og gendannelse, Politik for backup og gendannelse for SME’er, Politik for forretningskontinuitet og katastrofeberedskab for SME’er, Zenith Blueprint og Zenith Controls.

Jeres næste praktiske skridt er enkelt. Vælg én kritisk tjeneste i denne uge. Kør en gendannelsestest mod dens godkendte RTO og RPO. Dokumentér resultatet. Kortlæg det til risikoregisteret og SoA. Registrér alle læringspunkter.

Hvis processen skal kunne gentages på tværs af ISO 27001:2022, NIS2, DORA, NIST og COBIT 2019, giver Clarysecs toolkit jer strukturen til at dokumentere gendannelse uden at bygge en compliance-labyrint fra bunden.