Een website die offline gaat kost geld. Dat is niet verrassend. Wat ondernemers regelmatig onderschatten is hoe die kosten zich opstapelen zodra de oorzaak geen serverprobleem blijkt te zijn, maar een inbraak. Ransomware, datadiefstal, een geïnjecteerd script dat klantgegevens doorstuurt naar een externe server: het zijn geen abstracte gevaren voor grote corporates. Ze treffen ook de regionale dienstverlener, de webshop met tienduizend orders per jaar en het MKB-bedrijf met een ledenportaal. Ik zie het in projecten waarbij ik word ingeschakeld nadat het al is misgegaan, en dan is de rekening altijd hoger dan van tevoren gevreesd.
Wat er werkelijk stil valt na een hack
De directe schade is het makkelijkst te berekenen. Een webshop die twee dagen offline staat, loopt omzet mis. Maar dat is nog het minst ingrijpende onderdeel. Zodra een site is gecompromitteerd, moeten alle wachtwoorden gereset worden, moeten klanten worden geïnformeerd, moet een forensisch onderzoek uitwijzen hoe de aanvaller is binnengekomen en of er data is buitgemaakt. Dat onderzoek kost tijd en geld, en die tijd gaat ergens anders niet naartoe.
Hosting providers blokkeren geïnfecteerde accounts soms direct, zonder vooraankondiging. De e-mail die via hetzelfde domein loopt, valt dan ook weg. Facturatie, klantenservice, interne communicatie: dat staat allemaal stil terwijl je probeert te achterhalen wat er is gebeurd. Als de back-up niet goed was ingericht, of als die back-up ook is aangetast, begin je feitelijk opnieuw. Dat herstarten vanaf nul duurt bij een gemiddeld WordPress-project met meerdere plugins al snel twee tot vijf werkdagen.
Minder zichtbaar maar structureel schadelijk is wat er daarna gebeurt. Google detecteert geïnjecteerde malware via de Search Console en markeert de site als onveilig. Browsers tonen een rode waarschuwing voor bezoekers. Zelfs nadat de site is opgeschoond, duurt het weken voordat die markering wordt opgeheven, en in die weken daalt het organische verkeer consistent. Een hersteltraject voor de zoekmachineposities telt dan bij de totaalschade op.
Waarom beveiliging zelden prioriteit krijgt voor het te laat is
Een beveiligde site ziet er aan de buitenkant precies hetzelfde uit als een onbeveiligde site. Dat maakt het lastig om de investering erin te rechtvaardigen. De neiging is om beveiliging te zien als een technische luxe, iets wat pas nodig is als het bedrijf groeit of als er "écht gevoelige" data in het spel is. Dat is precies de redenering die aanvallers exploiteren.
Geautomatiseerde aanvallen schalen naar duizenden sites tegelijk. De bots die kwetsbaarheden scannen maken geen onderscheid op bedrijfsgrootte. Ze zoeken op verouderde plugin-versies, bekende PHP-lekken, zwakke authenticatie of open uploadmappen. Een kleine webshop met een druk aangevallen WooCommerce-plugin is net zo kwetsbaar als een groot platform, en soms makkelijker doelwit omdat er minder monitoring is. De vraag is daarmee niet óf een site aangevallen wordt, maar of de aanvaller iets kan doen zodra hij probeert in te breken.
Daar zit ook het argument voor preventief investeren. Een goede beveiligingssetup, inclusief juiste headers, dichte upload-eindpunten, rate limiting op inlogpagina's en een waterdicht update- en back-upbeleid, kost een fractie van wat een hersteltraject kost. Ik richt dergelijke setups standaard in bij elk project dat ik bouw, niet als premium optie maar als onderdeel van een deugdelijke oplevering. Maar bij overgenomen projecten, sites die zijn gebouwd door iemand anders of door de ondernemer zelf via een goedkope websitebouwer, ontbreken die lagen regelmatig volledig.
De GDPR-dimensie die ondernemers over het hoofd zien
Persoonsgegevens die worden gestolen door een inbraak op jouw website vallen onder de meldplicht datalekken. Je hebt 72 uur de tijd om een datalek bij de Autoriteit Persoonsgegevens te melden zodra je er kennis van hebt genomen. Die termijn is krap, zeker als je nog bezig bent te achterhalen wat er is misgegaan. Een te late of onvolledige melding kan resulteren in een boete, bovenop de schade die de inbraak zelf al heeft veroorzaakt.
Klanten en gebruikers hebben recht op transparantie. Als hun naam, e-mailadres of betalingsinformatie op straat ligt, moet je ze dat vertellen. Die communicatie kost tijd en personeel, heeft directe impact op klantvertrouwen en kan leiden tot opzeggingen, klachten of zelfs civiele claims. Het draait dan niet meer om een technisch incident: het wordt een juridisch en reputatiedossier.
De ironie is dat de AVG-compliance waar ondernemers soms tegenaan hikken bij het opzetten van een nieuwe site, later als bescherming werkt. Een verwerkersovereenkomst, een correct privacybeleid en een technisch systeem dat zo min mogelijk persoonsgegevens opslaat: dat zijn geen formaliteiten maar concrete risicobegrenzers. Bij het bouwen van portalen en webapplicaties stel ik deze zaken altijd vroegtijdig in het project aan de orde, niet als verplichte checkbox maar omdat het de omvang van mogelijke schade direct beperkt.
Wat een degelijke beveiligingslaag concreet inhoudt
Beveiliging is geen product dat je eenmalig aanschaft, maar een set van maatregelen die je inbouwt en daarna structureel onderhoudt. Op serverniveau gaat het om zaken als firewallregels die ongebruikelijke verzoeken blokkeren, SSH-toegang die uitsluitend via sleutelparen werkt en geen wachtwoorden accepteert, en een logstructuur die afwijkend gedrag signaleert. Bij applicaties zoals Laravel of op maat gebouwde PHP-systemen stel ik daar bovenop een Content Security Policy in, valideer ik alle invoer server-side en zorg ik dat gevoelige routes achter authenticatie zitten die token-gebaseerd werkt.
Voor bestaande sites die niet door mij zijn gebouwd, begin ik met een audit. Daarin kijk ik naar verouderde dependencies, misconfigureerde permissies, onbeschermde eindpunten en de kwaliteit van de back-upstrategie. Uit die audit volgt een concreet actieplan met prioriteiten, zodat je als ondernemer weet wat er moet gebeuren en in welke volgorde. Je hoeft geen technische kennis te hebben om die uitkomst te begrijpen: het gaat uiteindelijk om risico's en wat ze je kosten als ze zich materialiseren.
Cloudflare speelt in veel van mijn setups een rol als eerste verdedigingslinie. Het verkeer loopt dan via Cloudflare's netwerk, dat DDoS-aanvallen absorbeert, botverkeer filtert en aanvallen afstopt voordat ze je server bereiken. Dat is niet alleen beveiliging, het verbetert ook de laadtijd voor bezoekers, wat direct effect heeft op conversie en zoekmachine-ranking. Beveiliging en performance zijn in de praktijk geen concurrerende belangen; ze versterken elkaar.
De back-upstrategie is het meest onderschatte onderdeel. Een dagelijkse back-up op dezelfde server is bij een aanval waardeloos als de aanvaller die server heeft aangetast. Offsite back-ups, bij voorkeur naar een afzonderlijke cloudopslag met aparte toegangsreferenties, maken het verschil tussen een hersteltraject van een halve dag en een hersteltraject van een week. Dit is iets wat ik altijd meeneem in het advies, ongeacht de grootte van het project.
Wat ik zelf altijd eerlijk zeg: geen enkele maatregel is een absolute garantie. Beveiliging is risicobeheer, geen verzekering die elke schade uitsluit. Maar het verschil tussen een slecht beveiligde en een goed beveiligde site is het verschil tussen een aanvaller die in vijf minuten binnen is en een aanvaller die het na tientallen pogingen opgeeft en naar een eenvoudiger doelwit gaat. Dat is de realistische doelstelling, en die is haalbaar.
Op https://pimvdmolen.nl/diensten/beveiliging lees je hoe ik beveiligingsaudits en structurele beveiligingssetups aanpak, zowel voor nieuwe projecten als voor bestaande sites die je wilt laten doorlichten. Wil je weten waar jouw situatie staat, neem dan contact op via https://pimvdmolen.nl/contact, dan kijk ik met je mee.