IT continuiteitsplan maken voor uw bedrijf

Een webshop die op maandagochtend niet bereikbaar is, e-mail die stilvalt of bestanden die door ransomware worden versleuteld: dan telt niet alleen hoe snel de techniek herstelt. Ook de vraag wie beslist, wie klanten informeert en welke processen voorrang krijgen, bepaalt de schade. Een IT continuiteitsplan maken geeft uw organisatie houvast wanneer een storing geen theoretisch risico meer is, maar gewoon gebeurt.

Voor zzp’ers en mkb-bedrijven hoeft zo’n plan geen dik handboek in een la te zijn. Juist een compact, actueel en getest plan werkt. Het maakt duidelijk welke systemen onmisbaar zijn, hoe u herstelt en welke partij u belt als elke minuut telt.

Wat is een IT-continuiteitsplan?

Een IT-continuiteitsplan beschrijft hoe uw bedrijf doorwerkt tijdens en na een IT-verstoring. Denk aan uitval van internet, een defecte server, een aanval op uw e-mailomgeving, een gestolen laptop of verlies van gegevens. Het plan gaat verder dan een back-up: een back-up is een hulpmiddel voor herstel, maar vertelt niet wat u eerst herstelt, hoe lang dat mag duren en wie welke actie uitvoert.

Het doel is niet om elke storing te voorkomen. Dat is onmogelijk en vaak onnodig duur. Het doel is om de gevolgen te beperken tot een niveau dat uw bedrijf kan dragen. Voor een administratiekantoor kan toegang tot klantdossiers binnen enkele uren cruciaal zijn. Voor een webshop zijn de bestelpagina en betaalomgeving meestal het eerst aan de beurt. Een klein bureau kan misschien een dag zonder intern archief, maar niet zonder e-mail of cloudtelefonie.

Daarom is continuïteit altijd maatwerk. De juiste oplossing hangt af van uw afhankelijkheden, omzetverlies per uur, wettelijke verplichtingen en de verwachtingen van klanten.

Begin met de bedrijfsprocessen, niet met de server

Veel organisaties starten met de vraag welke back-upsoftware of firewall ze moeten kopen. Dat is begrijpelijk, maar het levert zelden een volledig plan op. Begin liever bij de bedrijfsvoering: wat moet blijven functioneren om klanten te helpen, omzet te maken en aan afspraken te voldoen?

Breng per proces in kaart welke systemen, gegevens, personen en leveranciers nodig zijn. Een offerteproces kan bijvoorbeeld afhankelijk zijn van zakelijke e-mail, een CRM-systeem en toegang tot gedeelde documenten. Orderverwerking kan daarnaast gekoppeld zijn aan een website, voorraadpakket, betaalprovider en verzendpartij.

Stel vervolgens twee praktische vragen. Hoe lang mag dit proces uitvallen voordat de schade merkbaar wordt? En hoeveel gegevensverlies is acceptabel? Deze antwoorden vormen de basis voor hersteldoelen.

De maximale hersteltijd wordt vaak aangeduid als RTO, Recovery Time Objective. Een webshop kan bijvoorbeeld een RTO van twee uur hebben. De maximaal acceptabele hoeveelheid gegevensverlies heet RPO, Recovery Point Objective. Als u elk uur een back-up maakt, kunt u in het slechtste geval maximaal een uur aan wijzigingen verliezen. Wie helemaal geen bestelgegevens mag verliezen, heeft een andere inrichting nodig dan alleen een nachtelijke back-up.

Risico’s kiezen die bij uw omgeving passen

U hoeft niet te plannen voor ieder denkbaar rampscenario. Kijk eerst naar de risico’s die reëel zijn voor uw organisatie. Bij mkb-omgevingen zijn dat vaak een cyberincident, fouten van medewerkers, falende hardware, stroom- of internetuitval, problemen bij een cloudleverancier en verlies of diefstal van apparatuur.

Beschrijf per scenario wat er vermoedelijk uitvalt en wat de eerste veilige handeling is. Bij ransomware is dat bijvoorbeeld niet direct systemen opnieuw opstarten, maar apparaten isoleren, toegang blokkeren en beoordelen welke systemen zijn geraakt. Bij een defecte internetverbinding kan een mobiele noodverbinding voldoende zijn om essentiële werkzaamheden tijdelijk voort te zetten.

Neem ook leveranciers mee. Als uw website, e-mail, domein, DNS, cloudopslag en werkplekken bij verschillende partijen zijn ondergebracht, kost coördinatie tijdens een incident extra tijd. Leg vast wie eigenaar is van welke dienst, welke contactgegevens nodig zijn en welke contractuele hersteltijden gelden. Eén technisch aanspreekpunt voorkomt dat u tijdens een storing zelf moet uitzoeken waar het probleem precies zit.

Zo maakt u een bruikbaar IT-continuiteitsplan

Een goed plan is duidelijk genoeg om onder druk te gebruiken. Zet daarom geen algemene teksten als ‘neem passende maatregelen’ in het document. Noteer concrete acties, namen en beslismomenten.

Gebruik ten minste deze onderdelen:

