Organization for Transformative Works
The exposed field was an email address. On a severity scale built for identity theft, that scores near zero. For these users it is the whole harm.
What happened?
The Organization for Transformative Works, the nonprofit that operates Fanlore and Archive of Our Own, disclosed a breach exposing email addresses, password hashes, and IP addresses. No threat actor has been publicly attributed and the affected count has not been disclosed as of this writing.
The OTW is a volunteer-run nonprofit. Its platforms host fan-created writing and reference material for a very large user base that publishes under pseudonyms.
What data was actually inside?
Email addresses, password hashes, and IP addresses. No financial data, no government identifiers, no health records.
By the field list, this is one of the mildest datasets covered in this series. That is precisely why it is worth covering. Severity models used across the industry — and encoded into most breach notification statutes — score data by its usefulness for identity theft and financial fraud. Against that model this dataset is near the bottom.
The model is measuring the wrong thing here. What makes this dataset dangerous is not any field in isolation. It is the join: a public pseudonym linked to a private email address.
Who gets hurt and how?
These platforms are built on pseudonymity, and the pseudonymity is load-bearing. Users publish under handles specifically so their legal identity is not attached to what they write, because the work often touches sexuality, gender, religion, and personal expression they have chosen not to connect to their employer, their family, or their government.
A breach that links the pseudonym to an email address collapses that separation permanently, and usually trivially — most people reuse one email across their pseudonymous and professional lives, so the mapping requires no skill. IP addresses narrow further, to a city and frequently to an employer's or university's network.
For a user in a jurisdiction where their writing is criminalised, or living with family who do not know they are queer, the harm is not fraud. It is exposure, and it does not expire.
What did they think they were doing right?
Data minimisation, and they were right to. The OTW collects strikingly little: no real names, no addresses, no payment details tied to accounts, no demographic profiling. Compared to a commercial platform serving the same user base, the collected footprint is a fraction of the size. Password hashing was in place.
Minimisation reduced the field count. It could not reduce the sensitivity of the fields that remained, because the sensitivity comes from the population rather than the schema. An email address in a corporate CRM and an email address in a pseudonymous community are the same data type and completely different risks.
What did they not know about their own data?
The lesson generalises well beyond fan communities. Sensitivity is a property of the relationship between the data and the person, not a property of the column. Every classification tool in common use asks what type a field is. Almost none asks who the population is and what disclosure would cost them.
A mailing list of conference attendees and a mailing list of support group members are structurally identical and carry entirely different risk. So do a customer email table and a whistleblower contact table. Organisations serving vulnerable, stigmatised, or pseudonymous populations hold high-consequence data in low-severity fields, and the standard tooling will report a clean bill of health.
IP addresses are the underrated element. Retained for abuse prevention, rarely classified, and sufficient to locate a person who took deliberate steps not to be located.
If your business runs on databases, you probably have similar records—customer data, credentials, financial information. Do you know what's actually in yours?
What does attribution look like the morning after?
Under most US state statutes, an email address plus a password or hash triggers notification; an email address alone frequently does not. Under GDPR, email and IP address are both personal data, so the 72-hour supervisory authority clock applies for EU users and the risk assessment must weigh consequences to the individual — a framework that handles this incident considerably better than the US patchwork does.
The practical difficulty is that the affected users are global, pseudonymous, and reachable only through the exposed email addresses. There is also a notification paradox worth naming: an email warning a user that their pseudonymous account was breached is itself a message linking that account to that inbox, which may be read by someone other than the user. Volunteer-run nonprofits carry all of this with no legal budget.
What would have changed the outcome?
Knowing which of your datasets describe a population for whom being identified is itself the harm — and treating those as your highest tier regardless of what fields they contain.
The OTW did the hard part already by collecting almost nothing. The remaining question is one every organisation should be able to answer and most cannot: which of our tables link a public identity to a private one? Support communities, reporting hotlines, HR investigations, and pseudonymous platforms all hold that join, usually in fields no classifier flags. If your inventory sorts by data type alone, it will rate this file as low risk right up until it is published. See also our analysis of the Suisun City dispatch incident, another dataset whose harm no statute measures.
The Organization for Transformative Works found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.