Ik verwacht dat we de komende jaren steeds vaker te maken krijgen met cybersecurity-incidenten.
Is dat doemdenken? Misschien wel. Misschien niet.
Ik ben in ieder geval graag voorbereid op vervelende scenario’s. Met een gezonde dosis relativeringsvermogen natuurlijk!
Daarom wil ik de volgende gedachtekronkel eens delen.
Wat als je webshop drie dagen of zelfs een week offline is?
Stel: je webshop ligt drie dagen plat. Of misschien zelfs een hele week. Door een cyberaanval, een grote storing bij je hostingprovider of een kritiek beveiligingslek waardoor je webshop uit voorzorg tijdelijk offline moet.
Voor een grotere webshop die sterk afhankelijk is van online omzet, kan dat financieel behoorlijk ingrijpend zijn. Ook je klantenservice, magazijn en lopende bestellingen kunnen er last van krijgen.
Om het concreet te maken, heb ik vijf mogelijke scenario’s uitgewerkt. Denk aan een PrestaShop-webshop met een achterliggend ERP-systeem, waarbij beide systemen in afzonderlijke hostingomgevingen draaien.
Vijf scenario’s om rekening mee te houden
1. PrestaShop moet preventief offline vanwege een cyberdreiging
Er wordt een kritiek beveiligingslek ontdekt in PrestaShop, PHP of een veelgebruikte module. Er zijn geen aanwijzingen dat jouw webshop daadwerkelijk is gehackt, maar het risico is te groot om online te blijven. Je besluit de webshop tijdelijk uit te schakelen totdat er een beveiligingsupdate of betrouwbare noodmaatregel beschikbaar is.
Indicatieve uitval voor noodplanning: 4–48 uur.
2. Je hostingprovider is onbereikbaar
Je hostingprovider, krijgt te maken met een grote infrastructuurstoring, netwerkprobleem of cyberaanval. Je webshop zelf kan technisch helemaal in orde zijn, maar bezoekers kunnen hem niet bereiken. Je bent afhankelijk van de provider voor herstel.
Indicatieve uitval voor noodplanning: 2–24 uur, in uitzonderlijke gevallen meerdere dagen.
3. ERP is offline, maar PrestaShop werkt nog
Klanten kunnen de webshop nog bezoeken en mogelijk bestellen, maar de verbinding met het ERP-systeem is weggevallen. Daardoor kunnen voorraadmutaties, orderverwerking, facturatie of verzending vertraging oplopen. Misschien kun je tijdelijk doorverkopen, maar hoe voorkom je dat je producten verkoopt die inmiddels niet meer op voorraad zijn?
Indicatieve verstoring voor noodplanning: 2–48 uur.
In dit scenario is een noodbestelomgeving niet automatisch nodig. Een goede procedure voor handmatige verwerking binnen de bestaande webshop kan voldoende zijn.
4. Je ERP en webshop zijn offline
Dit vind ik een interessante. Je webshop draait bij de ene hostingprovider, je ERP-systeem bij een andere. Twee afzonderlijke omgevingen. Hoe groot is de kans dat beide systemen tegelijkertijd uitvallen?
Bij twee volledig onafhankelijke storingen is die kans klein. Maar onafhankelijk gehost betekent niet dat er geen gezamenlijke risico’s zijn. Denk aan een gecompromitteerd beheerdersaccount, een cyberaanval die via koppelingen meerdere systemen raakt, ransomware op gedeelde werkplekken of een storing bij een gezamenlijke externe dienst.
Indicatieve hersteltijd voor noodplanning: 1–3 dagen of langer, afhankelijk van de oorzaak.
In zo’n situatie ligt niet alleen je verkoopkanaal stil, maar mogelijk ook je interne orderverwerking.
5. Je webshop is daadwerkelijk gehackt
Dit is misschien het vervelendste scenario. Bestanden zijn aangepast, gegevens zijn mogelijk buitgemaakt of je kunt niet langer vertrouwen op de integriteit van de omgeving.
Dan kun je niet zomaar een back-up terugzetten en verdergaan. Eerst moet duidelijk zijn hoe de aanvaller is binnengekomen, welke systemen geraakt zijn en hoe je veilig kunt herstellen.
Indicatieve hersteltijd voor noodplanning: 2–7 dagen, bij ernstige incidenten mogelijk weken.
Juist dan wil je niet onder omzetdruk een mogelijk onveilige webshop te snel opnieuw online zetten.
Deze hersteltijden zijn grove inschattingen voor noodplanning, geen statistische gemiddelden of garanties. De daadwerkelijke duur hangt af van de oorzaak, de leveranciers, beschikbare back-ups en herstelprocedures.
Waarom een back-up niet hetzelfde is als een noodplan
Een goede back-up is essentieel. Maar een back-up is nog geen garantie dat je webshop binnen een paar uur weer veilig online is.
Je moet beschikken over een werkende herstelomgeving, toegang tot je gegevens en voldoende zekerheid dat je niet dezelfde kwetsbaarheid of besmetting terugplaatst.
Een back-up helpt je om je bestaande systemen te herstellen. Plan C is bedoeld om tijdens dat herstel bereikbaar te blijven en bestelaanvragen te ontvangen.
Plan C: geen tweede webshop, maar een noodbestelomgeving
Maar stel dat je nog wel toegang hebt tot je DNS. Waarom zou je dan geen eenvoudige noodbestelomgeving achter de hand hebben?
Geen tweede PrestaShop-installatie, geen ingewikkelde ERP-koppelingen, geen uitgebreide checkout en geen realtime voorraadbeheer.
Gewoon een eenvoudige, statische HTML-catalogus met je belangrijkste producten, prijzen, contactgegevens en een bestelformulier waarmee klanten een aanvraag kunnen indienen.
Je hebt tijdens een calamiteit geen tweede webshop nodig. Je hebt een manier nodig waarop klanten bestelaanvragen kunnen blijven indienen.
Hoe zou zo’n noodbestelomgeving werken?
- Onafhankelijke hosting: de noodbestelomgeving draait bij een andere provider, los van de reguliere webshop en het ERP-systeem.
- Een vooraf bijgewerkte productcatalogus: een externe product- en voorraaddataset wordt dagelijks vernieuwd en is onder normale omstandigheden maximaal 24 uur oud.
- Een herkenbare uitstraling: dezelfde huisstijl en waar mogelijk dezelfde product-URL’s, zodat bezoekers niet ineens op een onbekende website terechtkomen.
- Bestellingen als aanvragen: klanten dienen een aanvraag in. Na een handmatige voorraadcontrole wordt de bestelling bevestigd.
- Standaard stand-by: de catalogus staat al klaar; het bestelformulier wordt alleen bij een calamiteit geactiveerd.
Technisch zou ik het bewust zo eenvoudig mogelijk houden: statische HTML, zonder database, PHP of complexe koppelingen in de catalogus zelf. Alleen voor het veilig ontvangen en doorsturen van aanvragen is een kleine, afzonderlijk gehoste verwerkingsfunctie of externe dienst nodig.
Uiteraard moet ook die voorziening goed beveiligd zijn, met versleutelde communicatie, spambeveiliging en een zorgvuldige verwerking van persoonsgegevens. Bestelaanvragen mogen bovendien niet uitsluitend afhankelijk zijn van één mailbox die tijdens hetzelfde incident onbereikbaar kan worden.
De productgegevens moeten vooraf beschikbaar zijn in de noodomgeving. Tijdens een incident wil je niet alsnog afhankelijk zijn van een export uit het getroffen systeem. Voorraadstanden kunnen verouderd zijn; daarom blijft een aanvraag voorlopig en volgt pas na controle een definitieve bevestiging.
En als je DNS of domeinnaam ook niet bereikbaar is?
Bij een calamiteit kun je, zolang je toegang hebt tot je DNS en de betreffende diensten werken, het reguliere domein naar de noodomgeving laten verwijzen. Houd rekening met caching en de tijd die DNS-wijzigingen nodig kunnen hebben.
Mocht dat niet lukken, dan kan een vooraf ingerichte alternatieve domeinnaam met onafhankelijke DNS als laatste vangnet dienen. Die kun je via e-mail, sociale media en andere kanalen communiceren.
Dat werkt alleen als je de omgeving, domeinnaam, certificaten en communicatie vooraf hebt ingericht en getest. Tijdens een incident wil je dit niet voor het eerst moeten uitzoeken.
Het hoeft niet perfect te zijn
Een noodbestelomgeving vervangt je reguliere webshop niet. Je mist mogelijk online betalingen, klantaccounts, kortingsregels, realtime voorraad en automatische verwerking. Aanvragen moeten misschien handmatig worden beoordeeld en later alsnog in je ERP-systeem worden geregistreerd.
Bij een beveiligingsincident moet je bovendien voorkomen dat je onbetrouwbare gegevens of onveilige koppelingen overneemt naar de noodomgeving.
Maar misschien is dat juist de kracht van het idee: het doel is niet om tijdens een calamiteit alles te kunnen. Het doel is om niet volledig stil te vallen.
Wat kost drie dagen downtime? En een hele week?
Stel dat je webshop gemiddeld € 10.000 per dag omzet. Drie dagen offline vertegenwoordigen dan € 30.000 aan reguliere omzet. Een week zelfs € 70.000.
Dat betekent niet dat al die omzet definitief verloren gaat. Sommige klanten bestellen later alsnog. Andere klanten wijken uit naar concurrenten. En na herstel kan er een flinke achterstand ontstaan.
Daartegenover staat de investering in een eenvoudige noodbestelomgeving die je hopelijk nooit nodig hebt.
Slimme voorbereiding of een probleem dat nauwelijks voorkomt?
Ik ben vooral benieuwd hoe eigenaren van grotere webshops en andere e-commerceprofessionals hierover denken.
Hebben jullie al een noodscenario waarmee je bij langdurige uitval toch bestelaanvragen kunt blijven ontvangen? Bijvoorbeeld via een alternatieve bestelomgeving, telefonische bestellingen of zelfs ouderwetse papieren formulieren?
Of accepteer je dat je webshop bij een ernstig incident enkele dagen volledig offline kan zijn?
Is een onafhankelijke noodbestelomgeving een verstandige investering in bedrijfscontinuïteit, of ben ik hier een probleem aan het oplossen dat in de praktijk nauwelijks voorkomt?
Ik ben benieuwd naar jullie ervaringen en ideeën. Stuur mij gerust een e-mail. Heb je hier technische ondersteuning of ander advies nodig dan kan je mij natuurlijk altijd bereiken.
Stefan Dijkstra
