Aanpak continuïteitsplan ICT is veranderd

Business continuity is nu, net als vroeger, nog altijd een zaak van het onderkennen van de single points of failure in de processen en het oplossen hiervan. Vroeger was meestal wel duidelijk welke de single points of failure waren. Zo vormden  de serverruimte en de data opslag als geheel een single point of failure. Hiervoor moest een uitwijk gecreëerd worden. Iedere ICT-er begreep dat, evenals de business. En zo ontstonden uitwijkcentra in allerlei vormen. In feite stonden deze niets te doen tot zich een calamiteit voordeed, meest in een fysieke vorm als brand, overstroming of iets dergelijks. Het calamiteitenplan bestond dan uit één groot draaiboek, hoe de ICT moest uitwijken naar de uitwijklocatie en hoe vervolgens de business hierop aangesloten moest worden.

De problemen zijn veranderd

Met de huidige stand van zaken in de ICT is deze oplossing natuurlijk achterhaald. Virtualisatie van de ICT heeft ervoor gezorgd dat bij fysieke calamiteiten een snelle migratie naar een andere locatie eenvoudig mogelijk is. Ook werkplekken hoeven niet meer afhankelijk te zijn van fysieke bekabeling, en het aansluiten van de business is dan ook nauwelijks meer een probleem. De aandacht voor business continuity is hierdoor op de achtergrond geraakt. Natuurlijk moet die uitwijk wel worden geregeld. En er moet worden gekeken of deze in vredestijd (dat wil zeggen  wanneer er geen sprake is van een calamiteit), ook toegevoegde waarde biedt aan de organisatie. (Zie ook ‘Hoe beleid maken voor informatiebeveiliging of Business Continuity’.)
Maar hiermee is de kous nog niet af. Laten we eens het voorbeeld nemen, dat u software heeft draaien in een extern datacenter en dat daar ook de dataopslag plaats vindt. Zolang dit alleen uw website betreft, is dit doorgaans geen probleem. Als het echter ook gaat om bedrijfskritische applicaties, dan is het zaak om de gehele keten door te lopen op single points of failure. Het maakt daarbij niet uit of uw eigen servers in het datacenter heeft (hosting) of dat u IaaS (infrastructure as a service) afneemt.

Het datacenter

Laten we beginnen met het onderzoeken van het datacenter op single points of failure. De eerste vraag is dan of het datacenter voor de organisatie achter het datacenter een single point of failure is.

• Als die organisatie slechts over één datacenter beschikt, dan is er geen uitwijk in geval van een calamiteit in dat datacenter.
• Als die organisatie beschikt over meerdere datacentra, maar u niet contractueel heeft geregeld, dat u recht heeft op uitwijk als uw specifieke datacenter onderuit gaat, dan heeft u nog steeds een single point of failure.
• Als die organisatie failliet gaat of dreigt te gaan, waarbij er een curator aan het bewind komt, dan loopt u het risico dat u fors moet betalen voor de beschikbaarheid van de voorzieningen en zelfs voor de toegang tot uw data.
• Als in het datacenter een beveiligingsincident plaats vindt die ook uw data betreft, dan bent u hiervoor aansprakelijk en moet u voldoen aan de Meldplicht datalekken, tenzij u dit goed heeft afgedekt. 

Overeenkomsten met datacenters bevatten doorgaans wel allerlei clausules over beschikbaarheid en incidentafhandeling, maar vaak weinig over continuïteit, beveiliging, privacy en compliance rapportages hierover. Onderzoek daarom altijd de overeenkomsten met uw datacenter goed en let met name op de overmachtsituaties en het exit-scenario.

Externe communicatielijnen

De verantwoordelijkheid van het datacenter eindigt doorgaans bij de muren van het datacenter. Zelf bent u verantwoordelijk voor de verbinding met het datacenter. In veel gevallen loopt deze via internet. De potentiele single points of failure hierin zijn de verbinding tussen het datacenter en de internet backbone (is meestal goed geregeld en gegarandeerd) en tussen internet en uw eigen gateway. En hierin komen regelmatig single points of failure voor. Redundantie is nodig voor internet toegang providers, lijnen voor datatransport en het punt, waar deze lijnen het gebouw binnenkomen (het inkooppunt) en natuurlijk de gateway zelf. Complicerende factor hierbij kan zijn, dat u een bedrijfspand huurt. De verhuurder is dan meestal verantwoordelijk voor:

