Wanneer een belangrijk systeem binnen uw bedrijf uitvalt, is het moeilijkste om te weten wat u eerst moet herstellen, wie de toegang heeft om dat te doen, welke back-up kan worden vertrouwd en hoe lang uw bedrijf kan blijven werken zonder dat systeem.
Dat is waar veel kleine en middelgrote bedrijven (mkb’s) de kloof ontdekken tussen het hebben van back-ups en het hebben van een daadwerkelijk herstelabonnement. Een back-up kan de gegevens bevatten die u nodig heeft, maar deze bepaalt niet de herstelvolgorde, wijst geen verantwoordelijkheden toe, valideert niet of het herstellen werkt en lost het probleem van ontbrekende beheerdersinloggegevens tijdens een uitval niet op.
Een IT-rampenherstelabonnement geeft dit proces structuur voordat er een storing optreedt. Het definieert welke systemen het belangrijkst zijn, hoe snel ze moeten worden hersteld, hoeveel gegevensverlies het bedrijf kan tolereren, welke preventie van gegevensverlies-strategieën moeten worden geïmplementeerd, wie de eigenaar is van elke herstelstap en hoe kritieke inloggegevens worden beschermd. Deze duidelijkheid kan voorkomen dat een IT-incident verandert in langdurige downtime, gederfde inkomsten of een bredere operationele crisis.
Wat is een IT-rampenherstelabonnement?
Bedrijfscontinuïteit vs. IT-rampenherstel
Wat uw IT-rampenherstelabonnement moet dekken
Wat uw IT-rampenherstelabonnement moet definiëren
Inloggegevensherstel: het over het hoofd geziene rampenherstelscenario
Sjabloon voor rampenherstelabonnement
Hoe u uw IT-rampenherstelabonnement test
Bouw herstel rond systemen, gegevens en toegang
Wat is een IT-rampenherstelabonnement?
Een IT-rampenherstelabonnement is een gedocumenteerd proces voor het herstellen van technologiesystemen na een storing. Het richt zich op de IT-laag van het bedrijf: gegevens, toepassingen, apparaten, infrastructuur, cloudservices, toegang voor de beheerder, back-ups en de mensen die verantwoordelijk zijn voor het herstel.
Een praktisch IT-herstelabonnement zou vragen moeten beantwoorden zoals:
- Welke systemen moeten als eerste terugkeren?
- Hoeveel downtime kan het bedrijf tolereren?
- Hoeveel gegevensverlies is acceptabel?
- Waar worden back-ups opgeslagen?
- Wie kan systemen herstellen?
- Welke beheerderinloggegevens zijn nodig?
- Hoe zal het team bevestigen dat herstelde systemen veilig en bruikbaar zijn?
- Hoe zal het bedrijf communiceren met personeel en klanten als de primaire kanalen uitvallen?
Een rampenherstelabonnement moet verder gaan dan het omgaan met cyberaanvallen: het moet alledaagse problemen dekken zoals hardwarestoringen, verloren inloggegevens en per ongeluk verwijderen. Het moet ook externe servicestoringen dekken, zoals storingen in cloudplatforms of SaaS-tools, configuratiefouten en sleutelmedewerkers die vertrekken zonder kritieke toegang over te dragen.
Herstel is niet iets om te ontwerpen tijdens een storing. Het moet worden gepland, toegewezen, gecommuniceerd en getest voordat uw bedrijf er afhankelijk van moet zijn.
Bedrijfscontinuïteit vs. IT-rampenherstel
Bedrijfscontinuïteit en IT-rampenherstel worden vaak als hetzelfde behandeld, maar ze lossen verschillende problemen op.
Bedrijfscontinuïteit gaat over het draaiende houden van het bedrijf tijdens een storing. Het omvat communicatie met klanten, tijdelijke werkstromen, verantwoordelijkheden van het personeel, coördinatie van leveranciers en beslissingen over welke diensten moeten worden voortgezet, zelfs als normale systemen onbeschikbaar zijn.
IT-rampenherstel richt zich op de technologie achter dat werk. Het definieert hoe systemen, gegevens, toepassingen, back-ups en toegang voor de beheerder worden hersteld, zodat het bedrijf de normale activiteiten veilig kan hervatten.
Neem bijvoorbeeld een CRM-storing. Een bedrijfscontinuïteitsabonnement kan uitleggen hoe verkoop- of ondersteuningsteams klanten blijven bedienen terwijl het CRM plat ligt. Het IT-herstelabonnement legt uit wie contact opneemt met de leverancier, welke gegevens moeten worden hersteld, welke back-up of export beschikbaar is, welke inloggegevens vereist zijn en hoe het team bevestigt dat het systeem weer veilig te gebruiken is.
Voor veel mkb’s verschijnt de kloof pas tijdens een incident. Mensen weten wie contact zou opnemen met klanten, maar niet wie het facturatiesysteem kan herstellen. Ze weten dat er back-ups bestaan, maar niet of een herstel ooit is getest. Ze weten dat één medewerker meestal de IT beheert, maar niet wat er gebeurt als die persoon onbeschikbaar is of waar de beheerderswachtwoorden zijn opgeslagen als die persoon onbereikbaar is.
Wat uw IT-rampenherstelabonnement moet dekken
Een sterk IT-rampenherstelabonnement hoeft niet overdreven lang te zijn, maar moet specifiek genoeg zijn om tijdens een stressvolle situatie uit te voeren.
Recovery Time Objective
Recovery Time Objective, of RTO, definieert hoe snel een systeem moet worden hersteld. Een betalingssysteem moet mogelijk binnen enkele uren weer online zijn, terwijl een intern rapportagedashboard een langere uitval kan tolereren.
Stel RTO’s in op basis van bedrijfsimpact, niet op basis van technische voorkeur, omdat de kosten van downtime zowel een zakelijk als een technisch probleem zijn. Vraag welke systemen invloed hebben op de omzet, klantverplichtingen, wettelijke verplichtingen, beveiliging en productiviteit van werknemers.
Recovery Point Objective
Recovery point objective, of RPO, definieert hoeveel gegevensverlies acceptabel is, wat vervolgens helpt bij het bepalen van de juiste preventie van gegevensverlies-strategieën (DLP). Als een systeem een RPO van één uur heeft, moeten back-ups of replicatie herstel tot ongeveer dat punt ondersteunen.
Als de RPO één dag is, accepteert het bedrijf een grotere kloof. RPO helpt ook bij het bepalen van de back-upfrequentie, want hoe korter uw RPO, hoe vaker uw back-ups moeten worden gemaakt. Kritieke systemen hebben daarom vaker back-ups nodig dan systemen met een lage prioriteit.
Systeemprioriteitsniveaus
Niet elk systeem mag tegelijkertijd worden hersteld. Een rampenherstelabonnement voor kleine bedrijven moet systemen onderverdelen in prioriteitsniveaus.
- Niveau 1: Systemen die vereist zijn voor kernactiviteiten, beveiliging, communicatie of omzet.
- Niveau 2: Belangrijke systemen die korte downtime kunnen tolereren.
- Niveau 3: Systemen met een lagere prioriteit die kunnen worden hersteld nadat het bedrijf stabiel is.
Typische niveau 1-systemen zijn bijvoorbeeld e-mail, de identiteitsprovider, de wachtwoordbeheerder, financiële systemen, de klantendatabase, cloud-Opslag en communicatieplatforms.
Back-upstrategie
Uw back-upstrategie moet definiëren:
- Waarvan een back-up wordt gemaakt en hoe vaak
- Waar back-ups worden opgeslagen
- Wie er toegang toe heeft
- Hoe het herstel wordt getest
De NCSC heeft ook(nieuw venster) principes voor ransomware-resistente back-ups gepubliceerd voor cloud- en on-premise back-upoplossingen, waarbij wordt opgemerkt dat back-upgegevens standaard niet resistent zijn tegen ransomware en moeten worden beoordeeld op de ransomware-dreiging.
Een sterke back-upstrategie omvat meestal offline of onveranderbare back-ups voor kritieke gegevens, regelmatig testen, gedocumenteerde herstelstappen en afzonderlijke inloggegevens voor back-upbeheer.
Functies en verantwoordelijkheden
Een rampenherstelabonnement moet eigenaren noemen, niet alleen taken. Als één persoon alle herstelkennis bezit, heeft het bedrijf zowel een personeelsrisico als een IT-risico. Definieer wie:
- Het herstel leidt
- Systemen herstelt
- Contact opneemt met leveranciers
- Noodtoegang goedkeurt
- Intern communiceert
- Beslissingen documenteert
Wat uw IT-rampenherstelabonnement moet definiëren
| Component | Wat het beantwoordt |
| RTO | Hoe snel moet elk systeem worden hersteld? |
| RPO | Hoeveel gegevens kan het bedrijf zich veroorloven te verliezen? |
| Prioriteitsniveaus | Welke systemen keren als eerste terug, en welke kunnen wachten? |
| Back-upstrategie | Waarvan wordt een back-up gemaakt, waar wordt deze opgeslagen en is het herstel getest? |
| Functies en verantwoordelijkheden | Wie leidt het herstel, herstelt systemen, neemt contact op met leveranciers en keurt noodwijzigingen goed? |
Inloggegevensherstel: het over het hoofd geziene rampenherstelscenario
Rampenherstel richt zich vaak op gegevens, servers en back-ups. Maar in de praktijk kan herstel mislukken omdat het team geen toegang heeft till de systemen die nodig zijn om de activiteiten te herstellen.
Inloggegevensherstel vraagt:
- Wie heeft toegang tot beheerdersaccounts?
- Waar worden back-upinloggegevens opgeslagen?
- Welke accounts kunnen kritieke systemen herstellen?
- Wat gebeurt er als een wachtwoord verloren gaat, in gevaar is gebracht of in het bezit is van iemand die onbeschikbaar is?
- Worden noodinloggegevens beschermd en beoordeeld?
- Kan toegang snel worden ingetrokken en opnieuw toegewezen?
Als back-upinloggegevens worden opgeslagen in de browser van één werknemer, herstelcodes in een privénotitie worden bewaard of gedeelde beheerderswachtwoorden via chat circuleren, kan het bedrijf tijdens een incident mogelijk niet soepel herstellen.
Een wachtwoordbeheerder voor bedrijven helpt dat risico te verkleinen door kritieke inloggegevens te centraliseren in versleutelde kluizen, toegang toe te wijzen per functie en het eenvoudiger te maken om toegang in te trekken of opnieuw toe te wijzen wanneer iemand vertrekt of verantwoordelijkheden veranderen. Proton Pass for Business helpt teams om sterke wachtwoorden te genereren, inloggegevens veilig op te slaan, veilig delen te gebruiken en gevoelige toegang buiten chats en spreadsheets te houden.
Als een wachtwoordbeheerder voor IT-teams ondersteunt Proton Pass gecentraliseerd beheer van inloggegevens, wachtwoordbeleid, veilig delen, rapportage en logboeken, SCIM-provisioning en SSO-integraties. Dat maakt het herstel van inloggegevens beheersbaarder, omdat toegang till kritieke systemen niet afhankelijk is van één persoon, één browserprofiel of één ongedocumenteerd wachtwoord.
Sjabloon voor rampenherstelabonnement
Een rampenherstelabonnement werkt het beste als het specifiek genoeg is om actie te sturen tijdens een storing, maar eenvoudig genoeg is voor het team om onder druk te gebruiken. Voor mkb’s moet het sjabloon zich richten op de essentie: wat moet worden hersteld, hoe snel, vanaf welke back-up, door wie en met welke inloggegevens.
1. Bereik
Definieer welke systemen, diensten, locaties, apparaten en gegevens het abonnement dekt.
Sjabloontekst: Dit IT-rampenherstelabonnement dekt de systemen, gegevens, diensten, inloggegevens en leveranciers die nodig zijn om de kritieke activiteiten van [Company Name] te herstellen na een technologische storing.
2. Inventarisatie van kritieke systemen
Maak een lijst van de systemen waarvan uw bedrijf afhankelijk is en wijs prioriteitsniveaus toe.
Sjabloontekst: Kritieke systemen worden gegroepeerd in Niveau 1, Niveau 2 en Niveau 3 op basis van bedrijfsimpact, recovery time objective, recovery point objective en afhankelijkheid van andere systemen.
3. Hersteldoelstellingen
Definieer RTO en RPO voor elk prioriteitssysteem.
Sjabloontekst: Elk systeem moet een gedocumenteerde recovery time objective en recovery point objective hebben. Deze doelen moeten ten minste jaarlijks en na grote systeemwijzigingen worden beoordeeld.
4. Back-up- en herstelproces
Documenteer waar back-ups worden opgeslagen, hoe vaak ze worden uitgevoerd, wie er toegang toe heeft en hoe het testen van herstel werkt.
Sjabloontekst: Back-ups moeten worden beschermd tegen ongeautoriseerde toegang, indien van toepassing apart van primaire systemen worden opgeslagen en regelmatig worden getest. Herstelprocedures moeten worden gedocumenteerd voor Niveau 1-systemen.
5. Herstel van inloggegevens en toegang
Definieer waar kritieke inloggegevens worden opgeslagen en wie er toegang toe heeft tijdens het herstel.
Sjabloontekst: Beheerdersinloggegevens, back-upinloggegevens, herstelcodes en toegang voor leveranciers die vereist zijn voor rampenherstel, moeten worden opgeslagen in een goedgekeurde versleutelde kluis. Toegang moet worden beperkt tot geautoriseerde functies en worden beoordeeld na functiewijzigingen, uitdiensttreding en hersteloefeningen.
6. Functies en escalatie
Definieer hersteleigenaren, vervangers en escalatiepaden.
Sjabloontekst: Elke herstelfunctie moet een primaire eigenaar en een back-upeigenaar hebben. Het abonnement moet identificeren wie het herstel leidt, wie systemen herstelt, wie contact opneemt met leveranciers, wie updates communiceert en wie noodwijzigingen goedkeurt.
7. Communicatieabonnement
Definieer hoe het bedrijf intern en extern communiceert tijdens een IT-storing.
Sjabloontekst: Tijdens een herstelafspraak worden interne updates gedeeld via het [goedgekeurde kanaal]. Externe communicatie naar klanten, leveranciers, verzekeraars of toezichthouders moet worden goedgekeurd door [functie/team].
8. Frequentie van testen en beoordelen
Definieer hoe vaak het abonnement wordt getest en bijgewerkt.
Sjabloontekst: Dit rampenherstelabonnement wordt ten minste [jaarlijks/twee keer per jaar] getest en beoordeeld na grote incidenten, systeemwijzigingen, wijzigingen van leveranciers of mislukte hersteloefeningen.
Hoe u uw IT-rampenherstelabonnement test
Een rampenherstelabonnement wordt pas nuttig als het is getest onder omstandigheden die lijken op een echte storing. Een back-up die bestaat maar nooit is hersteld, is nog steeds een aanname. Een herstelfunctie die slechts één persoon begrijpt, is nog steeds een afhankelijkheid. Een beheerdersinloggegeven dat niemand kan vinden tijdens een storing, is nog steeds een blokkade.
Testen hoeft in het begin niet ingewikkeld te zijn. Voor de meeste mkb’s is het doel om te bewijzen dat het bedrijf de juiste systemen kan herstellen, met de juiste mensen, met behulp van de juiste inloggegevens, binnen een realistisch tijdsbestek.
1. Tabletop-oefening
Kies een waarschijnlijk scenario, zoals ransomware die gedeelde bestanden treft, een uitval van cloudOpslag, het per ongeluk verwijderen van klantgegevens of het plotselinge verlies van toegang tot een beheerdersaccount. Loop door wat het team in het eerste uur zou doen, wie de leiding zou hebben, met welke leveranciers contact zou worden opgenomen, welke systemen prioriteit zouden krijgen en welke informatie zou ontbreken.
2. Herstel testen
Selecteer een kritiek bestand, database, postvak IN of systeemexport en bevestig dat dit kan worden hersteld naar een bruikbare staat. Controleer of de herstelde gegevens recent genoeg zijn, of machtigingen nog werken en of het team weet waar de back-up zich bevindt.
3. Regelmatig testen
Als praktische basislijn moeten mkb’s het abonnement ten minste eenmaal per jaar testen, in overeenstemming met de NIST-richtlijnen in Special Publication 800-34 Revision 1(nieuw venster), and vaker na grote systeem- of leverancierswijzigingen.
4. Herstel van inloggegevens testen
Bevestig dat geautoriseerde personen toegang hebben tot back-upbeheerdersaccounts, cloudbeheerdersaccounts, leveranciersportalen, herstelcodes en noodinloggegevens zonder afhankelijk te zijn van de browser, privénotities of het geheugen van één werknemer. Het doel is niet om gevoelige wachtwoorden onnodig bloot te leggen. Het is om te bevestigen dat het toegangsmodel nog steeds werkt wanneer het bedrijf onder druk staat.
Documenteer na elke test wat er is mislukt, wat te lang duurde en wijs een specifieke persoon en deadline toe voor elke oplossing. Een goede test is niet een test waarbij alles perfect verloopt. Het is een test die de kloven onthult terwijl het bedrijf nog tijd heeft om ze te verhelpen.
Bouw herstel rond systemen, gegevens en toegang
Een nuttig IT-rampenherstelabonnement geeft het bedrijf een herstelvolgorde, een groep eigenaren, een realistisch beeld van acceptabele downtime en een manier om de bedrijfscontinuïteit te behouden en weer toegang te krijgen tot de systemen die het werk draaiende houden.
Voor mkb’s kan dit het verschil maken tussen een korte storing en een langdurige uitval. Als e-mail, financiële software, cloudOpslag, klantsystemen of beheerdersaccounts onbeschikbaar zijn, moet het team weten wat eerst komt, wie kan handelen en welke inloggegevens vereist zijn om de toegang veilig te herstellen.
Dit is de reden waarom herstelplanning systemen, gegevens en toegang samen moet dekken. Back-ups kunnen bestanden herstellen, maar inloggegevens zorgen ervoor dat het team weer controle krijgt over de systemen die nodig zijn om te herstellen. Beheerdersinlogs, leveranciersportalen, back-upaccounts, herstelcodes en gedeelde operationele inloggegevens moeten allemaal worden beschermd, georganiseerd en beschikbaar zijn voor de juiste mensen als er iets misgaat.
Een wachtwoordbeheerder voor bedrijven helpt dat deel van het abonnement te versterken. Omdat kritieke inloggegevens zijn opgeslagen in versleutelde wachtwoordkluizen and alleen worden gedeeld met geautoriseerde mensen, is het bedrijf tijdens een herstelafspraak minder afhankelijk van de browser, privénotities of het geheugen van één werknemer.
