Most writing about HIPAA is procurement advice: which vendors sign a BAA, which cloud regions to use, which certification to buy. Useful, but it skips the part that actually determines whether a small team can hold health data safely — the architecture, which is cheap to get right at the start and close to impossible to retrofit.
We built LoveHurts, a platform for anonymously notifying partners about potential STI exposure. Anonymity was not a feature layered on top; it was the entire product proposition. If the system could leak who told whom, there was no product.
That constraint clarifies the architecture usefully, so it is a good case to reason from.
Decide what you are allowed to know
The first question is not how to encrypt data. It is what you are willing to hold at all.
Every identifying field you store is a field that has to be encrypted, access-controlled, audited, backed up safely, deleted on request and disclosed in a breach. Every field you do not store is none of those things.
This sounds obvious and is routinely skipped, because schemas get designed for analytics that nobody has committed to yet. A column added speculatively becomes a compliance obligation permanently.
For a notification platform, the discipline is severe: hold what is needed to deliver the message and nothing that would let anyone reconstruct the relationship afterwards.
Encrypt before the write, decrypt in memory only
The architecture we ran was zero-trust in a specific, checkable sense: no plaintext PII ever touches disk. Identifying data is encrypted before it is written and decrypted in memory only for the request that needs it.
The distinction from "encryption at rest" matters. Disk-level encryption protects against someone stealing the disk. It does nothing against an application-layer bug, a misconfigured backup, a support engineer with database access or an over-broad query — all of which see plaintext because the database decrypts transparently.
Field-level encryption means the database holds ciphertext. A leaked dump is ciphertext. An over-broad query returns ciphertext. The blast radius of the most likely failures shrinks to almost nothing.
The cost is real and worth stating: you lose the ability to search or index those fields directly, which forces decisions about deterministic encryption or blind indexes early. That is a genuine constraint, not a free win, and it is far cheaper to design around at the start than to introduce once queries depend on plaintext.
The leak is almost always the logs
If one thing in this piece is worth acting on, it is this.
Teams encrypt the database carefully, then:
- log full request payloads for debugging
- ship exceptions with request context to a third-party error tracker
- write verbose access logs including query parameters
- email themselves alerts containing user data
Each is standard practice. Each moves health data somewhere with none of the protections, often to a vendor that is now an unbudgeted subprocessor.
The rule that prevents it: identifying data is opaque to the logging layer by construction, not by convention. Not "developers remember not to log PHI" — a type or wrapper that cannot be serialised into a log line. Conventions fail under deadline; types do not.
Compliance is a property of the system, not the CMS
A detail from this build that generalises: the marketing site and CMS were configured so non-technical editors could publish freely, with privacy guardrails built into what those surfaces could touch.
The point is separation. Content editing should not be able to reach regulated data, which means the compliance boundary sits inside the architecture rather than around the whole company. Without that separation every content change becomes a compliance review, which is unsustainable and therefore gets ignored.
The uncomfortable part: UX is a compliance surface
For a platform built on anonymity, a confusing interface is a safety failure, not just a usability one. A user who cannot tell what will be revealed cannot give meaningful consent, and a user who misunderstands the flow may expose themselves in the one situation where exposure is the harm.
Designing for dignity — plain language, no judgment in the copy, no dark patterns pushing disclosure — is part of the compliance posture. It does not appear on any control checklist, which is precisely why it gets skipped.
What this costs a small team
Less than expected, on one condition: it is decided up front.
Field-level encryption, a logging layer that cannot see identifying data, a schema holding the minimum, and a compliance boundary that content editing cannot cross — those are architecture decisions, not purchases. Made at the start they cost design time. Retrofitted, each one touches everything, and the retrofit usually happens under the pressure of a deal that requires it by a date.
If you are about to start holding health data, the sequence that saves the most money is: decide what you refuse to store, make the logging layer blind by construction, and only then go shopping for tooling.
Common questions
- Does HIPAA compliance require expensive tooling?
- Not primarily. The bulk of it is architectural discipline — what you store, where it is decrypted, who can read it and what your logs contain. Tooling helps with attestation and monitoring, but it cannot fix a schema that stores PHI in plaintext.
- What does "no plaintext PII on disk" mean in practice?
- Identifying data is encrypted before it is written and only decrypted in memory for the request that needs it. Nothing persistent — database, backup, log or error report — holds a readable copy.
- What is the most commonly missed HIPAA leak?
- Logs and error reporting. Teams encrypt the database and then send a full request payload to a third-party error tracker, which is now an unbudgeted subprocessor holding health data.
- Compliance
- Security
- Architecture
