Auditklare hersteltesten voor ISO 27001, NIS2 en DORA

Het is 07:40 op maandagochtend en Sarah, de CISO van een snelgroeiende fintechorganisatie, ziet in realtime een crisis ontstaan. De CFO kan het platform voor betalingsgoedkeuring niet openen. De servicedesk denkt aan een opslagprobleem. Het infrastructuurteam vermoedt ransomware, omdat meerdere gedeelde mappen inmiddels versleutelde bestandsnamen tonen. De CEO wil weten of de salarisverwerking veilig is. Juridische zaken vraagt of toezichthouders moeten worden geïnformeerd.

Sarah opent het back-updashboard. Het staat vol groene vinkjes.

Dat zou geruststellend moeten zijn, maar dat is het niet. Een succesvolle back-upjob is geen bewijs van een succesvol herstel. Het is alsof er een brandblusser aan de muur hangt zonder te weten of die gevuld, bereikbaar en onder druk bruikbaar is.

Sarahs organisatie valt binnen de scope van ISO 27001:2022, wordt onder NIS2 aangemerkt als belangrijke entiteit en valt als financiële entiteit onder DORA. De vraag is niet langer of de organisatie back-ups uitvoert. De vraag is of zij de juiste systemen kan herstellen, naar het juiste moment in de tijd, binnen goedgekeurde Recovery Time Objectives en Recovery Point Objectives, met bewijsmateriaal dat sterk genoeg is voor een auditor, toezichthouder, klant, verzekeraar en bestuur.

Daar falen veel back-upprogramma’s. Ze hebben back-upjobs. Ze hebben dashboards. Ze hebben snapshots. Soms hebben ze zelfs cloudopslag. Maar zodra de druk toeneemt, kunnen ze niet aantonen dat kritieke systemen herstelbaar zijn, dat hersteltests zijn uitgevoerd, dat mislukte tests corrigerende maatregelen hebben geactiveerd en dat het bewijsmateriaal eenduidig aansluit op de verwachtingen van ISO 27001:2022, NIS2, DORA, NIST en COBIT 2019.

Back-up- en hersteltesten is een vraagstuk van operationele weerbaarheid op bestuursniveau geworden. NIS2 verhoogt de verwachtingen voor cyberbeveiligingsrisicobeheer en bedrijfscontinuïteit. DORA maakt digitale operationele ICT-weerbaarheid een kernverplichting voor financiële entiteiten en hun kritieke ICT-dienstverleners. ISO 27001:2022 biedt de managementsysteemstructuur voor scope, risico, selectie van beheersmaatregelen, bewijsmateriaal, audits en voortdurende verbetering.

De praktische uitdaging is om een technische hersteltest om te zetten in auditklaar bewijsmateriaal.

Back-up is pas bewijsmateriaal wanneer herstel is aangetoond

Een back-upjob die succesvol wordt voltooid, is slechts een gedeeltelijk signaal. Het laat zien dat gegevens ergens naartoe zijn gekopieerd. Het bewijst niet dat de gegevens kunnen worden hersteld, dat applicatieafhankelijkheden intact zijn, dat encryptiesleutels beschikbaar zijn, dat identiteitsdiensten nog werken of dat het herstelde systeem echte bedrijfsprocessen ondersteunt.

Auditors weten dit. Toezichthouders weten dit. Aanvallers weten dit.

Een technisch volwassen auditor stopt niet bij een schermafbeelding met 97 procent succesvolle back-upjobs. Die zal vragen:

• Welke systemen zijn kritiek of hebben een hoge impact?
• Welke RTO en RPO gelden voor elk systeem?
• Wanneer is de laatste hersteltest uitgevoerd?
• Was de test volledig, gedeeltelijk, op applicatieniveau, databaseniveau of bestandsniveau?
• Wie heeft het bedrijfsproces na herstel gevalideerd?
• Zijn fouten geregistreerd als non-conformiteiten of verbeteracties?
• Hoe lang worden logs en hersteltestregistraties bewaard?
• Zijn back-upkopieën over gescheiden locaties verdeeld?
• Hoe sluit het bewijsmateriaal aan op het risicoregister en de Verklaring van Toepasselijkheid?