• Een overzicht van kritieke processen, systemen en afhankelijkheden, gerangschikt op herstelvolgorde.
• Contactgegevens van interne verantwoordelijken, technische partners, providers en belangrijke leveranciers.
• Een incidentprocedure: wie meldt, wie besluit, wie communiceert en wie technische acties uitvoert.
• Herstelstappen voor de belangrijkste scenario’s, inclusief de locatie van back-ups, beheergegevens en eventuele noodvoorzieningen.
• Een communicatieplan voor medewerkers, klanten en eventueel toezichthouders wanneer persoonsgegevens betrokken zijn.
• Een test- en evaluatieplanning, zodat het plan niet veroudert.

Bewaar dit plan niet alleen in de omgeving die bij een storing mogelijk niet bereikbaar is. Zorg voor een beveiligde, offline of onafhankelijk toegankelijke versie. Beperk tegelijk de toegang: een document met beheergegevens en noodaccounts moet niet voor iedereen beschikbaar zijn. Gebruik waar mogelijk een wachtwoordkluis met noodtoegang en leg vast wie die toegang mag inzetten.

Leg rollen vast, ook in een klein team

In een kleine organisatie draagt één persoon soms meerdere rollen. Dat is geen probleem, zolang er een vervanger is. Wijs minimaal een incidentcoördinator aan die overzicht houdt en beslissingen afstemt. Daarnaast is er iemand nodig voor technische afhandeling en iemand voor communicatie. Bij een zzp’er kan een externe IT-partner een deel van die rol overnemen.

Maak ook vooraf afspraken over escalatie. Wanneer schakelt u een specialist in? Wanneer wordt een systeem bewust offline gehaald? Wie mag besluiten om terug te zetten naar een back-up? Die keuzes maakt u liever rustig vooraf dan onder tijdsdruk, terwijl klanten bellen en medewerkers wachten.

Back-ups zijn pas waardevol als herstel werkt

Dagelijkse back-ups zijn een sterke basis, maar alleen als ze gescheiden van de productieomgeving worden opgeslagen, goed beveiligd zijn en daadwerkelijk terug te zetten zijn. Een back-up op dezelfde server helpt niet bij een defecte server. Een back-up die door ransomware bereikbaar is, kan eveneens worden versleuteld. En een herstelpunt dat maandenlang niet is gecontroleerd, biedt schijnzekerheid.

Kies de frequentie op basis van uw RPO. Voor sommige bestanden is een dagelijkse back-up voldoende. Voor databases met bestellingen, e-mail of actuele klantgegevens kan een hogere frequentie nodig zijn. Let ook op bewaartermijnen. Een aanval wordt soms pas na weken ontdekt. Zonder oudere herstelpunten kunt u ongemerkt een al besmette kopie terugzetten.

Test niet alleen of een bestand terugkomt. Test een realistisch herstel: kan de website functioneren op een alternatieve omgeving, werkt de database, kunnen medewerkers inloggen en zijn de juiste rechten aanwezig? De uitkomst van zo’n test is vaak waardevoller dan een technisch rapport met alleen de melding dat de back-up is geslaagd.

Kies passende technische maatregelen

Een continuiteitsplan is geen vervanging voor preventie. Monitoring, tijdige updates, sterke wachtwoorden, multifactorauthenticatie, spam- en virusfiltering en goed werkplekbeheer verkleinen de kans op uitval aanzienlijk. Bij systemen die bedrijfskritisch zijn, kunnen redundante componenten, failover of een tweede internetverbinding verstandig zijn.

Tegelijkertijd heeft extra beschikbaarheid een prijs. Dubbele infrastructuur voor elk systeem is voor veel kleinere bedrijven niet nodig. Richt uw budget eerst op de processen waar stilstand direct omzet, vertrouwen of wettelijke verplichtingen raakt. Een goed beheerde VPS of cloudomgeving met monitoring en gecontroleerde back-ups kan voor een groeiend bedrijf passender zijn dan complexe techniek die niemand intern beheert.

DeltaServ kan daarbij als vaste technische partner helpen om hosting, e-mail, back-ups, beveiliging en beheer op elkaar af te stemmen. Dat maakt verantwoordelijkheden overzichtelijker, vooral wanneer u geen eigen IT-afdeling heeft.

Test uw plan voordat u het nodig heeft

Een plan dat niet wordt getest, is een aanname. Plan daarom minimaal jaarlijks een oefening en doe dit vaker na grote wijzigingen, zoals een nieuwe cloudomgeving, andere e-mailoplossing of uitbreiding van uw team. Houd de eerste oefening klein: simuleer bijvoorbeeld dat zakelijke e-mail een werkdag niet beschikbaar is. Kunnen medewerkers doorwerken? Is de contactlijst correct? Weet iedereen hoe klanten worden geïnformeerd?

Voer daarna een technisch hersteltest uit van een kritieke applicatie of database. Meet hoe lang het werkelijk duurt, welke stappen ontbreken en waar afhankelijkheden zichtbaar worden. Pas het plan direct aan. Ook nieuwe medewerkers, gewijzigde telefoonnummers en verlopen contracten maken een plan sneller onbruikbaar dan u denkt.

Een IT-continuiteitsplan maken is geen eenmalig project, maar een praktische afspraak met uzelf, uw team en uw IT-partner: als er iets misgaat, weten we wat we doen. Dat geeft rust op rustige dagen en zorgt voor daadkracht op de momenten waarop betrouwbaarheid echt wordt getest.