Welke systemen moet je als eerste herstellen na een grote verstoring?

Begin met de systemen die je organisatie minimaal nodig heeft om operationeel te blijven: denk aan identiteitsbeheer, netwerktoegang, e-mail en de bedrijfskritische applicaties die dagelijkse processen ondersteunen. Welke systemen dat precies zijn, verschilt per organisatie, maar de volgorde van herstel bepaal je altijd op basis van bedrijfsimpact, onderlinge afhankelijkheden en hoe snel een systeem beschikbaar moet zijn. De secties hieronder werken die volgorde stap voor stap uit.

Wat bepaalt de herstelvolgorde na een cyberincident?

De herstelvolgorde na een verstoring wordt bepaald door drie factoren: hoe groot de operationele impact is als een systeem uitvalt, hoe afhankelijk andere systemen van dat systeem zijn, en hoe snel de organisatie dat systeem nodig heeft om minimaal te kunnen blijven functioneren. Systemen met de hoogste impact, de meeste afhankelijkheden en de kortste toegestane uitvaltijd krijgen prioriteit.

Concreet betekent dit dat je per systeem twee vragen stelt: wat valt er stil als dit systeem niet beschikbaar is, en hoeveel tijd heeft de organisatie voordat dat echt een probleem wordt? Die tijdgrens heet de Recovery Time Objective (RTO). Hoe korter de RTO, hoe hoger de herstelprioriteit.

Daarnaast speelt de volgorde van technische afhankelijkheden een grote rol. Je kunt een applicatieserver niet herstellen als de identiteitsinfrastructuur nog niet werkt. Je kunt geen e-mail versturen als de DNS-configuratie ontbreekt. De logische volgorde van herstel volgt daarmee de architectuur van je omgeving, niet de voorkeur van individuele afdelingen.

Wat is een Minimum Viable Company en welke systemen vallen daaronder?

Een Minimum Viable Company (MVC) is de minimale set systemen, applicaties en processen die een organisatie nodig heeft om operationeel te blijven na een grote verstoring. Het gaat niet om alles wat handig is, maar om wat strikt noodzakelijk is om de kernprocessen draaiende te houden en verdere schade te beperken.

Welke systemen onder de MVC vallen, is per organisatie anders. Toch zijn er categorieën die vrijwel altijd terugkomen:

• Identiteit en toegang: Active Directory, Azure AD of een vergelijkbare directory service. Zonder dit kunnen medewerkers nergens bij.
• Netwerktoegang en DNS: De basisinfrastructuur waarop alle andere systemen leunen.
• Communicatie: E-mail en eventueel een alternatief communicatiekanaal voor interne en externe afstemming.
• Primaire bedrijfsapplicaties: De systemen die direct gekoppeld zijn aan de kernprocessen, zoals een ERP-systeem, een orderbeheersysteem of een productieplanningsomgeving.
• Financiële systemen: Betalingsverkeer en facturatie, omdat stilstand hier direct financiële gevolgen heeft.
• Back-up en herstelinfrastructuur: Zonder werkende back-ups kun je de rest ook niet herstellen.

Het bepalen van je Minimum Viable Company is een strategische oefening die je het beste doet samen met zowel IT als de business. Technische mensen weten hoe systemen samenhangen, maar de business bepaalt welke processen echt niet kunnen wachten.

Hoe stel je een herstelprioriteit vast per systeem?

Herstelprioriteiten stel je vast door per systeem de bedrijfsimpact, de technische afhankelijkheden en de maximaal toegestane uitvaltijd in kaart te brengen. Combineer die drie elementen en je krijgt een volgorde die zowel technisch uitvoerbaar als operationeel verdedigbaar is.

Een praktische aanpak werkt in vier stappen:

1. Breng alle systemen in kaart. Maak een overzicht van alle applicaties, servers en diensten die de organisatie gebruikt, inclusief cloudoplossingen en SaaS-tools.
2. Koppel elk systeem aan een bedrijfsproces. Welk proces valt stil als dit systeem wegvalt? Hoe groot is de impact op omzet, klanten of interne werking?
3. Bepaal de RTO per systeem. Hoe lang mag dit systeem maximaal uitvallen voordat de schade onaanvaardbaar wordt? Vier uur? Acht uur? Twee dagen?
4. Breng technische afhankelijkheden in kaart. Welke systemen zijn afhankelijk van dit systeem? En van welke andere systemen is dit systeem zelf afhankelijk? Zo ontstaat een logische herstelvolgorde.

Het resultaat is een herstelprioriteitslijst die je opneemt in je disaster recovery plan. Zorg dat deze lijst actueel blijft, want zodra je een nieuw systeem in gebruik neemt of een proces verandert, kan de prioriteit verschuiven.