Daarom is de beleidstaal van Clarysec bewust direct. De Backup and Restore Policy-sme [BRP-SME], sectie governancevereisten, beleidsclausule 5.3.3, vereist:

Hersteltests worden ten minste elk kwartaal uitgevoerd en de resultaten worden gedocumenteerd om herstelbaarheid te verifiëren

Die ene zin verandert het auditgesprek. De organisatie verschuift van “wij hebben back-ups” naar “wij verifiëren herstelbaarheid volgens een vastgestelde frequentie en bewaren de resultaten”.

Dezelfde Backup and Restore Policy-sme, sectie handhaving en naleving, beleidsclausule 8.2.2, versterkt de verplichting voor bewijsmateriaal:

Logboeken en registraties van hersteltests worden bewaard voor auditdoeleinden

Die clausule voorkomt dat hersteltesten ongedocumenteerde kennis van enkele medewerkers wordt. Als een infrastructuuringenieur zegt: “Dat hebben we in maart getest”, maar er bestaat geen registratie, dan is het geen auditklaar bewijsmateriaal.

Hetzelfde beleid behandelt ook overleefbaarheid door diversiteit in opslag. In de sectie vereisten voor beleidsimplementatie, beleidsclausule 6.3.1.1, moeten back-ups worden:

Opgeslagen op ten minste twee locaties (lokaal en cloud)

Dit is een praktische baseline. Het vervangt geen risicobeoordeling, maar verkleint de kans dat één fysiek of logisch foutdomein zowel productiegegevens als back-upgegevens vernietigt.

De bewijsketen voor ISO 27001:2022 begint vóór de test

Organisaties behandelen naleving rond back-ups vaak als een onderwerp voor IT-operaties. In termen van ISO 27001:2022 is dat te beperkt. Back-up- en hersteltesten moeten zijn ingebed in het Information Security Management System, gekoppeld aan scope, risico, selectie van beheersmaatregelen, monitoring, interne audit en voortdurende verbetering.

De Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] van Clarysec laat deze bewijsketen beginnen voordat een hersteltest wordt uitgevoerd.

In de fase ISMS-fundament en leiderschap, stap 2, stakeholderbehoeften en ISMS-scope, instrueert de Zenith Blueprint organisaties om te definiëren wat binnen het ISMS valt:

Actiepunt 4.3: Stel een ISMS-scopeverklaring op. Noteer wat is inbegrepen (bedrijfseenheden, locaties, systemen) en eventuele uitsluitingen. Deel dit concept met het topmanagement voor input – zij moeten instemmen met welke onderdelen van de organisatie onder het ISMS vallen. Het is ook verstandig deze scope te toetsen aan uw eerdere lijst met stakeholdervereisten: dekt uw scope alle gebieden die nodig zijn om aan die vereisten te voldoen?

Voor hersteltesten definieert de scope het hersteluniversum. Als het platform voor betalingsgoedkeuring, de identiteitsprovider, ERP-database, endpointbeheerserver en cloudobjectopslag binnen de scope vallen, moet het herstelbewijsmateriaal deze omvatten of onderbouwen waarom dat niet het geval is. Als een systeem is uitgesloten, moet die uitsluiting verdedigbaar zijn ten opzichte van stakeholdervereisten, contractuele verplichtingen, wettelijke verplichtingen en behoeften op het gebied van bedrijfscontinuïteit.

De volgende schakel is risico. In de fase risicobeheer, stap 11, opbouw en documentatie van het risicoregister, beschrijft de Zenith Blueprint het risicoregister als de centrale registratie van risico’s, bedrijfsmiddelen, dreigingen, kwetsbaarheden, bestaande beheersmaatregelen, eigenaren en behandelingsbesluiten.

Een back-upgerelateerde risicovermelding moet praktisch zijn, niet theoretisch.

Hier wordt back-up auditeerbaar. Het is niet langer “wij hebben back-ups”. Het wordt: “wij hebben een bedrijfsrisico geïdentificeerd, beheersmaatregelen geselecteerd, eigenaarschap toegewezen, de beheersmaatregel getest en bewijsmateriaal bewaard”.

