What Makes Software HIPAA-Compliant? A Builder’s Guide

“HIPAA-compliant” is one of the most overused phrases in healthcare software. However, HIPAA compliance is not a certification, a badge, or a feature you turn on. It is a specific set of technical, administrative, and organizational requirements that a platform and the organization using it must meet continuously, and the details matter more than the label.

Specifically, this guide is for teams building healthcare apps, whether with no-code tools, AI builders, or custom code, who need a plain-English answer to what HIPAA actually requires of their software stack. It covers the technical safeguards the law specifies, the contractual requirements that apply to every vendor in the chain, and the one regulatory change builders need to know about for 2026.

Key takeaways

• HIPAA compliance is not a certification. There is no official government stamp. A vendor is compliant when they implement the required safeguards and will sign a Business Associate Agreement (BAA).
• The Security Rule defines three categories of safeguards: technical (encryption, access controls, audit logs), physical (facility and device security), and administrative (policies, training, risk analysis). Software addresses the technical layer. Your organization handles the rest.
• A signed BAA is non-negotiable. If a vendor stores, processes, or transmits PHI and will not sign a BAA, you cannot use that vendor for patient data, period.
• The proposed 2026 HIPAA Security Rule update would make encryption mandatory rather than addressable, require MFA for most access, and mandate annual penetration testing. It is not yet final, but building to the proposed standard is already the safer path.
• Knack Health is built to meet the technical safeguard layer: encryption at rest and in transit, role-based access controls, and a signed BAA on every HIPAA plan.

What “HIPAA-compliant software” actually means

First, something most vendors won’t say clearly: there is no official HIPAA certification. The U.S. Department of Health and Human Services does not certify software as HIPAA-compliant, and no third-party certification makes a platform compliant by itself.

In practice, when a vendor says their software is HIPAA-compliant, they mean two things. First, they have implemented the technical safeguards the Security Rule requires. Second, they are willing to sign a Business Associate Agreement, which makes them legally accountable for protecting the PHI they handle. Without both, however, the compliance claim is marketing language, not a legal position.

Importantly, compliance is not a one-time state. It is continuous. The risk analysis you complete this quarter needs to be revisited when your tech stack changes. Consequently, the BAA signed last year needs to be reviewed when a vendor updates its services. The training your team completed needs to happen again next year.

The two types of HIPAA software

There is an important distinction worth knowing:

HIPAA-compliant software is a platform that includes the necessary privacy and security safeguards to handle PHI. Examples include secure hosting services, patient portals, and no-code builders with HIPAA plans. This is what Knack Health is.

HIPAA compliance software is a different category entirely. These are tools like Sprinto, Vanta, or Drata that help organizations manage their compliance program: tracking policies, running risk assessments, managing BAAs, and documenting training. These are governance tools, not PHI-handling platforms.

Both matter, but they solve different problems. This guide focuses on the first category.

The three safeguard categories HIPAA requires

The Security Rule organizes its requirements into three categories. Software addresses one of them. Your organization is responsible for all three.

Technical safeguards

Specifically, these are the ones built into the platform. They include:

Encryption at rest and in transit

Every piece of PHI stored in the system must be encrypted. Every transmission of PHI between the application, the database, and the user must be encrypted using TLS 1.2 or higher. Knack Health provides encryption at rest and in transit on every HIPAA plan, built into the infrastructure rather than configured by the customer.

Access controls

The system must enforce who can access which data. Specifically, the minimum necessary standard requires that each user accesses only the PHI their role requires. In practice, effective access controls work at the field level, not just the record or page level, so a billing staff member cannot see clinical notes and a clinician cannot see unrelated financial data.

Authentication

Users must be authenticated before accessing PHI. In practice, this means at minimum a login requirement, and increasingly MFA as a near-universal expectation even before the proposed 2026 rule makes it more explicit.

Physical safeguards

Physical safeguards cover the facilities and devices where PHI is stored or accessed. For cloud-based software, the hosting provider handles most of the facility-level requirements. Your organization handles the device level: ensuring that laptops, phones, and workstations accessing PHI are secured, and that devices are properly wiped when retired or lost.

Administrative safeguards

Administrative safeguards are organizational, not technical. They include your written privacy and security policies, your workforce training program, your designated privacy officer, your risk analysis process, and your breach notification procedures. No software platform handles these for you. They are your organization’s responsibility regardless of how compliant the platform is.

The BAA requirement: what it means and what it covers

Specifically, a Business Associate Agreement is a legally binding contract between your organization (the covered entity) and any vendor that creates, receives, maintains, or transmits PHI on your behalf (the business associate). Under HIPAA, a BAA is not optional. Operating without one, however, even informally or temporarily, is itself a compliance violation.