Welke systemen worden doorgaans als eerste hersteld?

In de meeste organisaties worden identiteits- en toegangssystemen als eerste hersteld, gevolgd door netwerkinfrastructuur en DNS, en daarna communicatietools zoals e-mail. Pas als die basislaag werkt, is het zinvol om bedrijfskritische applicaties te herstellen.

De reden is simpel: bijna alle andere systemen zijn afhankelijk van een werkende identiteitsomgeving. Als medewerkers niet kunnen inloggen, kun je geen enkel ander systeem effectief gebruiken. Dat maakt identiteitsherstel in vrijwel elke situatie de eerste stap.

Na de basisinfrastructuur volgen de systemen met de kortste RTO en de hoogste bedrijfsimpact. In een productiebedrijf kan dat het productieplanningssysteem zijn. Bij een logistiek bedrijf is dat mogelijk het orderbeheer. Bij een financiële dienstverlener staat het betalingssysteem bovenaan. De exacte volgorde verschilt, maar de logica is altijd dezelfde: herstel van buiten naar binnen, van fundament naar toepassing.

Wat gaat er mis als je geen herstelprioriteiten hebt vastgelegd?

Zonder vastgelegde herstelprioriteiten verlies je kostbare tijd aan discussie en afstemming op het moment dat je het minst kunt missen. Teams beginnen te herstellen wat ze kennen of wat het meest zichtbaar is, in plaats van wat het meest kritiek is voor de organisatie.

Dat leidt in de praktijk tot een aantal herkenbare problemen. Afdelingen trekken aan IT-capaciteit voor hun eigen systemen, terwijl de basisinfrastructuur nog niet stabiel is. Systemen worden hersteld in een volgorde die technisch niet logisch is, waardoor herstelwerk opnieuw gedaan moet worden. En de communicatie naar de buitenwereld stagneert omdat niemand weet wat er wanneer beschikbaar is.

Een goed cyber resilience plan voorkomt precies dit: het geeft iedereen dezelfde uitgangspunten en maakt de herstelvolgorde tot een operationele beslissing die je vooraf hebt genomen, niet een improvisatie onder druk.

Hoe test je of je herstelplan ook echt werkt?

Een herstelplan werkt alleen als je het hebt getest onder realistische omstandigheden. De meest effectieve manier is een tabletop exercise of een technische hersteltest waarbij je daadwerkelijk simuleert dat een of meerdere systemen niet beschikbaar zijn en vervolgens het herstelproces doorloopt.

Testen doe je op twee niveaus. Ten eerste het proces: weten de juiste mensen wat ze moeten doen, in welke volgorde, en met welke middelen? Ten tweede de techniek: werken de back-ups, zijn de hersteltijden haalbaar en kloppen de afhankelijkheden die je hebt vastgelegd nog met de werkelijkheid?

Een jaarlijkse test is een minimum. Organisaties die hun IT-omgeving regelmatig aanpassen, doen er goed aan vaker te testen, of in ieder geval na elke significante wijziging. Denk ook aan het testen van herstel van Microsoft 365, want cloudoplossingen worden regelmatig onderschat in herstelplannen terwijl ze voor veel organisaties essentieel zijn.

Documenteer de resultaten van elke test en gebruik die om het plan te verbeteren. Een herstelplan dat nooit wordt bijgewerkt, verliest snel zijn waarde.

Hoe wij helpen bij het bepalen van herstelprioriteiten

Bij OpenSight helpen we organisaties om herstelprioriteiten niet alleen op papier te zetten, maar ook praktisch uitvoerbaar te maken. We beginnen met het in kaart brengen van de kritieke systemen en processen die samen de Minimum Viable Company vormen, en werken van daaruit naar een concrete herstelvolgorde die past bij de architectuur en bedrijfsdoelstellingen van de organisatie.

Dat doen we samen met zowel IT als de business, zodat de prioriteiten technisch kloppen en operationeel gedragen worden. Vervolgens helpen we met het inrichten van de juiste herstelinfrastructuur, het testen van het plan en het actueel houden ervan naarmate de omgeving verandert.

Wil je weten hoe jouw organisatie er nu voor staat? Vraag een risk assessment aan en we kijken samen waar de grootste verbeterkansen liggen.

Gerelateerde artikelen

• Hoe beïnvloedt een cyberincident je relatie met toezichthouders?
• Wat is een RTO en waarom is het belangrijk voor IT-managers?
• Hoe weet je of je cloudprovider voldoende bijdraagt aan je disaster recovery?
• Hoe zorg je dat nieuwe medewerkers je herstelplan kennen en begrijpen?
• Hoe voldoe je aan NIS2 en verbeter je tegelijk je cyber resilience?