De Zenith Blueprint, fase risicobeheer, stap 13, planning van risicobehandeling en Verklaring van Toepasselijkheid, sluit de traceerbaarheidslus:

Beheersmaatregelen koppelen aan risico’s en clausules (traceerbaarheid)

Nu u zowel het risicobehandelingsplan als de SoA hebt:

✓ Koppel beheersmaatregelen aan risico’s: in het behandelplan van uw risicoregister hebt u voor elk risico bepaalde beheersmaatregelen opgenomen. U kunt aan elk risico een kolom “Annex A Control Reference” toevoegen en daarin de beheersmaatregelnummers opnemen.

Voor back-up- en hersteltesten moet de Verklaring van Toepasselijkheid het risicoscenario koppelen aan ISO/IEC 27001:2022 Bijlage A-beheersmaatregelen, in het bijzonder 8.13 Informatieback-up, 5.30 ICT-gereedheid voor bedrijfscontinuïteit, 8.14 Redundantie van informatieverwerkingsfaciliteiten en 5.29 Informatiebeveiliging tijdens verstoring.

De SoA mag deze beheersmaatregelen niet alleen als van toepassing markeren. Zij moet uitleggen waarom ze van toepassing zijn, welk implementatiebewijsmateriaal bestaat, wie eigenaar is van de beheersmaatregel en hoe uitzonderingen worden afgehandeld.

De mapping van beheersmaatregelen die auditors verwachten te zien

De Zenith Controls: The Cross-Compliance Guide [ZC] van Clarysec creëert geen afzonderlijke of propriëtaire beheersmaatregelen. Het ordent officiële normen en raamwerken in een praktische cross-complianceweergave, zodat organisaties begrijpen hoe één operationele praktijk, zoals hersteltesten, meerdere verplichtingen ondersteunt.

Voor ISO/IEC 27002:2022 beheersmaatregel 8.13 Informatieback-up classificeert Zenith Controls de beheersmaatregel als corrigerend, gekoppeld aan integriteit en beschikbaarheid, afgestemd op het cyberbeveiligingsconcept Recover, ondersteunend aan de capaciteit voor operationele continuïteit en gepositioneerd in het beveiligingsdomein Protection. Dat profiel herkadert back-ups als herstelcapaciteit, niet alleen als opslagproces.

Voor ISO/IEC 27002:2022 beheersmaatregel 5.30 ICT-gereedheid voor bedrijfscontinuïteit classificeert Zenith Controls de beheersmaatregel als corrigerend, gericht op beschikbaarheid, afgestemd op Respond, ondersteunend aan continuïteit en gepositioneerd in het beveiligingsdomein Resilience. Hier wordt hersteltesten rechtstreeks gekoppeld aan operationele weerbaarheid.

Voor ISO/IEC 27002:2022 beheersmaatregel 8.14 Redundantie van informatieverwerkingsfaciliteiten identificeert Zenith Controls een preventieve beheersmaatregel gericht op beschikbaarheid, afgestemd op Protect, ondersteunend aan continuïteit en assetmanagement, en gekoppeld aan de domeinen Protection en Resilience. Redundantie en back-ups zijn niet hetzelfde. Redundantie helpt onderbreking te voorkomen. Back-ups maken herstel mogelijk na verlies, corruptie of aanval.

Voor ISO/IEC 27002:2022 beheersmaatregel 5.29 Informatiebeveiliging tijdens verstoring toont Zenith Controls een breder profiel: preventief en corrigerend, gericht op vertrouwelijkheid, integriteit en beschikbaarheid, afgestemd op Protect en Respond, ondersteunend aan continuïteit en gekoppeld aan Protection en Resilience. Dit is relevant tijdens herstel na ransomware, omdat herstel geen nieuwe beveiligingsfouten mag veroorzaken, zoals het herstellen van kwetsbare images, het omzeilen van logging of het opnieuw activeren van te ruime privileges.

