What 'HIPAA-Adjacent' Actually Means for a Custom-Built System

"HIPAA-compliant" gets used constantly in healthcare software conversations, often more loosely than the term actually allows. A vendor claiming compliance without a real audit behind it is a liability for the buyer, not a feature.

We haven't shipped a named healthcare case study yet, and we won't claim one we don't have. What we can speak to honestly is the technical pattern behind healthcare data security, which is bigger than any one country's regulation, and it's a core part of what we build for healthcare clients.

ISO/IEC 27799 is the international standard for information security management in health, built on top of ISO/IEC 27001 and adapted specifically for personal health information. It is technology-neutral and jurisdiction-neutral by design, meant to apply to any healthcare organization or custodian of health data, anywhere.

Strip away the country-specific language and the requirement is consistent everywhere it's regulated: confidentiality, integrity, and availability of health information, backed by real technical controls, not a policy document nobody enforces.

In the US specifically, this shows up as HIPAA. Reporting on the 2026 update cycle describes a shift toward a 'prove it' enforcement model, where formerly 'addressable' safeguards like encryption are now treated as mandatory, and regulators expect evidence of technical enforcement, not documentation of intent. We reviewed this via HIPAA-focused trade press rather than a primary HHS.gov bulletin, so treat the specific 2026 framing as directional, the underlying shift toward technical proof over paperwork is the part that matters.

We are not a HIPAA-certified vendor, we don't operate in the US, and we are not claiming to build to that specific regime. We're citing it because it's the most-discussed enforced example of a principle that holds everywhere: encryption and access control that only exist on paper are not security controls.

If you're building healthcare-adjacent software outside the US, the practical bar doesn't disappear just because HIPAA doesn't directly apply. Encrypted PHI at rest and in transit. Role-based access control, not a shared login. An audit trail that records who accessed what and when, tamper-evident by design. Any credible enterprise healthcare customer's due-diligence checklist asks for these regardless of jurisdiction.

Encryption for data at rest and in transit as a default, not an add-on. Role-based access control scoped to what a given user actually needs to see, not an all-or-nothing login. Audit logging built into how the system works, the same discipline behind the reconciliation audit trail we build for fintech clients, adapted here to health data access instead of financial transactions.

Don't claim a compliance certification you haven't earned. We won't say 'HIPAA-compliant' without a real third-party audit behind that claim, and any vendor who says it casually in a sales conversation is a red flag worth pressing on.

We haven't built for every regional healthcare compliance regime. If your project has a specific named requirement, GDPR health-data provisions, a national health data law, say so early in a scoping call so we can be upfront about fit.

Name the actual compliance requirement your project needs, don't default to "HIPAA" as shorthand for "secure." The real requirement might be a different regime entirely, or no formal certification, just genuinely sound engineering.

Build the security pattern in from the first version. Retrofitting encryption and audit logging onto a system not designed for it is a materially bigger job than including it from day one.

Ask any vendor for evidence, not a claim. A real audit trail, a documented access-control model, and a clear answer on what's encrypted and what isn't tell you more than a compliance badge on a landing page.