Wat

is

business

continuity

management

(BCM)?

Wat is het doel van business continuity management?

Het doel van business continuity management is dat het werk doorgaat terwijl er iets kapot is. Niet dat er nooit iets uitvalt, want dat is geen haalbaar uitgangspunt. De vraag is hoe lang een proces stil mag liggen en wat er in die periode gebeurt.

Dat maakt BCM eerder een organisatievraag dan een technische. Ligt een orderportaal een uur stil, dan is dat hinderlijk. Ligt een medicatiesysteem een uur stil, dan is dat iets anders. Dezelfde storing heeft in twee organisaties een andere urgentie, en dus een ander prijskaartje aan maatregelen.

BCM legt die afweging vast voordat er iets gebeurt. Dat voorkomt dat er tijdens een storing wordt besloten wat er belangrijk is, op het moment dat de mensen die dat kunnen bepalen aan de telefoon hangen.

Hoe ziet een BCM-proces eruit?

Een BCM-proces bestaat uit vier stappen: een business impactanalyse, een risicoanalyse, een continuïteits- en herstelplan, en het testen en bijstellen daarvan. De eerste twee stappen leveren de onderbouwing, de laatste twee het werkende resultaat.

Business impactanalyse.

De business impactanalyse bepaalt wat de gevolgen zijn als een proces stilvalt, en hoe snel die gevolgen oplopen. Hier ontstaan twee begrippen die de rest van het traject sturen. De RTO, recovery time objective, is de tijd waarbinnen een proces weer moet draaien. De RPO, recovery point objective, is hoeveel gegevens je maximaal mag verliezen, uitgedrukt in tijd.

Die twee getallen bepalen de kosten. Een RPO van 24 uur is te dekken met een nachtelijke back-up. Een RPO van 5 minuten vraagt doorlopende replicatie, en dat is een andere inrichting met een ander budget. Stel ze daarom per proces vast en niet voor de hele organisatie tegelijk.

Risicoanalyse.

De risicoanalyse brengt in kaart wat er kan gebeuren en hoe waarschijnlijk dat is. Voor software gaat het meestal om een handvol categorieën: uitval van hosting, een beveiligingsincident, een mislukte wijziging, verlies van gegevens en het wegvallen van een leverancier.

Zoek daarbij gericht naar het single point of failure: het onderdeel dat, als het wegvalt, alles meesleept. Dat is vaker een koppeling dan een applicatie, of één server met een handmatig ingerichte configuratie die niemand heeft vastgelegd.

Continuïteitsplan en herstelplan.

Het continuïteitsplan beschrijft hoe het werk doorgaat tijdens de verstoring. Het herstelplan beschrijft hoe je terugkeert naar de normale situatie. Dat zijn twee verschillende documenten, omdat een tijdelijke werkwijze andere stappen vraagt dan een herstelactie.

Beide plannen zijn alleen bruikbaar als ze concreet zijn: wie beslist, wie communiceert, welke uitwijk er is en welke handelingen in welke volgorde gebeuren. Een plan dat vooral beschrijft dat er zorgvuldig gehandeld wordt, helpt niemand om twee uur 's nachts.

Testen en bijstellen.

Een ongetest plan is een aanname. De gebruikelijke test is het daadwerkelijk terugzetten van een back-up in een aparte omgeving en meten hoe lang dat duurt. Dat levert bijna altijd een verrassing op: een ontbrekende sleutel, een afhankelijkheid die niemand had opgeschreven, of een hersteltijd die het dubbele is van de afspraak.

Leg daarom vast wanneer je test en wie de uitkomst beoordeelt. Een plan dat na een organisatiewijziging niet is bijgesteld, verwijst naar mensen en systemen die er niet meer zijn.

Wat betekent BCM voor je software en systemen?

Voor software betekent BCM dat je per applicatie weet waar hij draait, welke gegevens hij bevat, waarvan hij afhankelijk is en hoe je hem terugzet. Die vier vragen klinken eenvoudig en zijn in een gegroeid landschap zelden allemaal te beantwoorden.

