Incident response plan webshop: monitoring en draaiboek

Een webshop die om 02:00 wordt gehackt, heeft om 02:05 geen tijd voor een discussie over wie wat doet. Wie dan nog moet uitzoeken wie de hosting belt, wie de klant informeert en of de AP gemeld moet worden, verliest uren. Die uren kosten omzet en vertrouwen.

Een incident response plan webshop regelt dat vooraf. Het is geen document van 40 pagina's. Het is een pagina met namen, telefoonnummers en beslissingen die je op een rustige dinsdagmiddag maakt.

Dit artikel gaat over voorbereiden. Zit je er nu middenin? Lees dan Magento 2 gehackt: wat nu. Dat stuk beschrijft de eerste 24 uur. Dit stuk beschrijft wat je daarvoor regelt.

Wat is het verschil tussen monitoring en een incident plan?

Monitoring ziet dat er iets gebeurt. Het plan bepaalt wat je daarna doet. Je hebt beide nodig. Monitoring zonder plan levert alerts op waar niemand op reageert. Een plan zonder monitoring start pas als een klant belt of Google je shop als gevaarlijk markeert.

Let op: dit is geen performance monitoring. Daarover lees je in Magento 2 monitoring. Hier kijken we alleen naar signalen voor misbruik en inbraak.

Security monitoring webshop: wat je bewaakt

Bewaak signalen die bij een aanval horen, niet alles wat meetbaar is. Elke alert die geen actie oplevert, is ruis. Ruis zorgt ervoor dat de echte alert wordt genegeerd.

De zeven signalen

Hoe je dat inricht

