Veelgemaakte fouten bij melding van inbreuken op persoonsgegevens die SaaS-teams nog steeds maken

De meest voorkomende fouten zijn zelden exotische juridische fouten. Het zijn operationele fouten: de beoordeling te laat openen, niet bevestigen of persoonsgegevens betrokken zijn, rollen verwarren, klantmelding gelijkstellen aan toezichthoudermelding en bewijs verspreid laten staan.

Volgens artikel 33 AVG moet de verwerkingsverantwoordelijke de bevoegde toezichthouder zonder onredelijke vertraging en waar mogelijk binnen 72 uur na kennisname melden, tenzij de inbreuk waarschijnlijk geen risico oplevert. Artikel 34 voegt communicatie aan betrokkenen toe bij waarschijnlijk hoog risico. Verwerkers moeten de verantwoordelijke zonder onredelijke vertraging informeren.

Waarom goede teams dit toch missen

SaaS-teams hebben vaak incident response, security owners, support, legal review en executive escalation. Maar die onderdelen staan in verschillende tools en gebruiken verschillende klokken. Security volgt detectie, legal heeft kennisname nodig, customer teams kijken naar contracten en engineering kent de systemen.

Als dit vooraf niet verbonden is, gaan de eerste uren naar het bouwen van het model.

Fout 1: wachten op zekerheid

Het record helpt beslissen of melding nodig is. Het moet bekende feiten, onzekerheden, owners en volgende review bevatten. Als er geen persoonsgegevens zijn of de drempel niet wordt gehaald, sluit je het met reden.

Fout 2: de verkeerde klok volgen

De 72 uur zijn niet altijd begin incident, eerste alert of root cause. De operationele vraag is wanneer de organisatie kennis kreeg van een inbreuk op persoonsgegevens. Contracten kunnen kortere klanttermijnen bevatten.

Fout 3: een enkele AVG-rol aannemen

Een SaaS-bedrijf kan verantwoordelijke zijn voor accounts, billing, HR, marketing, analytics of logs, en verwerker voor klantcontent. Rollen moeten per dataset worden vastgelegd met contract, beslisser en verplichting.

Fout 4: risico en hoog risico verwarren

Artikel 33 en artikel 34 hebben verschillende drempels. Toezichthoudermelding en communicatie aan betrokkenen moeten apart worden beoordeeld en gedocumenteerd.

Fout 5: te veel vertrouwen op encryptie of containment

Encryptie en containment zijn bewijs, geen shortcuts. Controleer beschermde data, sleutels, metadata, integriteit, beschikbaarheid en resterend risico.

Fout 6: klantplichten buiten het workflow laten

Enterprise-contracten kunnen termijnen, inhoud, contacten en samenwerking verplichten. Die moeten zichtbaar zijn in het incidentproces.

Fout 7: bewijs verliezen

Een goede response moet bewijsbaar zijn. Tijdlijn, scope, approvals, meldingen, vendorbevestigingen en remediation horen in een verbonden bewijspakket.

Fout 8: sluiten na melding

Melding is niet het einde. Sluiting moet probleem, containment, beslissing, remediation, owner, deadline, verificatie en control improvement tonen.

Voorbeeld

Een permissiebug toont supportbijlagen tussen twee klantworkspaces. Security lost het snel op. Een volwassen workflow opent het record, controleert bijlagen en logs, bevestigt rollen per dataset, controleert DPA, beoordeelt risico en hoog risico, bewaart bewijs en volgt remediation.

FAQ

Wat moeten teams begrijpen?

Dat melding een tijdgevoelig workflow is met securityfeiten, privacy, rollen, juridische beslissingen, klantplichten, bewijs en remediation.

Waarom is dit belangrijk?

Een inbreuk wordt snel een kwestie van klantvertrouwen, audit, legal, security en leadership.

Wat is de grootste fout?

Melding behandelen als een eenmalige juridische interpretatie in plaats van een herhaalbaar proces met owners, triggers, bewijs en escalatie.

Bronnen

• European Union, General Data Protection Regulation.
• European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR.
• Information Commissioner's Office, Personal data breaches - a guide.
• Information Commissioner's Office, 72 hours - how to respond to a personal data breach.