De afhankelijkheden zijn daarbij het lastigste deel. Een portaal dat orderstatussen toont, is afhankelijk van het ERP, van de ERP-koppeling ertussen en van de tussenlaag die het verkeer regelt. Valt één van die drie weg, dan is het portaal technisch in de lucht en inhoudelijk leeg. In een continuïteitsplan hoort dus niet alleen de applicatie, maar ook elke koppeling waarvan hij afhangt.

Daar komt monitoring bij. Weten dát iets niet werkt voordat een gebruiker belt, is het verschil tussen een storing van tien minuten en een storing van een halve dag. Hoe Cube dat inricht, staat op de pagina over hosting en infrastructuur.

Welke software ondersteunt business continuity management?

Er is BCM-software die plannen, risico's en testmomenten beheert, meestal onderdeel van een breder GRC-pakket voor governance, risk en compliance. Voor organisaties met veel processen en een auditverplichting is dat nuttig, omdat het de administratie en de aantoonbaarheid regelt.

Daarnaast wordt securitysoftware vaak bij dit onderwerp betrokken: monitoring, back-upsoftware, toegangsbeheer en detectie van incidenten. Dat zijn maatregelen, geen continuïteitsbeleid. Ze dekken een risico af dat je eerst in een analyse moet hebben benoemd, anders koop je gereedschap zonder te weten waarvoor.

Voor de meeste organisaties zit de winst dan ook elders. Niet in een pakket dat plannen bijhoudt, maar in back-ups die getest zijn, monitoring die alarmeert en een SLA waarin een hersteltijd staat in plaats van een reactietijd. Dat onderscheid is het navragen waard; wat er verder in zo'n afspraak hoort, staat in het artikel over wat een service level agreement is.

Welke normen en certificeringen zijn relevant?

De norm die specifiek over dit onderwerp gaat is ISO 22301, voor managementsystemen voor bedrijfscontinuïteit. Daarnaast raakt informatiebeveiliging het onderwerp: ISO 27001 voor informatiebeveiliging in het algemeen en NEN 7510 voor informatiebeveiliging in de zorg. De Europese NIS2-richtlijn stelt eisen aan de cyberweerbaarheid van organisaties in aangewezen sectoren.

Of een specifieke norm of richtlijn op jouw organisatie van toepassing is, hangt af van je sector en van de nationale invulling. Laat dat vaststellen door iemand die je situatie kent, en ga niet uit van een algemene uitspraak. Ook niet van deze.

Cube is gecertificeerd voor ISO 27001 en NEN 7510. Wat daar in de dagelijkse werkwijze onder valt, staat bij security en privacy.

Continuïteit van maatwerksoftware bij Cube.

Bij maatwerksoftware komt er een risico bij dat bij een standaardpakket minder speelt: leveranciersafhankelijkheid. Als de partij die jouw software heeft gebouwd wegvalt, moet iemand anders die code kunnen overnemen. Dat is te regelen, maar niet achteraf.

Drie afspraken dekken dat af. Ten eerste eigenaarschap van de broncode, vastgelegd in het contract. Ten tweede een broncodedepot of escrow-regeling, zodat de code bij een derde partij ligt. Ten derde documentatie en een omgeving die reproduceerbaar op te bouwen is, want code zonder werkende bouwomgeving is lastig over te nemen.

Voor het lopende beheer legt Cube hersteltijden en verantwoordelijkheden vast in een partnership voor onderhoud en beheer. Wil je eerst weten hoe je bestaande software ervoor staat, dan brengt de kwaliteitsscan van bestaande software de afhankelijkheden en achterstanden in kaart.

Kort samengevat.

Business continuity management zorgt dat kritische processen doorgaan bij een verstoring, met een impactanalyse, een risicoanalyse, plannen en tests als vaste onderdelen. De RTO en RPO per proces bepalen wat de maatregelen mogen kosten. Voor software gaat het vooral om afhankelijkheden, geteste back-ups en een SLA met een hersteltijd. Bij maatwerk komt daar eigenaarschap van de broncode bij.