Ask an engineering team whether they've built a PII vault and most will say no. Ask them where personal data is encrypted, who rotates the keys, which service handles erasure requests, and where the audit trail lives — and a different picture emerges. The vault exists. It just doesn't have a name, an owner, or a line on the roadmap.
This is how it happens, and it happens the same way almost everywhere.
It starts with a users table. Email, name, maybe a phone number. Nothing dramatic — the framework hashes passwords, the database is on a private network, TLS is on. Personal data is just data.
Then the product grows. Support tooling needs to look up customers. Analytics wants signup cohorts. Marketing exports lists. Invoicing needs billing addresses. Each integration copies personal data somewhere new: a replica, a warehouse, a third-party CRM, a CSV in someone's inbox. None of these steps is a decision about personal data. Each is a decision about a feature, with personal data along for the ride.
At some point, the first serious customer sends a security questionnaire, or the first data subject request arrives, or a new regulation applies. Now someone has to answer questions the architecture was never designed to answer: where exactly does personal data live, who can access it, how is it encrypted, how do we delete it everywhere?
The honest answer — "we're not entirely sure" — is not acceptable, so engineering starts patching. Encryption at rest gets enabled per datastore. A key management story gets written, usually starting with keys in environment variables and slowly graduating to a proper KMS. Logging gets scrubbed after someone finds an email address in a stack trace. A deletion script gets written for the main database, and then a longer one when someone remembers the warehouse.
Each patch is reasonable. Together they form something bigger: a distributed, undocumented system for protecting personal data, implemented as a thin layer smeared across every service that touches it.
By now the accidental vault has recurring costs that no one accounts for as a single line item, because it isn't one. It's a fraction of the security engineer's week (key rotation, cipher upgrades, questionnaire answers). A fraction of the DBA's week (encrypted backups, restore tests, column-level permissions). A fraction of a backend engineer's week (masking, serializers, "careful with that field" code reviews). A fraction of DevOps (hardened hosts, segmented networks, monitoring for data-access anomalies). And a compliance backlog — subject access, erasure, retention — that never quite empties, because personal data keeps spreading faster than the tooling that manages it.
Add those fractions up across a mid-sized engineering org and you typically land somewhere between three and six full-time equivalents. Not on anyone's budget as "PII vault maintenance" — but paid, every month, in engineering time.
The accidental vault has three properties that make it uniquely bad to own.
It's undifferentiated. No customer chooses a product because its internal key rotation is elegant. The work is mandatory and invisible — high downside, zero upside.
It's unbounded. Every new service, integration, and hire expands the surface. There's no version 1.0 after which it's done; there's only more of it.
And it's fragile in exactly the wrong place. A bug in a product feature loses a sale. A bug in the accidental vault — a replica with real data in staging, a log line with a passport number, a deletion job that missed a table — is a breach notification.
The industry solved a structurally identical problem once before. Nobody stores passwords and encrypts them better anymore; we stopped storing the passwords at all and store derived hashes instead. The threat model collapsed not because the walls got higher, but because the thing worth stealing stopped being there.
The same inversion applies to personal data more broadly: if operational systems hold references instead of the data itself, most of the accidental vault — the scattered encryption, the per-service masking, the multi-system deletion choreography — stops being necessary, because the systems no longer contain what all that machinery was protecting.
Whether that inversion is worth it depends on how big your accidental vault has quietly become. Which raises the only question that matters: if you added up every hour your team spent last quarter maintaining yours — would you be comfortable seeing the number?