A well-constructed BAA defines how the vendor must protect the data, how they handle and report a breach, what they are permitted to do with PHI, and what happens if they fall short. Regulators have consistently held that missing or unsigned BAAs are violations in their own right, not just procedural gaps.

Importantly, several things the BAA does not cover by default:

Third-party integrations. For instance, if your platform connects to a third-party tool (an email service, an analytics platform, a Zapier workflow) and PHI flows through that integration, the third-party needs its own BAA. Your platform’s BAA does not extend to tools that connect to it.

AI features. In 2026, this is consequently the most commonly missed gap. Many AI features and automation connectors are explicitly excluded from a platform’s BAA. The Airtable BAA, for example, explicitly excludes AI fields and agents. Any AI feature that processes PHI needs BAA coverage for the model provider, not just the application layer.

Free or standard plans. Furthermore, most platforms only include BAAs on paid or enterprise tiers. A free plan that lacks a BAA cannot legally handle PHI regardless of how secure the platform’s infrastructure is.

Knack Health includes a signed BAA with every HIPAA plan. You do not need to request it separately or negotiate it.

What the proposed 2026 HIPAA Security Rule update means for builders

In January 2025, HHS published a Notice of Proposed Rulemaking (NPRM) that would significantly raise the technical safeguard bar. As of August 2026, however, the rule is not yet final. OCR received approximately 4,700 public comments and has been reviewing them, with finalization targeted for 2026. Once a final rule publishes, covered entities and business associates have 240 days to comply.

The key proposed changes that affect software builders:

Encryption becomes mandatory. Currently, encryption is “addressable” under the Security Rule, meaning organizations can implement an equivalent alternative if encryption is unreasonable. The proposed rule would make encryption mandatory across all systems handling ePHI, with no addressable alternative.

MFA required for most access. Multi-factor authentication would become a baseline requirement for accessing systems that contain PHI, not just a recommended practice.

Annual penetration testing. Organizations would need to conduct penetration testing annually and vulnerability scanning every six months, with documented results.

Tighter incident response timelines. The proposed rule tightens the requirements around detecting, responding to, and documenting security incidents.

In other words, even though the rule is not final, building to the proposed standard is the safer approach. In fact, most platforms operating in healthcare are already moving in this direction because customers demand it. Choosing infrastructure that meets the proposed standard now avoids a compliance sprint later.

How to evaluate whether software is actually HIPAA-compliant

Specifically, when a vendor claims HIPAA compliance, here is what to verify rather than take on faith:

BAA availability. Does the vendor sign a BAA on your specific plan? Ask for the BAA template before signing any agreement. Confirm it covers your use case specifically.

Encryption specifics. Ask the vendor to confirm encryption at rest and in transit, and ask what standard they use. AES-256 at rest and TLS 1.2 or higher in transit are the current baselines.

Access control granularity. Can the platform enforce permissions at the field level? Role-based access at the page level is not sufficient for the minimum necessary standard in most healthcare workflows.

Audit log scope. What does the platform log? Who can access the logs? How long are they retained? Consequently, these are questions to ask the vendor directly.

Third-party integration coverage. If you use integrations, automation tools, or AI features, confirm separately that each one is covered by a BAA or is excluded from PHI flows.

SOC 2 Type II. In addition, a SOC 2 Type II report is not the same as HIPAA compliance, but it is a meaningful signal that a vendor has undergone independent security auditing. Knack Health maintains SOC 2 Type II compliance as part of its security posture.

How Knack Health meets the technical safeguard layer

Knack Health provides the technical infrastructure that the Security Rule’s technical safeguards require:

Encryption at rest and in transit, built into the platform architecture on every HIPAA plan. You do not configure this separately.

Role-based access controls at the field level, so each user role sees only the data their role requires. Configured without code and enforced across every view and form in the application.

Record change logs that capture who changed a record, when, and what values were updated. Built into the platform rather than requiring a separate logging configuration.

A signed BAA included on every HIPAA plan. No separate request or negotiation required.

SOC 2 Type II compliance with annual HIPAA attestations as part of Knack’s security review process.

However, what Knack Health does not handle for you: the administrative and physical safeguards. Your risk analysis, privacy officer designation, workforce training, breach notification procedures, and physical device security are your organization’s responsibility. The platform handles the technical layer. Your organization handles the rest.

If you are building a healthcare app with a no-code tool or an AI builder and need a compliant backend that passes the technical safeguard requirements above, Knack Health is built for that specific use case.