De bijlage waar niemand bij stilstond
Het document dat uitlekte, werd toegevoegd door iemand die het werk juist goed deed. Een fiscaal medewerker loopt tegen een rechtenfout aan bij de aangifte van een klant, opent een ticket bij het interne IT-team en voegt het bestand toe zodat de analist de storing kan reproduceren. Het ticket wordt diezelfde middag gesloten. Over de bijlage praat daarna niemand meer.
Ernst & Young heeft bekendgemaakt dat een onbevoegde derde toegang kreeg tot een extern IT-servicemanagementplatform dat de interne IT-teams gebruiken ter ondersteuning van de fiscale praktijk. In de woorden van EY zelf kunnen tickets die via het platform worden ingediend "documenten met fiscale informatie van klanten bevatten". De gemelde gegevenscategorieën omvatten persoons- en financiële gegevens die in belastingaangiften staan of zijn gebruikt om die op te stellen.
EY stelt dat de indringer tussen 28 maart 2026 en 12 april 2026 in het platform zat en documenten downloadde met betrekking tot een aantal klanten van EY. Het kantoor verklaart ook dat het geen weet heeft van misbruik of verdere blootstelling van de betrokken persoonsgegevens. Beide uitspraken staan op papier. Alleen de tweede stelt gerust.
Twee weken binnen, elf dagen tot ontdekking, drie maanden tot bericht
De data wegen hier zwaarder dan de techniek. De toegang liep van 28 maart 2026 tot 12 april 2026. EY stelde op 23 april 2026 afwijkende activiteit vast. De meldingsbrieven aan getroffen klanten zijn gedateerd 13 juli 2026 en op 15 juli 2026 werd een melding gedaan bij de procureur-generaal van Californië. Vier staten werden geïnformeerd.
Wat EY niet publiceerde weegt even zwaar. De leverancier achter het platform is niet genoemd. De initiële toegangsroute is niet bekendgemaakt. Er is geen aantal getroffenen gegeven en het blijft onduidelijk hoeveel klanten zijn geraakt. Geen enkele ransomwaregroep heeft de aanval opgeeist, waardoor de gebruikelijke publieke bron voor een inventaris van gestolen bestanden wegvalt.
Voor een klant van het kantoor is juist die combinatie het lastige deel. U weet dat uw documenten verplaatst kunnen zijn. U weet niet welke, u kent de toegangsroute niet en u kunt niets zelfstandig verifiëren omdat de logbestanden nooit bij u lagen. Alles wat u tegen een toezichthouder kunt zeggen, is een citaat van iemand anders.
De helpdesk is een gegevensopslag die niemand in kaart bracht
Het systeem dat lekte was niet het fiscale platform. Het was de ticketwachtrij. Dat onderscheid is de hele les en het geldt voor kantoren die veel kleiner zijn dan EY.
Medewerkers voegen klantdocumenten standaard toe aan tickets, omdat het bestand meesturen de snelste weg naar een oplossing is. In een paar jaar bouwt de helpdesk stilletjes een ongeclassificeerde, bij de leverancier ondergebrachte en onbeperkt bewaarde schaduwkopie op van het gevoeligste materiaal dat het kantoor bezit. Niemand heeft dat ontworpen. Het is een bijproduct van behulpzaamheid.
Op papier is het bovendien vrijwel onzichtbaar. Het ITSM-platform staat zelden op een gegevenskaart, komt zelden voor in een verwerkingsregister en leidt zelden tot een gegevensbeschermingseffectbeoordeling, omdat niemand de IT-helpdesk aanmerkt als plek waar klantgegevens wonen. Het fiscale platform krijgt de encryptietoets, de hercertificering van toegang en een bewaarbeleid. De wachtrij met kopieën van dezelfde documenten krijgt een licentieverlenging.
Uw termijn van 72 uur start wanneer uw verwerker dat bepaalt
De meldvertraging van een verwerker gaat rechtstreeks af van uw eigen nalevingsvenster. Onder de AVG loopt de meldplicht van 72 uur vanaf het moment waarop de verwerkingsverantwoordelijke kennis krijgt van het datalek. Doet de partij die uw gegevens houdt er bijna drie maanden over om u te bereiken, dan start uw termijn bijna drie maanden nadat de aanvaller klaar was.
Pas dat toe op deze data. Detectie op 23 april 2026, klantbrieven van 13 juli 2026. Een kantoor dat die brief ontvangt, opent half juli het gesprek met de Autoriteit Persoonsgegevens over downloads van eind maart, zonder eigen telemetrie, zonder genoemde leverancier en zonder omvang van blootstelling om te beschrijven.
Toezichthouders zijn niet onverschillig over wie de vertraging veroorzaakte, en een verantwoordelijke die voortvarend handelde op basis van de beschikbare informatie staat verdedigbaar. De praktijk blijft niettemin slecht: u legt een gat uit dat u niet veroorzaakte, met feiten die u niet kunt verifiëren, tegenover een autoriteit die terecht vraagt waarom uw contract die vertraging toestond.
Drie wijzigingen die lonen voor de volgende auditcyclus
Begin met uitzoeken wat uw ticketwachtrij feitelijk bevat. Exporteer een jaar aan bijlagen per bestandstype en neem steekproeven. De meeste kantoren die deze oefening doen, vinden loonbestanden, identiteitsdocumenten, getekende contracten en fiscale werkpapieren in gesloten tickets die jaren geleden zijn afgehandeld en vergeten.
Stel daarna bewaartermijnen in. Bijlagen bij opgeloste tickets moeten volgens een vast schema vervallen en automatisch worden verwijderd, en de standaard hoort in weken te worden gemeten. Waar het reproduceren van een storing echt klantgegevens vereist, moet het proces medewerkers naar een beheerde locatie sturen in plaats van naar het ticket, en het platform moet dat verschil kunnen aantonen.
Lees ten slotte het leverancierscontract specifiek tegen dit scenario. Controleer of het bereik van beschermde gegevens ticketteksten en bijlagen dekt en niet alleen de kernrecords van de leverancier. Controleer of de meldplicht is uitgedrukt in uren vanaf kennis bij de leverancier. Controleer of u recht hebt op de forensische details, inclusief de toegangsroute, die u nodig hebt tegenover uw eigen toezichthouder.
Lees hierna: 570 Windows-patches op een dag, twee al misbruikt | Roteer elk secret dat Grok Build ooit zag
