HIPAA-Compliant Software Architecture: What Healthtech Startups Get Wrong

You passed your BAA review. Your legal team signed off. Your engineers said the system is secure.

And then a hospital network sent you a 90-question security questionnaire — and you realized that “secure” and “HIPAA-compliant” are not the same thing.

This happens more often than most healthtech founders admit. Not because they were careless. Because HIPAA compliance looks like a legal milestone until the moment it becomes an engineering problem. By then, you are usually mid-deal, mid-fundraise, or mid-hiring sprint — and the timing could not be worse.

This article is for founders and CEOs who have already built something. You have a product, early traction, and possibly a round behind you. You are not starting from scratch. You are asking a harder question: Is what we built actually compliant — or do we just think it is?

You Signed a BAA. That Does Not Mean Your Code Is Compliant

A Business Associate Agreement (BAA) is a contract. It defines who is responsible for protecting patient data. It does not change how your database is structured, how your logs are written, or what your third-party integrations receive.

Most early-stage healthtech teams treat the BAA as the finish line. It is actually the starting line.

HIPAA has two layers that matter for engineers. The Privacy Rule defines what protected health information (PHI) is and who can access it. The Security Rule defines how systems must protect that information — technically, physically, and administratively. The Security Rule is where most architectures fail quietly.

When Carbon Health — a US-based healthcare company operating virtual and in-person clinics — worked with Impressit’s DevOps engineers as part of a custom healthcare software engagement, one of the first priorities was security hardening at the infrastructure level. That meant enforcing least privilege permissions across services, introducing app-specific and role-specific database permissions, and replacing VPN-based access with a more secure, auditable solution for private resources. None of those things were covered by a signed agreement. All of them had to be built.

Mistake #1: Your PHI Does Not Have a Clear Boundary

Ask your engineering team: where exactly does PHI live in your system?

If the answer takes more than 30 seconds, you have a problem.

PHI spreads. It starts in one table, gets referenced in another, gets pulled into a report, gets passed to an analytics event. In two years of shipping features, most early-stage teams have never mapped exactly where patient data flows — because that was never a sprint task.

The consequences are practical. Your dev and staging environments may contain real patient data. Your crash reporting tool may be receiving user identifiers that can be linked to health records. Your logs — the ones every engineer reads freely — may contain names, dates of birth, or diagnosis codes.

A data classification exercise is not glamorous work. But it is the foundation of everything that follows. You cannot protect what you cannot locate.

Mistake #2: Access Control Was Designed for Your Team, Not for an Audit

Early teams build access control around convenience. The engineer who needs to debug something gets database access. The product manager who wants to pull a report gets read access to production. It makes sense at the time. It does not hold up under scrutiny.

HIPAA’s Minimum Necessary standard requires that access to PHI is limited to what each person or system needs to do their specific job. Not “roughly what they need.” Specifically what they need — and nothing else.

There are two practical requirements here. First, role-based access control (RBAC) with documented roles: who can access what, and why. Second, audit logs for every interaction with PHI — not just writes, but reads. If a hospital system asks you to prove that a specific record was accessed only by authorized users over the past 12 months, you need to produce that evidence from your system, not reconstruct it from memory.

One scenario that ends deals: a compliance review reveals that your engineering team has had unrestricted read access to production PHI since launch. There is no malicious intent. There is also no remediation that makes that acceptable to an enterprise buyer. The answer is to redesign access before you are in that conversation.

Mistake #3: Your Infrastructure Was Never Built to Be Auditable

HIPAA does not just require that you protect data. It requires that you can prove you protected it.

That is a different engineering requirement. And most early architectures were not designed with proof in mind.

The gaps tend to cluster in four areas:

• Audit trail. Every access to PHI — read, write, delete — must be logged in a tamper-evident, centralized system. If your logs can be modified by the same engineers who generated them, they do not satisfy the requirement.
• Encryption. PHI must be encrypted at rest and in transit. Many teams implement this partially — the database is encrypted, but backups are not. Or data in transit is protected, but internal service-to-service calls are not. Partial encryption is not encryption under audit.
• Backup and disaster recovery. Most startups have backups. Few have documented, tested recovery procedures. HIPAA requires both. If your recovery plan exists only in someone’s memory, it does not exist.
• Vulnerability management. Security scanning needs to be part of your CI/CD pipeline, not a quarterly manual task. Unpatched vulnerabilities in a production system handling PHI are a direct compliance risk.

