Overview
I worked on a secure healthcare platform that handled highly sensitive personal data under strict privacy and compliance requirements. On a product like this, data protection can’t be something you add near the end — it has to shape the architecture from the first decision onward.
Challenge
Database-level encryption alone isn’t enough. It protects data at rest, but it still leaves plaintext exposed to anything with database access — application bugs, over-broad queries, internal tooling. For a platform holding sensitive healthcare information, that residual exposure was unacceptable. We needed multiple categories of personal data protected at a layer above the database, without losing the ability to actually use the data.
Constraints
A regulated healthcare context set the bar: strict privacy and compliance requirements applied to every category of personal data the platform touched, and data access had to follow the principle of least privilege throughout. Whatever the design gained in protection, the product still had to be able to look records up.
Architecture
The core decision was to encrypt sensitive data at the application layer rather than relying solely on the database — defense in depth beyond the database boundary. Envelope encryption separated the encrypted data from the encryption keys: more key-management moving parts, but a data/key separation worth having for the security posture.
Security then propagated outward. It stopped being a module and became a design driver across the backend: API contracts, the data model, validation flows, and logging (no sensitive data in logs) were all shaped by it.
Trade-offs
Application-level PII encryption over database-only encryption
A secure healthcare platform handled highly sensitive personal data under strict privacy and compliance requirements. Database-level encryption alone leaves plaintext exposed to anything with database access.
Encrypt multiple categories of PII at the application layer, and use envelope encryption to separate the encrypted data from the encryption keys. Data access followed the principle of least privilege.
- Defense in depth beyond the database boundary
- Key/data separation and a stronger key-management posture via envelope encryption
- Compliance and auditability posture appropriate to healthcare PII
- Added implementation complexity
- Encrypted fields cannot be queried by normal equality — deterministic hashing was needed for secure lookups
- Security requirements propagated into API design, data modeling, validation, and logging
Security must be part of the architecture from the start — it cannot be bolted on at the end.
The hard consequence of encrypting at the application layer is that querying encrypted fields stops being free — you can’t look records up by value anymore. We used deterministic hashing: hashing the sensitive value so equal inputs produce the same hash, which allows secure equality lookups without ever decrypting or exposing plaintext. The honest cost is that deterministic hashing leaks equality — identical values produce identical hashes — which we accepted where lookups were required.
Implementation
I participated in implementing and maintaining these security mechanisms as part of the backend and full-stack engineering effort. In practice that meant working within the patterns the architecture demanded: field-level encryption decisions, hash-based lookup paths that stay indexable, validation flows that respect the encrypted boundary, and logging that never touches plaintext.
Lessons
The lasting shift for me was treating security as an architectural requirement, decided up front — not a feature added at the end. Retrofitting privacy into a mature system is a crisis; designing for it from day one is tractable. It also reframed “done”: a feature isn’t done when it works — it’s done when it works and the data it touches is protected by default.
What I’d improve
I’d go deeper on the deterministic-vs-randomized encryption trade-off for searchable fields — deterministic hashing enables equality lookups but leaks equality — and on stronger patterns for querying encrypted data without that leak.