De praktische les is eenvoudig. Een hersteltest is geen geïsoleerde beheersmaatregel. Het is bewijsmateriaal in een keten van weerbaarheid.

Het verborgen audithiaat: RTO en RPO zonder bewijs

Een van de meest voorkomende bevindingen bij continuïteitsaudits is de kloof tussen gedocumenteerde RTO/RPO en werkelijke herstelcapaciteit.

Het bedrijfscontinuïteitsplan kan bepalen dat het klantenportaal een RTO van vier uur en een RPO van één uur heeft. Het back-upplatform kan elk uur draaien. Maar tijdens de eerste realistische hersteloefening ontdekt het team dat het databaseherstel drie uur duurt, DNS-wijzigingen nog een uur vragen, het applicatiecertificaat is verlopen en de identiteitsintegratie nooit in het hersteldraaiboek is opgenomen. De werkelijke hersteltijd is acht uur.

De gedocumenteerde RTO was fictie.

De Business Continuity Policy and Disaster Recovery Policy-sme [BCDR-SME] van Clarysec, sectie governancevereisten, beleidsclausule 5.2.1.4, maakt de continuïteitsvereiste expliciet:

Recovery Time Objectives (RTO’s) en Recovery Point Objectives (RPO’s) voor elk systeem

Dat is belangrijk, omdat “kritieke diensten snel herstellen” niet meetbaar is. “De database voor betalingsgoedkeuring binnen vier uur herstellen met maximaal één uur gegevensverlies” is wel meetbaar.

Dezelfde Business Continuity Policy and Disaster Recovery Policy-sme, sectie vereisten voor beleidsimplementatie, beleidsclausule 6.4.2, zet testen om in verbetering:

Alle testresultaten moeten worden gedocumenteerd en geleerde lessen moeten worden geregistreerd en gebruikt om het BCP te actualiseren.

Een mislukte herstelactie is niet automatisch een auditprobleem. Een mislukte herstelactie zonder gedocumenteerde les, eigenaar, correctie en hertest is dat wel.

Voor enterprise-omgevingen biedt de Backup and Restore Policy [BRP] van Clarysec formelere governance. In de sectie governancevereisten, beleidsclausule 5.1, staat:

Een centraal back-upschema moet worden onderhouden en jaarlijks worden beoordeeld. Het moet specificeren:

Die openingsvereiste stelt het kernartefact voor governance vast. Een centraal back-upschema moet systemen, gegevenssets, back-upfrequentie, bewaartermijn, locatie, eigenaarschap, classificatie, afhankelijkheden en testfrequentie identificeren.

Dezelfde Backup and Restore Policy, sectie governancevereisten, beleidsclausule 5.2, koppelt back-upverwachtingen aan bedrijfsimpact:

Alle systemen en toepassingen die in de Business Impact Analysis (BIA) als kritiek of met hoge impact zijn geclassificeerd, moeten:

Hier komen BIA en back-upgovernance samen. Kritieke systemen en systemen met hoge impact vereisen sterkere assurance over herstel, frequentere tests, beter in kaart gebrachte afhankelijkheden en discipline in bewijsmateriaal.

Eén bewijsmodel voor ISO 27001:2022, NIS2, DORA, NIST en COBIT 2019

Compliance-teams worstelen vaak met overlap tussen raamwerken. ISO 27001:2022 vraagt om risicogebaseerde selectie van beheersmaatregelen en bewijsmateriaal. NIS2 verwacht cyberbeveiligingsrisicobeheersmaatregelen, waaronder bedrijfscontinuïteit. DORA verwacht digitale operationele ICT-weerbaarheid, respons en herstel, back-up- en herstelprocedures en testen van digitale operationele weerbaarheid. NIST en COBIT 2019 gebruiken weer andere terminologie.

De oplossing is niet om voor elk raamwerk een afzonderlijk back-upprogramma te bouwen. De oplossing is één bewijsmodel dat via meerdere auditlenzen kan worden bekeken.