None of this requires rebuilding your architecture from scratch. It requires treating auditability as a feature — one that gets scoped, built, and maintained like any other.

Mistake #4: Your Third-Party Integrations Are Breaking Your Compliance Perimeter

This is the most common gap that healthtech founders do not see coming.

You are using Segment for analytics. Sentry for error tracking. Intercom for support. Mixpanel for product metrics. Each of them was integrated by an engineer who was focused on the task — not on whether that tool should be receiving PHI.

Here is the risk: if any of those tools receives data that can be linked to an individual’s health information — an account ID, an appointment timestamp, a condition code in a URL parameter — they are handling PHI. And if they have not signed a BAA with you, you are out of compliance. Not theoretically. Practically and legally.

A real example of how this surfaces: a healthtech startup prepares for a Series B due diligence process. Their compliance review finds that their analytics platform has been receiving user identifiers alongside behavioral events for 18 months. The platform has no BAA. The team has to pause the process, conduct a risk assessment, notify their legal team, and — depending on the findings — potentially notify HHS. A three-week delay becomes a three-month one.

The fix is a data classification matrix: for each third-party integration, document what data it receives and whether that data constitutes PHI under any interpretation. If it does — either get a BAA signed or strip the PHI before it leaves your system.

Mistake #5: Compliance Was Treated as a One-Time Project, Not a Process

Even teams that did the work at Seed or Series A often find themselves exposed by Series B.

Why? Because the product grew. New features were added. New integrations were plugged in. Engineers turned over. And the compliance posture that was accurate on the day it was documented is no longer accurate today.

HIPAA’s Administrative Safeguards require ongoing risk management — not a one-time risk assessment. That means a scheduled review process, a designated privacy and security officer (even in a small company), and a documented procedure for evaluating new features and integrations before they touch PHI.

This is also where the cost of delay becomes real. Teams that build these processes in year one spend a few sprints getting it right. Teams that build them in year three spend several months untangling what accumulated in the gap — while enterprise deals wait.

What “Compliance-Ready” Actually Looks Like

This is not an exhaustive checklist. It is a directional test you can run against your current architecture:

• PHI is mapped: you know exactly which fields, tables, and services contain or transmit it
• Access to PHI is role-based, with documented roles and least-privilege enforcement
• All PHI access — reads included — is logged in a centralized, tamper-evident audit trail
• Encryption at rest and in transit is fully implemented and documented, including backups and internal service calls
• Dev and staging environments use synthetic or anonymized data only
• Every third-party tool that touches PHI has a signed BAA on file
• Disaster recovery procedures are documented and tested
• A process exists for evaluating new features and integrations for PHI exposure before launch
• A named person is responsible for ongoing compliance

If more than two of these are missing or unclear — that is the scope of the work ahead.

The Cost of Waiting Is Not a Fine. It Is a Delayed Deal.

HHS enforcement actions make headlines. But for most early-stage healthtech companies, the real cost of a compliance gap is not a penalty. It is a paused enterprise pilot, a failed security questionnaire, or a due diligence process that takes three times longer than it should.

Enterprise health systems, payers, and large physician groups have compliance teams. Those teams ask detailed questions. They request evidence, not assurances. A startup that built its product on a compliant foundation can move through that process quickly. A startup that built fast and assumed compliance catches up during a conversation it cannot afford to lose.

The founders who resolve this before Series A do not spend time on it during Series A. That is the actual return on the investment.

A Note on SOC 2

If you are targeting enterprise buyers, HIPAA compliance and SOC 2 Type II certification are increasingly evaluated together. They are different frameworks — HIPAA is regulatory, SOC 2 is a voluntary audit standard — but they overlap significantly in the controls they require. Teams that build HIPAA-compliant architecture tend to cover a large portion of their SOC 2 surface area in the same effort. It is worth discussing with your team before you scope the work.

Conclusion

HIPAA compliance is not a legal milestone. It is an architectural property — something that is either built into your system or is not. Most healthtech startups discover the difference at the worst possible time: when a real enterprise buyer is on the other side of the table.

The good news is that the gaps are almost always fixable. The question is whether you fix them on your schedule or on someone else’s.

Is your current architecture ready for the compliance review that enterprise sales will eventually require?

---

Impressit is a software development partner that builds and scales custom healthcare software solutions. The team has hands-on experience with compliance-layer architecture, DevOps hardening, and security engineering for healthtech products — including work with Carbon Health on infrastructure security and access control.