Een incidentplan voor uw website klinkt als iets voor bedrijven met een IT-afdeling. Dat is het niet. Voor een bedrijf met vijftien mensen en één website is het juist belangrijker, want u heeft niemand die het uit het hoofd weet. Op het moment dat de site eruit ligt, begint bij de meeste ondernemers een zoektocht naar wie ook alweer de hosting regelt en waar dat wachtwoord staat.
Dat kost gemiddeld een halve dag, en dat is precies de tijd die u niet heeft. Alles wat u nodig heeft, past op één vel papier. Hieronder staat wat erop hoort, hoe u het invult en waar u het bewaart.
Blok 1: wie doet wat
Vier regels, meer niet. Zonder namen wordt er in het moment zelf gekeken wie het oppakt, en dat kost tijd.
- Wie beslist. Eén persoon die knopen doorhakt, inclusief het besluit om de site offline te halen. Zet er een vervanger bij.
- Wie technisch handelt. Uw beheerder, bureau of hostingpartij, met naam en direct nummer.
- Wie klanten te woord staat. Vaak iemand anders dan de vorige twee.
- Wie intern informeert. Collega’s die klanten spreken, moeten weten wat ze mogen zeggen.
Zet bij elke naam een mobiel nummer en een privé-e-mailadres. Ligt de mail eruit, dan werkt een adres op uw eigen domein niet meer, en dat is precies wanneer u elkaar nodig heeft.
Blok 2: waar staat wat
Dit is het deel waar de meeste tijd mee wordt verloren. Noteer per onderdeel de partij, het klantnummer en het adres van de inlogpagina. Wachtwoorden zet u er níet bij; die horen in een wachtwoordmanager waarvan de hoofdtoegang bij twee mensen bekend is.
- Domeinnaam. Bij welke registrar, op wiens naam, wanneer verloopt hij.
- Hosting. Welke partij, welk pakket, waar meldt u een storing, wat is de responstijd.
- DNS. Vaak een andere partij dan de hosting. Hier gaat het het vaakst mis.
- E-mail. Eigen server, of Microsoft 365 of Google. Bij een verhuizing is dit de kritieke.
- Back-ups. Waar staan ze, hoever gaan ze terug en wie kan erbij.
- Betaalprovider en koppelingen, als u een webshop heeft.
- SSL-certificaat. Automatisch of handmatig, en wanneer verloopt het.
Vult u dit blok in, dan ontdekt u vrijwel zeker iets dat niet klopt: een domein op naam van een oud-medewerker, of een hostingaccount waarvan alleen uw vorige bouwer de inloggegevens heeft. Dat is op zichzelf al de reden om dit een keer te doen.
Blok 3: de eerste beslissing
Zet één beslisregel op papier: wanneer haalt u de site offline. Dat lijkt drastisch, maar het is bij een besmetting bijna altijd de juiste zet en in het moment zelf durft niemand het te nemen.
Een werkbare formulering: bij een vermoeden van malware, van gestolen gegevens of van een overgenomen beheerdersaccount gaat de site direct in onderhoudsmodus, totdat is vastgesteld wat er speelt. Bij traagheid, een foutmelding of een mislukte update blijft de site online en wordt er hersteld.
Zet daaronder de tweede beslisregel: bewaar altijd eerst een kopie van de huidige situatie en de logbestanden voordat er iets wordt opgeruimd. Zonder die regel wordt in de haast precies het bewijsmateriaal gewist dat u nodig heeft om te achterhalen hoe men binnenkwam.
Blok 4: de eerste vijf handelingen
Kort en genummerd, zodat iemand die niet dagelijks in de techniek zit ze kan afwerken.
- Site in onderhoudsmodus zetten, of laten zetten door de hostingpartij.
- Kopie maken van bestanden, database en serverlogboeken, en die buiten de server bewaren.
- Wachtwoorden wijzigen van hosting, FTP, database en alle beheerdersaccounts, vanaf een schoon apparaat.
- Hostingpartij bellen en vragen of er meer sites zijn geraakt.
- Kort intern bericht sturen zodat niemand tegen klanten iets anders zegt.
Wat daarna volgt, is de eigenlijke opschoning. Die staat niet op uw A4, want dat is werk voor iemand die het vaker doet; het stappenplan daarvoor staat bij het herstel na een gehackte WordPress-site.
Blok 5: wat u aan klanten vertelt
Op het A4 staan hiervan alleen de kaders: wie het bericht schrijft, via welk kanaal het gaat en binnen hoeveel uur er iets naar buiten komt. De inhoudelijke opbouw hoeft u niet uit het hoofd te weten, maar de afspraak dat er binnen een dag iets gaat, wel.
Zet er ook bij welke persoonsgegevens u überhaupt bewaart, in drie steekwoorden. Dat is de eerste vraag die iedereen stelt en de vraag waar zonder voorbereiding de meeste tijd in gaat zitten. De verdere afweging staat beschreven bij wat u klanten na een incident laat weten.
Bijhouden zonder dat het werk wordt
Een plan van een jaar oud met verkeerde telefoonnummers is erger dan geen plan, want u vertrouwt erop en het klopt niet. Twee gewoontes houden het levend.
De eerste: zet een jaarlijkse herinnering in uw agenda, bijvoorbeeld tegelijk met de verlenging van uw domeinnaam. Loop dan alle regels na, vooral de namen en nummers. Dat is een kwartier werk en past prima bij de bredere jaarcontrole die u toch al doet op uw domein, uw licenties en uw certificaten.
De tweede: werk het plan bij op het moment dat er iets verandert. Nieuwe hostingpartij, vertrekkende medewerker, andere betaalprovider. Dat zijn precies de momenten waarop een plan ongemerkt verouderd raakt.
Bewaar het vel op twee plekken: digitaal in een gedeelde map, en op papier op kantoor. Dat laatste voelt ouderwets, maar als uw mailomgeving eruit ligt, is papier opeens het snelste medium dat u heeft.
Wat u ermee opschiet
Het rendement zit niet in het document maar in het invullen ervan. In vrijwel elk bedrijf komt er tijdens het opstellen minstens één losse eindje boven water: een back-up die al maanden niet meer draait, een certificaat dat handmatig verlengd moet worden, of niemand die weet waar het DNS staat. Die dingen vindt u nu op een rustige dinsdag in plaats van tijdens een storing.
Voor onze klanten stellen wij dit blad samen bij aanvang, omdat het de rest van het beschermen en herstellen van een website eenvoudiger maakt. U hoeft er niets van te onthouden; u moet alleen weten waar het ligt.
Concrete volgende stap: open een leeg document en vul blok 2 in, de vraag waar wat staat. Loopt u daar vast bij het DNS of de back-ups, dan heeft dit artikel zijn werk al gedaan.