Voor NIS2 is de meest directe verwijzing Article 21 over cyberbeveiligingsrisicobeheersmaatregelen. Article 21(2)(c) omvat specifiek bedrijfscontinuïteit, zoals back-upbeheer, herstel na verstoringen en crisismanagement. Article 21(2)(f) is eveneens relevant, omdat het betrekking heeft op beleid en procedures om de doeltreffendheid van cyberbeveiligingsrisicobeheersmaatregelen te beoordelen. Hersteltesten is precies dat: bewijsmateriaal dat de maatregel werkt.

Voor DORA liggen de sterkste koppelingen bij Article 11 over respons en herstel, Article 12 over back-upbeleid en -procedures, herstel- en terugzetprocedures en -methoden, en Article 24 over algemene vereisten voor testen van digitale operationele weerbaarheid. Voor financiële entiteiten kan een databasehersteltest alleen onvoldoende zijn als de bedrijfsdienst afhankelijk is van cloudidentiteit, connectiviteit met een betalingsgateway, uitbestede hosting of beheerde monitoring. DORA-bewijsmateriaal moet op dienstniveau liggen, niet alleen op serverniveau.

Dit is de efficiëntie van een geïntegreerde compliancestrategie. Een kwartaalgewijze hersteltest voor een betalingssysteem kan bewijsmateriaal ondersteunen voor ISO 27001:2022 Bijlage A, continuïteitsverwachtingen onder NIS2, ICT-herstelvereisten van DORA, Recover-uitkomsten van NIST CSF en governancerapportage onder COBIT 2019, mits het bewijsmateriaal correct is gestructureerd.

Een praktische hersteltest die auditbewijsmateriaal wordt

Keer terug naar Sarahs maandagochtendscenario, maar stel dat haar organisatie zich heeft voorbereid met de toolkit van Clarysec.

Het platform voor betalingsgoedkeuring is in de BIA als kritiek geclassificeerd. De goedgekeurde RTO is vier uur. De goedgekeurde RPO is één uur. Het platform is afhankelijk van een databasecluster, identiteitsprovider, geheimenkluis, logverwerkingsketen, DNS, certificaten en uitgaande mailrelay.

Sarahs team bouwt een kwartaalgewijze hersteltest rond zes stappen.

Stap 1: Bevestig scope en afhankelijkheden

Met Zenith Blueprint stap 2 bevestigt Sarah dat het betalingsplatform, de database, identiteitsintegratie, back-upinfrastructuur en herstelomgeving binnen de ISMS-scope vallen. Juridische zaken bevestigt de regelgevende relevantie. Finance bevestigt de bedrijfsimpact. IT bevestigt de afhankelijkheden.

Dit voorkomt de klassieke fout waarbij alleen de database wordt hersteld terwijl de authenticatiedienst die nodig is om toegang te krijgen tot de applicatie buiten beschouwing blijft.

Stap 2: Koppel de test aan het risicoregister

Met Zenith Blueprint stap 11 bevat het risicoregister het scenario: “Verlies of versleuteling van gegevens van het platform voor betalingsgoedkeuring verhindert betalingsprocessen en veroorzaakt blootstelling aan regelgeving.”

De huidige beheersmaatregelen omvatten dagelijkse back-ups, onveranderbare cloudopslag, back-upkopieën op meerdere locaties, kwartaalgewijze hersteltesten en gedocumenteerde hersteldraaiboeken. De risico-eigenaar is het Hoofd Infrastructuur. De bedrijfseigenaar is Finance Operations. Het behandelingsbesluit is beperken.

Stap 3: Koppel de behandeling aan de SoA

Met Zenith Blueprint stap 13 koppelt de SoA het risico aan ISO/IEC 27001:2022 Bijlage A-beheersmaatregelen 8.13, 5.30, 8.14 en 5.29. De SoA legt uit dat back-uptesten corrigerende herstelcapaciteit biedt, ICT-continuïteitsprocedures bedrijfscontinuïteit ondersteunen, redundantie de kans op uitval verkleint en beveiliging tijdens verstoring onveilige shortcuts tijdens herstel voorkomt.

Stap 4: Gebruik beleidsclausules als testcriteria

