Kernpunt: de maatregel is niet "heb back-ups". Het is "in staat zijn de dienst draaiende te houden, en hem terug te krijgen, binnen een tijd die je vooraf hebt bepaald en aantoonbaar kunt halen". De meeste organisaties hebben de back-ups. Veel minder hebben de herstelobjectieven, het restorebewijs, en de crisisbesluitstructuur die back-ups omzetten in continuïteit.
Artikel 21(2)(c) luidt, in het dictumgedeelte, als bedrijfscontinuïteit, zoals back-upbeheer en disaster recovery, en crisisbeheer. Dat ene onderdeel bundelt drie dingen die de meeste organisaties op verschillende plekken beleggen: een technische back-uppraktijk in handen van infrastructuur, een herstelplan in handen van IT, en een crisisproces in handen van de directie. NIS2 behandelt ze als een maatregel omdat ze vanuit het oogpunt van een toezichthouder een vraag beantwoorden. Als deze dienst stopt, wat gebeurt er dan, en hoe lang duurt het voordat hij terug is?
Dit artikel doorloopt de maatregel in de volgorde waarin je hem zou moeten bouwen: herstelobjectieven afgeleid van de kritikaliteit van de dienst, een back-uparchitectuur die ervan uitgaat dat de aanvaller al binnen is, de continuïteitslaag boven de techniek, crisisbeheer en de botsing ervan met de meldklok van artikel 23, en het bewijs dat aantoont dat het geheel werkt.
Begin bij diensten, niet bij systemen
De maatregel geldt voor de continuïteit van je essentiële of belangrijke diensten. Dat is de analyse-eenheid, en die is niet hetzelfde als de eenheid waarin de meeste IT-teams werken. Een back-upbeleid dat zegt "alle productieservers, dagelijks, 30 dagen bewaring" is een systeemantwoord op een dienstenvraag. Het kan je niet vertellen welke restore je als eerste moet draaien als veertig servers tegelijk versleuteld zijn.
Het startartefact is een korte tabel. Een rij per essentiële of belangrijke dienst. Kolommen voor de maximaal toelaatbare uitval afgestemd met de business, het maximaal toelaatbare gegevensverlies, de systemen die de dienst ondersteunen, de leveranciersafhankelijkheden, en een aangewezen business owner. Tien rijen goed uitgevoerd is meer waard dan honderd rijen gekopieerd uit de CMDB. Deze tabel is ook wat het verschil maakt tussen een discussie en een beslissing terwijl herstel bezig is, omdat de prioriteit vooraf is afgesproken door mensen die niet onder druk stonden.
Uit die tabel volgen de herstelobjectieven vanzelf. De recovery time objective is de maximaal toelaatbare uitval vertaald naar een technisch doel. De recovery point objective is het maximaal toelaatbare gegevensverlies vertaald naar een back-upfrequentie. Geen van beide termen komt voor in de richtlijn, maar artikel 21(2)(f) vereist dat je de effectiviteit van je maatregelen beoordeelt, en effectiviteit kan niet worden beoordeeld zonder een doel om tegen af te meten.
De eerlijkheidstest: vraag de business owner welke uitval hij kan tolereren, en vraag infrastructuur vervolgens wat zij vandaag daadwerkelijk kunnen leveren. Verschillen de twee getallen, dan is dat verschil een risico dat op het register moet staan met een eigenaar die het heeft geaccepteerd. Een ambitieuze recovery time objective van vier uur in een beleid opnemen terwijl de werkelijke capaciteit drie dagen is, is erger dan drie dagen opschrijven, want het beleid wordt dan bewijs tegen jezelf.
Back-uparchitectuur die uitgaat van een compromittering
Back-updesign ging vroeger over hardwarestoringen en menselijke fouten. Beide komen nog steeds voor, en beide worden opgevangen door conventionele back-ups. De dreiging die de discipline heeft hervormd is ransomware, want een ransomware-aanvaller met domeinbeheerdersrechten besteedt tijd aan het opsporen en vernietigen van back-ups voordat de versleuteling wordt geactiveerd. Tegen die tegenstander is een back-upserver die aan hetzelfde domein hangt, met een beheerconsole bereikbaar met dezelfde inloggegevens, onderdeel van het schadegebied in plaats van het herstelpad.
De ontwerpprincipes die volgen zijn niet nieuw, maar ze zijn de moeite waard om helder te benoemen, want dit is waar een toezichthouder of verzekeraar op controleert.
- Ten minste een kopie die een aanvaller niet kan bereiken. Offline, air-gapped, of onveranderbaar met een bewaarslot dat de productiebeheerders niet kunnen opheffen. De test is simpel: als iemand met de hoogste rechten in je omgeving vanmiddag kwaadaardig wordt, welke kopie overleeft dan?
- Scheid het identiteitsvlak. Back-upinfrastructuur zou niet moeten authenticeren tegen dezelfde directory als productie. Een gecompromitteerde directory zou niet ook de hersteldiensten moeten prijsgeven, samen met al het andere.
- Bescherm de configuratie, niet alleen de data. Bestanden terugzetten op een domein dat je niet kunt herbouwen, is een trage manier om erachter te komen dat de directory, de certificate authority en de netwerkconfiguratie nooit binnen de reikwijdte van de back-up vielen.
- Monitor mislukte back-ups als beveiligingsincidenten. Een stille reeks mislukte back-uptaken is óf een operationeel probleem óf de eerste fase van een aanval. In beide gevallen hoort het iemand op te piepen, niet weg te zakken in een rapport dat niemand leest.
- Houd een plan voor een schone herstelomgeving. Herstellen in een netwerk dat nog gecompromitteerd is, infecteert de herstelde systemen opnieuw. Leg vast waar schoon herstel plaatsvindt voordat je het nodig hebt.
Restoretesten is het bewijs, niet de back-uptaak
Een voltooide back-uptaak bewijst dat data is weggeschreven. Het bewijst niet dat data kan worden gelezen, dat de restoreprocedure werkt, dat de persoon met dienst hem kan uitvoeren, of dat het resultaat binnen de recovery time objective terugkomt. Alleen een restoretest bewijst dat, en het is het artefact waar het vaakst om wordt gevraagd tijdens toezicht.
Een restoretest die de moeite waard is om te documenteren heeft vijf eigenschappen. Ze herstelt naar een aparte omgeving in plaats van over productie heen. Ze wordt uitgevoerd door iemand die de geschreven procedure volgt, idealiter niet degene die hem heeft geschreven. Ze meet de verstreken tijd van beslissing tot beschikbaarheid van de dienst. Ze verifieert de herstelde data op applicatieniveau, niet alleen op bestandsniveau. En ze legt vast wat er misging, want elke echte test levert verrassingen op, en een rapport zonder verrassingen leest als een rapport van een test die niet echt is uitgevoerd.
De frequentie zou de kritikaliteit moeten volgen. Jaarlijks is de ondergrens voor alles binnen de reikwijdte, per kwartaal is normaal voor de systemen achter de meest kritieke dienst, en na elke materiële wijziging aan het back-upplatform. Voor het bewijs telt de trend: drie gedateerde rapporten over achttien maanden, met verbeterende hersteltijden en gesloten issues, vertellen een veel beter verhaal dan een vlekkeloze test van vorige maand.
De continuïteitslaag boven de techniek
Disaster recovery brengt de systemen terug. Bedrijfscontinuïteit houdt de dienst draaiende terwijl ze uitliggen. Dit zijn verschillende plannen met verschillende eigenaren, en NIS2 noemt ze beide. Het continuïteitsplan beantwoordt vragen die geen enkel technisch runbook dekt.
- Handmatige noodoplossingen. Wat doet de operatie op papier, telefonisch, of op een losstaande laptop, en hoe lang houdt dat stand? Ziekenhuizen en nutsbedrijven hebben dit doorgaans wel. Software- en dienstenbedrijven vaak niet.
- Prioritering. Als slechts een deel van de dienst kan draaien, wie krijgt het dan. Dit is een bedrijfsbeslissing die vooraf wordt genomen, geen operationele beslissing om 03:00 uur.
- Communicatie. Wat klanten, personeel en toezichthoudende autoriteiten te horen krijgen, door wie, via welk kanaal, en waar de templates staan als e-mail uitligt.
- Afhankelijkheden die je niet controleert. Als de uitval bij een leverancier ligt, is jouw hersteltijd de zijne. Dat hoort thuis in het leverancierscontract en in het continuïteitsplan, niet in een hoopvolle aanname.
- Terugkeer naar normaal. Van een noodoplossing af komen en de data die daartijdens is ontstaan verzoenen, is vaak lastiger dan de uitval zelf. Dat heeft een eigen plan nodig.
Crisisbeheer en de meldklok
Crisisbeheer is het derde element in de maatregel en het element dat het vaakst wordt overgelaten aan de impliciete aanname dat de directie het wel oplost. Onder NIS2 is die aanname kostbaar, want de meldtermijn van artikel 23 loopt gelijktijdig met het herstel. Een vroegtijdige waarschuwing is verschuldigd aan het CSIRT of de bevoegde autoriteit binnen 24 uur na kennisname van een significant incident. Een incidentmelding met een eerste beoordeling volgt binnen 72 uur. Een eindrapport is verschuldigd binnen een maand.
Die termijnen worden niet stilgezet door het feit dat je team bezig is met het herstellen van systemen. De praktische oplossing is structureel: scheid de technische incident commander van de eigenaar van de regelgevingsmelding, en geef elk een plaatsvervanger. Een persoon kan niet zowel een herstel leiden als een melding aan de toezichthouder opstellen, en als hij het toch probeert, is de melding wat erbij inschiet.
Crisisbeheer heeft ook een schriftelijke trigger nodig. Wie roept een crisis uit, op welke criteria, en wat verandert er dan. Zonder dat besteden organisaties de eerste zes uur van een groot incident aan discussiëren of het wel een groot incident is, en dat zijn precies de zes uur die de klok van 24 uur niet kan missen.
Dossier voor artikel 21(2)(c)
- Kritikaliteitstabel per dienst met recovery time en recovery point objectives per essentiële of belangrijke dienst, afgetekend door business owners.
- Back-upbeleid dat de reikwijdte, frequentie, bewaartermijn, versleuteling en de locatie van de offline of onveranderbare kopie vastlegt.
- Architectuurdiagram dat de scheiding tussen productie-identiteit en back-upidentiteit laat zien.
- Gedateerde restoretestrapporten voor ten minste de afgelopen twaalf maanden, met gemeten hersteltijden en gemelde en gesloten issues.
- Bedrijfscontinuïteitsplan met handmatige noodoplossingen, prioriteringsregels en communicatietemplates.
- Crisisbeheerprocedure met de trigger voor het uitroepen, de aangewezen beslisser, de plaatsvervanger, en de aparte eigenaar van de melding aan de toezichthouder.
- Oefeningsrapport van de afgelopen twaalf maanden dat een scenario dekt waarin back-ups het herstelpad zijn.
- Gedocumenteerde verdeling van gedeelde verantwoordelijkheid voor elke clouddienst die een dienst binnen de reikwijdte ondersteunt, met vermelding van wat de provider back-upt en wat jij doet.
Waar de cloudaanname breekt
Een terugkerend gat in verder volwassen programma's is de aanname dat software as a service betekent dat iemand anders de continuïteit regelt. Platformleveranciers leveren infrastructuurweerbaarheid en meestal korte hersteltermijnen voor data die zij als hun eigen verantwoordelijkheid beschouwen. Waar ze je in het algemeen niet tegen beschermen is verwijdering door je eigen beheerders, corruptie die via je eigen integraties wordt verspreid, een gecompromitteerd account in je tenant, of een contractuele beëindiging die je data met zich meeneemt.
Documenteer de verdeling per dienst. Wat de provider back-upt, voor hoe lang, hoe je een restore aanvraagt, hoe lang dat duurt, en wat je zelfstandig back-upt. Toets het antwoord vervolgens aan de herstelobjectieven in je kritikaliteitstabel. Als het standaard restorevenster van een provider langer is dan je gestelde objectief, heb je óf een gat in de maatregelen óf een objectief dat moet worden herzien. Beide zijn prima uitkomsten. De mismatch ontdekken tijdens een incident is dat niet.
Veelgestelde vragen
Wat vereist NIS2 voor back-ups?
Artikel 21(2)(c) noemt bedrijfscontinuïteit, zoals back-upbeheer en disaster recovery, en crisisbeheer, als een van de tien minimale maatregelen. De richtlijn schrijft geen back-uptechnologie, bewaartermijn of schema voor. Ze vereist maatregelen die passend zijn bij het risico, wat in de praktijk betekent: back-ups die de systemen dekken die je essentiële of belangrijke diensten ondersteunen, die een aanvaller met domeinrechten overleven, en die aantoonbaar zijn hersteld.
Vereist NIS2 onveranderbare of offline back-ups?
Niet met naam. Maar het risico dat NIS2 je vraagt te beheren omvat ransomware, en moderne ransomware verwijdert bereikbare back-ups voordat productie wordt versleuteld. Een back-uparchitectuur die een aanvaller met domeinbeheerdersrechten kan verwijderen beheert dat risico niet, dus een offline of onveranderbare kopie is de normale manier om aan de maatregel te voldoen, en het is wat auditors en verzekeraars nu verwachten.
Hoe vaak moeten we restores testen onder NIS2?
De richtlijn kent geen interval. Twaalf maanden is de praktische ondergrens omdat dit aansluit bij de audit- en verzekeringscyclus, en per kwartaal is normaal voor de systemen achter de meest kritieke dienst. Belangrijker dan de frequentie is dat de test een echte restore is met een gemeten hersteltijd, geen verificatie dat de back-uptaak is voltooid.
Wat is het verschil tussen disaster recovery en bedrijfscontinuïteit onder NIS2?
Disaster recovery is het technisch herstellen van systemen en data. Bedrijfscontinuïteit is hoe de dienst blijft draaien voor de mensen die ervan afhankelijk zijn terwijl systemen uitliggen, inclusief handmatige noodoplossingen, communicatie en prioritering. NIS2 noemt beide plus crisisbeheer, de besluitvormingslaag daarboven.
Moeten recovery time objectives worden gedocumenteerd voor NIS2?
De richtlijn gebruikt de termen RTO en RPO niet, maar vereist maatregelen die evenredig zijn met het risico en een beoordeling van hun effectiviteit. Zonder gedocumenteerde herstelobjectieven per dienst is er geen norm om effectiviteit tegen af te meten, dus in de praktijk worden ze verwacht en zijn ze een van de eerste opgevraagde artefacten.
Hoe verhoudt bedrijfscontinuïteit zich tot de meldtermijnen van artikel 23?
Ze lopen parallel en strijden om dezelfde mensen. De vroegtijdige waarschuwing van 24 uur, de incidentmelding van 72 uur en het eindrapport na een maand vervallen allemaal terwijl het herstel bezig is. Een continuïteitsplan dat niemand aanwijst die verantwoordelijk is voor de melding aan de toezichthouder, los van degene die het technisch herstel leidt, mist doorgaans een van de twee.
Neemt een clouddienst de back-upverplichting weg?
Nee. Cloudplatforms bieden infrastructuurweerbaarheid, wat beschermt tegen hardware- en datacenterstoringen. Ze beschermen niet tegen verwijdering, corruptie, misconfiguratie of een gecompromitteerd beheerdersaccount in je eigen tenant. De verplichting blijft bij de entiteit liggen, en het model van gedeelde verantwoordelijkheid moet per dienst worden gedocumenteerd zodat de grens expliciet is.
Kun je bewijzen dat je op tijd zou herstellen?
Wij bouwen de kritikaliteitstabel, stellen herstelobjectieven vast met de business, beoordelen de back-uparchitectuur tegen een ransomwarescenario, en voeren de restoretest uit die het bewijs oplevert.
Boek een continuïteits-readinessreview