• de bekabeling tussen het inkooppunt en uw gateway;
  het is dus nodig met de verhuurder afspraken te maken over storingen in deze bekabeling en de toegang van derden tot deze bekabeling;
• de capaciteit van de dataverbinding naar buiten;
  in een kantoorpand voor bedrijven heb je dan vaak te maken met heel verschillende behoeften.

Interne communicatielijnen

Voor de interne communicatie wordt meestal het bestaande LAN en eventueel het bestaande WAN gebruikt met alle single point of failure, zoals die ook vroeger al bestonden. Denk hierbij vooral ook aan de patchkasten en de redundante verbinding van de patchpanels naar de gateways. Strikt genomen zou ook de verbinding tussen de patchpanels naar de werkplek redundant moeten zijn, maar als dit bij het ontwerp van het bedrijfspand niet meegenomen is, dan is dit een zeer kostbare oplossing.

Meer veranderingen

Natuurlijk zijn er meer veranderingen dan alleen uitbesteding van ICT naar een datacenter. En al die veranderingen kennen elk hun eigen risico’s. Denk bijvoorbeeld aan:

• het inkopen van SaaS-diensten;
• de continuïteit van uw vaste inkomende telefoonlijnen;
• de toegenomen risico’s van reputatieschade;
  deze risico’s liggen tegenwoordig veelal op het gebied van de privacy (zie ook ‘Privacy wet (Wbp) en de cloud’);
• het op afstand bedienen van uw installaties via procesautomatisering.

In het voorbeeld uit het vorige hoofdstuk ging het erom, duidelijk te maken dat de massieve ‘single points of failure’ tegenwoordig niet meer bestaan, maar dat die vervangen zijn door een doorgaans groter aantal specifieke ‘single points of failure’, die vaak niet-technisch van aard zijn en waarvan dan ook vaak onduidelijk is wie de probleemeigenaar binnen de organisatie is.

Natuurlijk zijn deze problemen oplosbaar. Zeker als ze bij het opzetten van een verandering als ontwerpcriterium worden meegenomen. Dan is het vaak een kwestie van het eenmalig goed regelen, wat op dat moment weinig kosten met zich meebrengt. Het komt meestal neer op slim inkopen en de zaken contractueel goed vastleggen.
Als u echter in de situatie zit, dat u in de afgelopen jaren hijgend achter de ontwikkelingen hebt aangerend en zich niet drukgemaakt hebt over continuïteit, dan zult u nu keuzes moeten maken. Opties zijn dan bijvoorbeeld:

• het uitvoeren van (doorgaans kostbare) structurele reparaties;
• het tijdelijk accepteren van risico’s op calamiteiten, waarbij u wel draaiboekjes op de plank moet hebben liggen voor het geval een calamiteit zich voordoet.

Dit laatste geniet in de meeste gevallen de voorkeur. Het risico is immers maar tijdelijk (enkele jaren) en de kosten zijn dan een fractie van die van structurele reparaties. De draaiboekjes vormen dan de kern van uw business continuity plan.  Deze zijn aanzienlijk dunner dan de continuïteitsplannen van 10 jaar geleden. U kunt ze uitstekend zelf opstellen, want het gaat doorgaans om specifieke single points of failure met een voor u specifieke oplossing. Ook het inregelen van een complex proces voor business continuity management conform ISO 22301 is dan niet nodig. Het gaat tenslotte alleen om het up-to-date houden van de draaiboekjes.
Business continuity management komt pas aan de orde, als u daadwerkelijk ‘Continuity by design’ toepast. Dat komt echter pas aan bod als u toe bent aan de volgende grote verandering. Tegen die tijd is uw corporate risk management echter waarschijnlijk op een dergelijk niveau, dat apart business continuity management overbodig is.