Het team gebruikt Backup and Restore Policy-sme clausule 5.3.3 voor kwartaalgewijze hersteltesten, clausule 8.2.2 voor bewaring van bewijsmateriaal en clausule 6.3.1.1 voor opslag op meerdere locaties. Het gebruikt Business Continuity Policy and Disaster Recovery Policy-sme clausule 5.2.1.4 voor RTO/RPO-doelen en clausule 6.4.2 voor geleerde lessen en BCP-actualisaties.

Stap 5: Voer het herstel uit en registreer feiten

Het herstel wordt uitgevoerd in een geïsoleerde herstelomgeving. Het team registreert tijdstempels, identificatoren van back-upsets, herstelstappen, fouten, validatieresultaten en goedkeuringen.

Een sterke registratie van een hersteltest moet het volgende bevatten:

Tijdens de test ontdekt het team één probleem. De herstelde applicatie kan geen notificatie-e-mails verzenden, omdat de toelatingslijst van de mailrelay het herstelsubnet niet bevat. De kernfunctie voor betalingsgoedkeuring werkt, maar de workflow is gedegradeerd.

Stap 6: Registreer geleerde lessen en corrigerende maatregelen

Hier stoppen veel organisaties te vroeg. De aanpak van Clarysec brengt het probleem onder in het verbeteringssysteem.

In de fase audit, beoordeling en verbetering, stap 29, voortdurende verbetering, gebruikt de Zenith Blueprint een CAPA-logboek om de probleembeschrijving, oorzaakanalyse, corrigerende maatregel, eigenaar, streefdatum en status te volgen.

Deze ene hersteltest levert nu een auditklare bewijsketen op: beleidsvereiste, bevestiging van scope, risicomapping, SoA-mapping, testplan, uitvoeringsregistratie, bedrijfsvalidatie, beveiligingsvalidatie, probleemregistratie, corrigerende maatregel en BCP-actualisatie.

Hoe verschillende auditors hetzelfde bewijsmateriaal beoordelen

Een sterk bewijspakket anticipeert op het perspectief van de auditor.

Een ISO 27001:2022-auditor begint meestal bij het managementsysteem. Die zal vragen of back-up- en herstelvereisten zijn gescopeerd, risicogebaseerd zijn, zijn geïmplementeerd, worden gemonitord, intern zijn geaudit en worden verbeterd. De auditor verwacht traceerbaarheid van risicoregister naar SoA en operationele registraties. Ook kan de auditor mislukte tests en corrigerende maatregelen koppelen aan ISO/IEC 27001:2022 clause 10.2 over non-conformiteit en corrigerende maatregelen.

Een DORA-beoordelaar richt zich op digitale operationele ICT-weerbaarheid voor kritieke of belangrijke functies. Die wil herstel op dienstniveau zien, afhankelijkheden van derde ICT-partijen, scenariogebaseerde tests, toezicht door het leidinggevend orgaan en bewijsmateriaal dat herstelprocedures doeltreffend zijn.

Een NIS2-toezichtsperspectief zoekt naar passende en evenredige cyberbeveiligingsrisicobeheersmaatregelen. Bewijsmateriaal voor back-up en herstel na verstoringen moet laten zien dat essentiële of belangrijke diensten na incidenten activiteiten kunnen handhaven of herstellen, waarbij het management zich bewust is van het restrisico.

Een NIST-georiënteerde assessor richt zich op cyberbeveiligingsuitkomsten over Identify, Protect, Detect, Respond en Recover. Die kan vragen naar onveranderbare back-ups, geprivilegieerde toegang tot back-uprepositories, herstel naar schone omgevingen, communicatie en geleerde lessen.

Een COBIT 2019- of ISACA-achtige auditor legt nadruk op governance, proceseigenaarschap, metrieken, managementrapportage en issue-opvolging. Een technisch elegante herstelactie maakt minder indruk als eigenaarschap en rapportage onduidelijk zijn.

Hetzelfde bewijsmateriaal kan al deze perspectieven ondersteunen, maar alleen als het volledig is.

Veelvoorkomende tekortkomingen in hersteltesten die auditbevindingen veroorzaken