• File integrity: vergelijk bestanden met je git-repository of een bekende hash-lijst. Wijzigingen buiten een deploy zijn per definitie verdacht.
• Admin-logs: stuur login- en gebruikersgebeurtenissen naar een plek waar de server zelf niets kan wissen. Een aanvaller met servertoegang ruimt lokale logs op.
• Checkout-scripts: houd een lijst bij van toegestane scripts op betaalpagina's. Een onbekend extern script is een alert.
• Egress: beperk uitgaand verkeer van de server tot wat nodig is (PSP, mailprovider, API's). Alles anders loggen of blokkeren.
• Uptime: check niet alleen de homepage. Check ook checkout, login en een betaalstap, en vergelijk de content op een vaste marker.
• Orders: stel een drempel in op het aantal mislukte betalingen per tien minuten. Dat vangt card testing.

Eerlijk advies: begin met bestandswijzigingen, nieuwe admin-gebruikers en admin-logins. Die zijn goedkoop en leveren de minste valse alarmen. Voeg de rest toe als de eerste drie stabiel draaien.

Alert routing: wie krijgt de melding?

Een alert die in een gedeelde inbox belandt, wordt door niemand opgepakt. Leg per signaal vast waar het naartoe gaat en wie reageert.

• Kritiek (nieuwe admin, bestandswijziging in checkout, onbekende uitgaande call): telefoon of pushmelding naar de incident lead én een back-up. Dag en nacht.
• Hoog (WAF-piek, mislukte-betalingspiek): chatkanaal en e-mail, reactie binnen een uur tijdens kantooruren.
• Info (losse mislukte logins): wekelijks overzicht. Geen push.

Spreek een back-up af voor vakanties en ziekte. Test de route elk kwartaal met een nepalert. Als de test faalt, weet je het nu.

Het incident plan op één pagina

Print het uit. Leg het ook buiten je eigen systemen, want bij een incident kan je mail of wiki weg zijn.

Rollen

In een klein bedrijf zijn dit twee of drie mensen met meerdere hoeden. Dat is prima. Zorg dat elke rol een naam heeft.

Beslisboom

1. Is er een verdenking? Noteer tijdstip en bron. Het uur waarop je het ontdekt, is straks relevant voor de meldtermijn.
2. Loopt de aanval nog? Ja: beperk eerst (zie hieronder). Nee: ga naar bewijs veiligstellen.
3. Zijn er persoonsgegevens of betaalgegevens mogelijk geraakt? Ja of onzeker: ga naar de meldbeoordeling. Behandel onzeker als ja tot je het tegendeel kunt aantonen.
4. Is checkout geraakt? Dan direct de PSP en acquirer informeren en overweeg de checkout tijdelijk uit te zetten.
5. Herstellen vanaf een schone staat, niet vanaf "opgeruimd".
6. Post-mortem binnen twee weken.

Beperken zonder bewijs te vernietigen

• Zet de shop in onderhoudsmodus of blokkeer verdacht verkeer op de WAF. Zet de server niet zomaar uit en wis niets.
• Roteer wachtwoorden en API-sleutels van admin, database, hosting en PSP. Doe dit pas als je een kopie van de logs hebt.
• Verwijder verdachte admin-accounts niet blind. Leg eerst vast wat ze deden.

Bewijs veiligstellen

• Maak een volledige kopie (snapshot) van de server of container voordat je opruimt.
• Exporteer webserverlogs, applicatielogs, admin-actielogs en WAF-logs naar een aparte plek.
• Noteer een tijdlijn: wie deed wat, wanneer, op basis waarvan.
• Bewaar kopieën van de kwaadaardige bestanden. Open ze niet op productie.

Dit bewijs heb je nodig voor de oorzaakanalyse, de verzekeraar en een eventuele melding.

Herstellen vanaf een schone backup

Een backup is pas bruikbaar als je weet wanneer de infectie begon. Terugzetten vanaf een besmette backup brengt de achterdeur terug.

• Bepaal het vroegste moment van compromittering uit de logs. Kies een backup daarvoor.
• Bouw code opnieuw op vanuit git en een schone composer-install. Kopieer geen bestanden van de oude server.
• Patch de kwetsbaarheid vóór je live gaat. Zie Magento 2 security patches zonder downtime.
• Wissel alle geheimen. Controleer admin-gebruikers en cronjobs op onbekende items.
• Test de volledige checkout met een testbetaling voordat je het verkeer terugzet.

Een restore-test hoort in je jaarplanning. Een backup die je nooit hebt teruggezet, is een aanname.

Communicatie

Bereid drie korte teksten voor: een statuspagina-bericht, een klantmail en een intern bericht. Houd ze feitelijk. Zeg wat er is gebeurd, wat het betekent voor de klant en wat die zelf moet doen (bijvoorbeeld wachtwoord wijzigen). Speculeer niet over oorzaak of omvang.

Post-mortem

Houd een sessie zonder schuldvraag. Beantwoord vier vragen: hoe kwamen ze binnen, hoe lang duurde het voor we het zagen, wat werkte in het plan en wat niet? Maak van elk antwoord een taak met een eigenaar en einddatum.

Datalek webshop melden: wanneer moet het?

Dit is geen juridisch advies. Beoordeel je situatie met een privacyjurist of je functionaris gegevensbescherming.

De hoofdregels onder de AVG:

• Melding aan de Autoriteit Persoonsgegevens (artikel 33 AVG): zonder onredelijke vertraging en uiterlijk 72 uur nadat je het datalek hebt ontdekt. Je meldt niet als het onwaarschijnlijk is dat het lek een risico voor de rechten en vrijheden van mensen oplevert.
• Melding aan betrokkenen (artikel 34 AVG): alleen bij een hoog risico. Dat is een hogere drempel dan voor de AP-melding. Veel datalekken moeten wel naar de AP, maar niet naar klanten.
• Te laat? Dan voeg je een onderbouwde reden voor de vertraging toe.
• Intern registreren: je documenteert elk datalek in een intern register, ook als je niet meldt.

Wat het risico verhoogt: inloggegevens, financiële gegevens, kopieën van identiteitsbewijzen en grote aantallen betrokkenen. Een gestolen e-mailadres met naam weegt anders dan wachtwoord-hashes met bestelhistorie.

De 72 uur lopen vanaf het moment dat je op de hoogte bent, niet vanaf de aanval. Daarom noteer je het ontdekmoment in stap 1 van de beslisboom. Je meldt via het meldformulier op de website van de AP. Controleer daar de actuele criteria en het formulier, want de AP past haar richtlijnen aan.

Verwerkt een externe partij gegevens voor jou (hosting, mailprovider, bureau)? Dan moeten zij jou volgens de verwerkersovereenkomst zonder vertraging informeren. Controleer dat die afspraak erin staat. Meer over privacyverplichtingen lees je in GDPR voor e-commerce in 2026.

PSP en acquirer

Zijn kaartgegevens mogelijk geraakt, of is je checkout gemanipuleerd? Informeer dan direct je PSP en acquirer. De exacte meldplicht en termijn staan in je contract en in de regels van de kaartnetwerken. Controleer dat bij je PSP en leg het contactpunt vast in je plan. Verwacht daarna vragen en mogelijk een forensisch onderzoek.

Template: beslissingen en meldingen

Veelgestelde vragen

Hoe snel moet ik een datalek melden bij de AP?

Zonder onredelijke vertraging en uiterlijk 72 uur nadat je het lek ontdekt, tenzij het onwaarschijnlijk is dat het een risico voor betrokkenen oplevert. Is je melding later, dan geef je de reden van de vertraging. Controleer de actuele regels op de website van de Autoriteit Persoonsgegevens. Dit is geen juridisch advies.

Moet ik klanten altijd informeren bij een datalek?

Nee. Klanten informeer je bij een hoog risico voor hun rechten en vrijheden, bijvoorbeeld bij gestolen betaalgegevens of inloggegevens. Voor de AP-melding geldt een lagere drempel. Twijfel je, laat dan een privacyjurist het risico beoordelen en leg de afweging schriftelijk vast.

Wat is het minimale security monitoring webshop-pakket?

Drie dingen: bestandswijzigingen buiten deploys, nieuwe admin-gebruikers en admin-logins buiten gewone patronen. Stuur kritieke alerts naar een telefoon met een back-up. Voeg daarna uitgaande verbindingen, WAF-events en orderafwijkingen toe.

Wat is een beveiligingsincident webshop en wat is een datalek?

Een beveiligingsincident is elke gebeurtenis die de veiligheid van je systemen bedreigt, zoals een malware-infectie of een gestolen admin-wachtwoord. Een datalek is een incident waarbij persoonsgegevens onbedoeld of onrechtmatig toegankelijk worden, vernietigd of gewijzigd. Niet elk incident is een datalek, maar je moet dat wel per incident beoordelen.

Wie moet het incident plan beheren?

Eén eigenaar, met een vaste back-up. Review het plan twee keer per jaar en na elk incident. Controleer telefoonnummers, PSP-contacten en de locatie van de printversie.

Je plan laten opzetten

Wij helpen je met monitoring, alert routing en een plan dat past bij jouw hosting en team. Bekijk wat we doen op security en Magento support, of neem contact op.