# AVG-meldplicht: 72 uur na het incident > Datalek en meldplicht binnen 72 uur: wat art. 33 en 34 AVG na een serveraanval vereisen en wat u nu moet documenteren. Algemene informatie, geen juridisch advies. Bron: https://phpsos.de/nl/compliance/dsgvo-meldepflicht-72-stunden/ Stand: 25-10-2026 Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **Kort gezegd:** Wordt bij een aanval de beveiliging van persoonsgegevens geschonden, dan vereist art. 33 AVG een melding aan de toezichthouder, indien mogelijk binnen 72 uur na kennisname, voor zover er een risico voor de betrokkenen bestaat. Bij een hoog risico komt volgens art. 34 de kennisgeving aan de betrokkenen erbij. Los daarvan moet u elke inbreuk documenteren. Deze pagina is algemene informatie en geen juridisch advies. > **Belangrijk:** > Geen juridisch advies: of en wanneer er in het individuele geval een meldplicht bestaat, beoordelen uw functionaris voor gegevensbescherming of een advocaat. Wij leveren de technische feiten waarop die beoordeling steunt. ## Datalek en meldplicht binnen 72 uur: wat art. 33 regelt Art. 33 AVG betreft de „inbreuk op de beveiliging van persoonsgegevens”. Bedoeld is elke beveiligingsinbreuk die leidt tot vernietiging, verlies, wijziging, ongeoorloofde openbaarmaking of ongeoorloofde toegang tot persoonsgegevens. Een gecompromitteerde webserver met klantendatabase, contactformulieren of sollicitantengegevens kan daaronder vallen. De melding aan de toezichthouder moet onverwijld en zo mogelijk binnen 72 uur worden gedaan nadat de verwerkingsverantwoordelijke kennis heeft genomen van de inbreuk. Ze vervalt als de inbreuk waarschijnlijk geen risico oplevert voor de rechten en vrijheden van natuurlijke personen. Wie later dan na 72 uur meldt, moet de vertraging motiveren. Informatie mag gefaseerd worden nagestuurd. ## Wat een melding moet bevatten Art. 33, lid 3, AVG noemt minimale inhoud. Bereid deze punten voor, ook als nog niet alles vaststaat: - aard van de inbreuk, zo mogelijk met categorieën en bij benadering het aantal betrokken personen en gegevensrecords - naam en contactgegevens van de functionaris voor gegevensbescherming of een ander contactpunt - waarschijnlijke gevolgen van de inbreuk - genomen of voorgestelde maatregelen om de inbreuk aan te pakken en mogelijke nadelige gevolgen te beperken Juist bij aanvallen op webservers is de omvang aanvankelijk vaak onduidelijk. Dan helpt een eerlijke eerste melding met de bekende stand en de aankondiging verdere bevindingen na te sturen. ## Wanneer begint de termijn na een serveraanval? De termijn sluit aan bij de kennisname, niet bij het tijdstip van de aanval. In de praktijk is de afbakening vaak lastig: een bericht over een kwetsbaarheid zoals PHP2Shell vormt alleen nog geen kennis van een inbreuk op de gegevensbescherming. Vindt u echter concrete aanwijzingen voor een inbraak, zoals een webshell of verdachte databasequery's, dan kan de situatie anders liggen. Documenteer daarom vanaf het begin met tijdstip wie wanneer welke informatie heeft ontvangen en welke stappen volgden. Dit tijdsoverzicht helpt bij de juridische beoordeling en bij vragen van de autoriteit. Een zorgvuldig technisch onderzoek, bijvoorbeeld door [IT-forensisch onderzoek](https://phpsos.de/nl/leistungen/it-forensik/), zoekt uit of en welke gegevens daadwerkelijk getroffen zijn. ## Kennisgeving aan betrokkenen volgens art. 34 Heeft de inbreuk waarschijnlijk een hoog risico voor de persoonlijke rechten en vrijheden tot gevolg, dan moeten ook de betrokken personen onverwijld worden geïnformeerd. Dat kan bijvoorbeeld het geval zijn bij toegangsgegevens, bankgegevens of gezondheidsgegevens. De kennisgeving moet in duidelijke en eenvoudige taal beschrijven wat er is gebeurd en minstens het contactpunt, de waarschijnlijke gevolgen en de genomen maatregelen vermelden. Art. 34 voorziet in uitzonderingen, bijvoorbeeld als de gegevens voor onbevoegden ontoegankelijk zijn gemaakt, zoals door versleuteling. Zou een kennisgeving aan elke afzonderlijke persoon onevenredige inspanning vergen, dan kan in plaats daarvan een openbare mededeling of een even doeltreffende maatregel in aanmerking komen. Of een uitzondering van toepassing is, hoort bij de juridische beoordeling. Hoe u klanten begrijpelijk informeert, beschrijft [Crisiscommunicatie na een aanval](https://phpsos.de/nl/compliance/krisenkommunikation/). ## Documentatieplicht volgens art. 33, lid 5 Los van de meldplicht vereist art. 33, lid 5, AVG elke inbreuk te documenteren: de feiten, de gevolgen en de genomen corrigerende maatregelen. Deze documentatie moet de toezichthouder in staat stellen de naleving te controleren. Dat geldt ook als u na onderzoek tot de conclusie komt dat geen melding nodig is. Voor webservers betekent dat in de praktijk: logs veiligstellen voordat ze worden geroteerd, vondsten met tijdstip vastleggen, beslissingen en hun motivering noteren. Bij PHP2Shell adviseert de vakpers serverlogs vanaf 20-10-2026 te bewaren. Een patch verwijdert bovendien geen reeds ingebrachte schadelijke software en bewijst niet dat er daarvoor niets is gebeurd. ## Praktisch verloop in de eerste uren 1. Vermoeden intern melden bij een vast aanspreekpunt en de functionaris voor gegevensbescherming erbij betrekken. 2. Bewijs veiligstellen: logs, bestandslijsten, database-uittreksels, voordat iets wordt verwijderd of opnieuw opgezet. 3. Technisch uitzoeken of persoonsgegevens getroffen kunnen zijn. 4. Juridische beoordeling van de meld- en kennisgevingsplicht, zo nodig met advocaat en verzekeraar. 5. Melding via het formulier van de bevoegde toezichthouder, aanvullingen bij nieuwe bevindingen. Een voorbereid [IT-noodplan](https://phpsos.de/nl/compliance/notfallplan-erstellen/) verkort deze stappen aanzienlijk. ## Hoe helpt PHP SOS concreet? - Wij leggen logs en systeemtoestanden zo vast dat ze bruikbaar blijven voor de beoordeling en een latere controle. - Wij zoeken technisch uit of en welke gegevens bereikbaar waren en leveren een begrijpelijke samenvatting voor functionarissen voor gegevensbescherming en advocaten. - Wij houden een tijdlijn bij van de technische bevindingen die u voor melding en documentatie kunt gebruiken. - Bij een bevestigde inbraak nemen we [Incident Response](https://phpsos.de/nl/leistungen/incident-response/) en opschoning over. ## Veelgestelde vragen **Vanaf wanneer lopen de 72 uur?** Volgens art. 33 AVG vanaf het moment waarop de verwerkingsverantwoordelijke kennis heeft genomen van de inbreuk. Wanneer dat in het individuele geval moet worden aangenomen, is een juridische beoordeling. Documenteer daarom nauwkeurig wanneer wie welke informatie had. **Moet elke beveiligingskwetsbaarheid worden gemeld?** Nee. Een kwetsbaarheid alleen is nog geen inbreuk op de beveiliging van persoonsgegevens. Meldplichtig kan het worden als er aanwijzingen zijn dat onbevoegden toegang hadden of konden hebben tot dergelijke gegevens, en daaruit een risico voor betrokkenen ontstaat. **Wat als ik na 72 uur nog niet alles weet?** Art. 33, lid 4, AVG staat toe informatie gefaseerd na te sturen als die niet tegelijk kan worden verstrekt. Een late melding moet worden gemotiveerd. Wachten op volledige duidelijkheid is daarom in de regel geen reden om de termijn te laten verstrijken. **Wie meldt als de hostingprovider getroffen was?** Meldplichtig is de verwerkingsverantwoordelijke, dus in de regel het bedrijf dat de website exploiteert. Een verwerker zoals de hostingprovider moet de verwerkingsverantwoordelijke volgens art. 33, lid 2, AVG onverwijld informeren. **Waar meld ik een datalek?** Bij de bevoegde toezichthoudende autoriteit voor gegevensbescherming; voor bedrijven in Duitsland is dat meestal de autoriteit van de deelstaat waar ze gevestigd zijn. De meeste autoriteiten bieden daarvoor onlineformulieren aan. ## Bronnen - [AVG art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/) - [BSI](https://www.bsi.bund.de/) - [php.net: beveiligingsmeldingen](https://www.php.net/)