AVG vs. de EU Cyber Resilience Act: wat WordPress-sitebeheerders moeten weten

Twee EU-regelgevingen, twee verschillende taken

Het is makkelijk om de AVG en de EU Cyber Resilience Act (CRA) op één hoop te gooien — beide zijn EU-regelgeving, beide brengen serieuze boetes met zich mee, en beide worden genoemd in dezelfde "compliance checklist"-gesprekken. Maar ze reguleren echt verschillende dingen, en ze als verwisselbaar behandelen laat echte gaten open.

De AVG gaat over data: welke persoonlijke informatie je verzamelt, waarom, hoe lang je die bewaart, en welke rechten de mensen achter die data hebben. De CRA gaat over softwarebeveiliging: hoe veilig een digitaal product is gebouwd, hoe kwetsbaarheden worden gemeld, en hoe beveiligingsupdates worden geleverd gedurende de levensduur van het product.

Een WordPress-site kan volledig AVG-conform zijn — correcte cookietoestemming, een duidelijk privacybeleid, verwerkersovereenkomsten — en niets hebben van wat de CRA verwacht. Het omgekeerde is ook waar. Het zijn geen overlappende vakjes op dezelfde lijst; het zijn twee gescheiden lijsten.

Wat de AVG daadwerkelijk dekt

De Algemene Verordening Gegevensbescherming, van kracht sinds 2018, regelt hoe persoonsgegevens worden verzameld, opgeslagen, verwerkt en gedeeld. Voor een typische WordPress-site raakt dit aan:

• Cookietoestemming — analytics-, advertentie- en trackingcookies vereisen expliciete opt-in-toestemming voordat ze laden, niet alleen een mededelingenbanner.
• Privacybeleid — een duidelijke, toegankelijke uitleg van welke data je verzamelt (contactformulieren, reacties, analytics, e-commerce bestellingen) en wat je ermee doet.
• Rechten van betrokkenen — mechanismen voor bezoekers om hun data op te vragen, correctie te vragen, of verwijdering te verzoeken.
• Verwerkersovereenkomsten — contracten met elke externe dienst die data namens jou verwerkt (e-mailproviders, analyticstools, hosting).
• Meldplicht bij datalekken — een proces om datalekken binnen 72 uur te melden aan de bevoegde autoriteit, als persoonsgegevens worden blootgesteld.

Niets hiervan heeft te maken met de beveiliging van je code, je plugins, of hoe kwetsbaarheden worden gemeld. De AVG maakt het niet uit of je contactformulier-plugin een ongepatchte SQL-injectiebug heeft — het gaat erom wat er gebeurt met de data die erdoorheen stroomt zodra die is verzameld.

Wat de CRA daadwerkelijk dekt

De Cyber Resilience Act, waarvan de handhaving tot 2027 gefaseerd wordt ingevoerd, regelt de beveiliging van producten met digitale elementen die op de EU-markt worden verkocht. Het richt zich primair op fabrikanten — inclusief softwareleveranciers, wat WordPress-plugin- en thema-ontwikkelaars omvat — in plaats van op elke website-exploitant. Voor een ontwikkelaar of leverancier betekent dit:

• Secure-by-design-ontwikkeling — software bouwen waarbij beveiliging vanaf het begin wordt meegenomen, niet er achteraf aan vastgeplakt.
• Beleid voor het melden van kwetsbaarheden — een gedocumenteerd, openbaar proces voor beveiligingsonderzoekers om kwetsbaarheden te melden (hier komt security.txt om de hoek kijken).
• Beveiligingsupdates — een toezegging om bekende kwetsbaarheden te patchen voor een vastgestelde supportperiode, en gebruikers te informeren wanneer een beveiligingsupdate beschikbaar is.
• Software Bill of Materials (SBOM) — voor veel producten, een gedocumenteerde lijst van de gebruikte softwarecomponenten en afhankelijkheden, zodat gebruikers en toezichthouders de blootstelling kunnen beoordelen wanneer een component een bekende kwetsbaarheid heeft.
• Incidentmelding — bevoegde autoriteiten (ENISA) informeren over actief misbruikte kwetsbaarheden binnen strakke tijdsbestekken.

Als je een sitebeheerder bent die gewoon plugins van WordPress.org installeert in plaats van iemand die software bouwt en distribueert, komen de directe verplichtingen van de CRA meer neer op de pluginontwikkelaars dan op jou — maar als je bedrijf een plugin, thema, of enig digitaal product met EU-klanten bouwt en verkoopt, geldt dit direct voor jou.

Een vergelijking naast elkaar

Waarom beide belangrijk zijn voor een WordPress-bedrijf

Als je een WordPress-bureau runt, plugins of thema's ontwikkelt, of een site beheert die data van EU-bezoekers verwerkt, zijn beide regelgevingen realistisch relevant — alleen voor verschillende delen van je activiteiten:

• De gegevensverzameling van je website (contactformulieren, analytics, e-commerce) valt onder de AVG.
• Elke software die je bouwt en distribueert — een plugin, een thema, een SaaS-product — valt onder de CRA.

Veel WordPress-bedrijven hebben de AVG-kant al op orde, omdat die al sinds 2018 wordt gehandhaafd en de meeste bureaus dit jaren geleden al in hun proces hebben ingebouwd. De CRA is nieuwer en wordt veel minder vaak aangepakt, wat precies is waar het gat meestal zit.

Het CRA-gat dichten

Als je een WordPress-plugin of -thema ontwikkelt en distribueert, is het praktische startpunt voor CRA-gereedheid de documentatie: een beleid voor het melden van kwetsbaarheden, een security.txt-bestand, en idealiter een SBOM met je afhankelijkheden. Erdo CRA Compliance scant een WordPress-site tegen CRA-, AVG- en NIS2-vereisten en genereert de door de CRA verwachte documentatie — beleid voor het melden van kwetsbaarheden, SBOM, security.txt — in één keer, in plaats van elk onderdeel handmatig te bouwen.

Kortom

De AVG en de CRA zijn geen concurrerende regelgevingen of twee versies van dezelfde vereiste — ze dekken volledig verschillende risico's. "Wij zijn AVG-conform" behandelen als bewijs van bredere compliance laat de softwarebeveiligingskant volledig onaangepakt. Als je WordPress-bedrijf software bouwt of distribueert, verdienen beide afzonderlijke aandacht, afzonderlijke documentatie, en het aanpakken van afzonderlijke risico's.