Clarysec ziet herhaaldelijk dezelfde vermijdbare hiaten in bewijsmateriaal.

Het doel is geen bureaucratie. Het doel is betrouwbaar herstel onder druk en verdedigbaar bewijsmateriaal tijdens audits.

Bouw een herstelbewijspakket op bestuursniveau

Bestuurders hebben geen ruwe back-uplogs nodig. Zij hebben assurance nodig dat kritieke diensten herstelbaar zijn, uitzonderingen bekend zijn en verbeteracties voortgang boeken.

Rapporteer per kritieke dienst:

• Dienstnaam en bedrijfseigenaar
• Kritikaliteit uit de BIA
• Goedgekeurde RTO en RPO
• Datum van de laatste hersteltest
• Behaalde RTO en RPO
• Testresultaat
• Openstaande corrigerende maatregelen
• Afhankelijkheden van derden die herstel beïnvloeden
• Verklaring van restrisico
• Volgende geplande test

Deze rapportagestijl slaat een brug tussen technische teams, auditors en leidinggevenden. Zij ondersteunt ook ISMS-managementbeoordelingen en toezicht op weerbaarheid onder NIS2 en DORA.

Praktische auditchecklist voor de komende 30 tot 90 dagen

Als uw audit nadert, begin dan met het bewijsmateriaal dat u al hebt en sluit eerst de hiaten met het hoogste risico.

• Identificeer alle kritieke systemen en systemen met hoge impact uit de BIA.
• Bevestig RTO en RPO voor elk kritiek systeem.
• Verifieer dat elk kritiek systeem voorkomt in het centrale back-upschema.
• Bevestig back-uplocaties, waaronder lokale, cloud-, onveranderbare of gescheiden repositories.
• Selecteer ten minste één recente hersteltest per kritieke dienst of plan direct een test.
• Zorg dat hersteltestregistraties scope, tijdstempels, back-upset, resultaat, behaalde RTO/RPO en validatie tonen.
• Verkrijg goedkeuring van de bedrijfseigenaar voor herstel op applicatieniveau.
• Valideer beveiliging na herstel, inclusief toegangscontrole, logging, monitoring, geheimen, certificaten en blootstelling aan kwetsbaarheden.
• Koppel bewijsmateriaal aan het risicoregister en de SoA.
• Registreer issues in CAPA, wijs eigenaren toe en volg hertests op.
• Vat resultaten samen voor de directiebeoordeling.
• Bereid een cross-complianceweergave voor auditgesprekken over ISO 27001:2022, NIS2, DORA, NIST CSF en COBIT 2019 voor.

Als u niet elk item vóór de audit kunt afronden, wees dan transparant. Auditors reageren doorgaans beter op een gedocumenteerd hiaat met een plan voor corrigerende maatregelen dan op vage claims over volwassenheid.

Maak hersteltesten uw sterkste bewijs voor weerbaarheid

Back-up- en hersteltesten is een van de duidelijkste manieren om operationele weerbaarheid aan te tonen. Het is tastbaar, meetbaar, bedrijfsrelevant en rechtstreeks verbonden met ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, bestuursrapportage, assurance richting klanten en verwachtingen van verzekeraars.

Maar alleen als het goed wordt gedocumenteerd.

Clarysec helpt organisaties back-upoperaties om te zetten in auditklaar bewijsmateriaal via de Backup and Restore Policy, Backup and Restore Policy-sme, Business Continuity Policy and Disaster Recovery Policy-sme, Zenith Blueprint en Zenith Controls.

Uw volgende praktische stap is eenvoudig. Kies deze week één kritieke dienst. Voer een hersteltest uit tegen de goedgekeurde RTO en RPO. Documenteer het resultaat. Koppel het aan het risicoregister en de SoA. Registreer elke geleerde les.

Als u wilt dat dit proces herhaalbaar is voor ISO 27001:2022, NIS2, DORA, NIST en COBIT 2019, geeft de toolkit van Clarysec u de structuur om herstel aan te tonen zonder vanaf nul een compliancedoolhof te bouwen.