Every privacy officer has heard myths about metadata and personal data. These myths appear in engineering meetings, processor contracts, and sometimes even inform decisions that create real risks. The Gyazo breach, which exposed 23.62 million user records and metadata from 490 million images after an attacker exploited a vulnerability on September 11, 2026, shows why you can't afford to let these myths persist.
These myths survive because they're convenient. Treating metadata as out-of-scope simplifies data mapping, and assuming encryption solves everything reduces security budgets. But convenience isn't a lawful basis, and these assumptions create gaps that attackers exploit and supervisory authorities penalize.
Myth 1: Image metadata isn't personal data
Reality: Metadata becomes personal data the moment it relates to an identifiable individual, and image metadata often does just that.
The Gyazo breach exposed metadata including upload IP addresses, User-Agent strings, EXIF location information, OCR-extracted text from images, and image IDs that could reconstruct URLs to view the actual content. This isn't just technical data, it's a map to individual behavior, location, and content.
Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. IP addresses qualify under Recital 30. EXIF location data obviously does. Even image IDs become personal data when they enable access to content uploaded by specific users. Your data inventory can't exclude metadata just because it sits in a different table or feels less sensitive than a password hash.
The practical test: can this metadata, alone or combined with other information you hold, identify someone or reveal something about them? If yes, it's personal data subject to the same Article 5 principles, lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, and accountability.
Myth 2: Password hashing means you don't have to notify users
Reality: Hashed passwords remain personal data, and Article 34 notification obligations don't disappear because you applied a cryptographic function.
Helpfeel exposed password hashes in this breach and still needed to advise users to change their passwords immediately, especially if they reused credentials elsewhere. A hash isn't encryption, it's a one-way function designed to verify credentials, not protect them in transit. Modern GPUs can test billions of hash candidates per second against common password lists. If your users chose weak passwords, hashing bought you hours or days, not immunity from notification.
Article 34(1) requires you to communicate a personal data breach to affected data subjects "without undue delay" when it's likely to result in a high risk to their rights and freedoms. Article 34(3)(a) provides an exception only when you've applied appropriate technical and organizational measures that render the data unintelligible to unauthorized persons, specifically citing encryption. Hashing doesn't qualify. Neither does "we salted it" or "we used bcrypt." Those measures reduce risk; they don't eliminate notification obligations.
Your incident response plan should assume that any credential exposure, hashed or not, triggers individual notification unless you've applied encryption with keys the attacker didn't obtain.
Myth 3: Anonymous accounts mean no breach notification required
Reality: The presence of anonymous accounts in your dataset doesn't exempt you from Article 33 or 34 obligations for the identifiable records.
Helpfeel noted that the 23.62 million exposed records included anonymous accounts and didn't necessarily represent the same number of identifiable individuals. That's accurate context for assessing scope, but it doesn't reduce their reporting obligations. They still reported to Japan's Personal Information Protection Commission on September 15, three days after detecting suspicious activity, because the dataset contained identifiable user information including email addresses, login session IDs, and Google SSO email addresses.
Article 33(1) requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, unless it's unlikely to result in a risk to rights and freedoms. You assess that risk based on the identifiable data exposed, not the percentage of anonymous records that padded the total count. If 30% of your exposed records are identifiable and meet the high-risk threshold, you notify for those records. You don't average down the risk by including the anonymous ones in your denominator.
Document your identifiability assessment. Show which records contained direct identifiers, which contained pseudonyms linkable to identifiers you hold elsewhere, and which were genuinely anonymous. That documentation supports your notification decisions and demonstrates accountability under Article 5(2).
Myth 4: Private/password-protected content is safe from GDPR obligations
Reality: Access controls are technical measures that can fail, and you remain the controller responsible for that content under Article 5(1)(f).
Gyazo allowed users to protect images with hashed passphrases, creating a private-image feature. The attacker obtained both a list identifying which images were private and the metadata needed to construct URLs to those images. Helpfeel correctly stated it couldn't rule out that some private images were viewed. That uncertainty alone triggers notification obligations.
Your users' expectation of privacy, reinforced by a password or access control, doesn't transfer your controller obligations to them. You're still processing their personal data. You're still responsible for implementing appropriate technical and organizational measures under Article 32. When those measures fail and private content becomes accessible, you've experienced a confidentiality breach that likely results in high risk.
This matters for any service that hosts user-generated content with privacy controls: document repositories, collaboration platforms, media libraries. The privacy setting is a feature you provide, not a legal boundary that ends your responsibility. Your Article 30 processing record should identify this content, your Article 32 measures should protect it, and your incident response plan should account for scenarios where those controls fail.
Myth 5: Suspending the service mitigates your notification timeline
Reality: Article 33's 72-hour clock starts when you become aware of the breach, not when you've finished investigating or restored service.
Helpfeel detected suspicious activity on the evening of September 11, blocked access routes and terminated connections by early September 12, confirmed data extraction on September 14, and reported to the supervisory authority on September 15. They also temporarily suspended image delivery as a precaution. That's a defensible timeline, detection to authority notification in four days, with active containment and investigation throughout.
But "we need more time to investigate" doesn't pause the 72-hour requirement. Article 33(1) runs from when you became aware, which Recital 85 clarifies means when you have a reasonable degree of certainty that a security incident has occurred that led to personal data being compromised. Helpfeel became aware on September 11 when they detected the suspicious activity. The clock started then.
You can submit an initial notification within 72 hours and provide additional information in phases under Article 33(4) as your investigation continues. You can't wait until you've quantified every exposed record, identified every affected individual, and rebuilt your infrastructure. Set your incident response thresholds to trigger initial notification based on reasonable indicators of compromise, not complete forensic certainty.
What to Do Next
Start with your data inventory. Map metadata the same way you map primary records, identify what you collect, where it's stored, how long you retain it, and whether it relates to identifiable individuals. Image metadata, log files, and analytics data aren't exempt from Article 30 documentation requirements.
Review your Article 32 measures for metadata stores. The Gyazo attacker exploited a vulnerability in an upload server to access backend systems. Your threat model should assume that any internet-facing service is a potential entry point and that lateral movement to backend databases is a realistic attack path. Segment your networks, restrict database access, monitor for anomalous queries, and test your detection capabilities.
Update your incident response plan to include metadata scenarios. Define what constitutes "awareness" of a breach for Article 33 purposes. Identify who makes the notification decision and on what timeline. Draft template notifications for common breach types so you're not writing from scratch under a 72-hour deadline. Test the plan with tabletop exercises that include metadata exposure, not just the obvious scenarios like stolen laptops.
Finally, train your engineering and product teams on what counts as personal data. The myth that metadata is out-of-scope often starts in architecture discussions where privacy input arrives too late. When someone proposes logging IP addresses or extracting text from user images, the privacy assessment should happen before deployment, not after the breach.
