Do You Actually Need HIPAA?

You need HIPAA compliance if you create, receive, store, or transmit protected health information on behalf of a US covered entity or another business associate, and you do not need it just because your product touches health data in general. A lot of digital health founders buy far more compliance program than the law requires, and a lot of others skip it entirely when a signed Business Associate Agreement is sitting in their inbox waiting on a security review.

What HIPAA Actually Regulates

HIPAA is a US federal law. It governs protected health information, PHI, when that data is handled by a covered entity (hospitals, clinics, insurers, health plans) or a business associate, which is any vendor that processes PHI on a covered entity's behalf. If your Toronto or Waterloo-built SaaS platform stores appointment data, diagnosis codes, claims data, or clinical notes for a US health system or payer, you are almost certainly a business associate under the law, regardless of where your servers or your team sit.

The trigger is not "we're in health tech." It is the specific data flow. A scheduling tool that only stores names and appointment times for a dental office might touch PHI. A wellness app that tracks step counts for consumers with no clinical relationship usually does not. The line matters because it determines whether you need a real HIPAA program or whether you are solving the wrong problem.

Who Genuinely Needs HIPAA Compliance

• SaaS vendors selling directly to US hospitals, clinics, or health systems who will sign a Business Associate Agreement (BAA) as part of the deal.
• Digital health platforms handling clinical or claims data, including EHR-adjacent tools, care coordination platforms, and remote patient monitoring products.
• Vendors selling to US health insurers or payers, where the BAA is often a hard procurement gate before contract signature.
• Sub-processors of business associates, meaning if your customer is already a business associate and you process PHI they collected, the obligation flows down to you.

If any of these describe your business, HIPAA readiness is not optional. A US health system's procurement and legal teams will ask for your Security Rule safeguards, your breach notification process, and a signed BAA before a contract closes. Skipping this step does not make the requirement go away, it just moves the conversation to a later, more painful stage of the sales cycle.

Who Is Over-Buying HIPAA Compliance

We see this constantly with Canadian founders building health-adjacent tools who assume HIPAA is a universal health tech requirement. It is not. If your customers are Canadian hospitals or clinics, your governing framework is provincial health information legislation and PIPEDA, not HIPAA. If you sell to consumers directly with no covered entity relationship, HIPAA likely does not apply to you at all, even if your product deals with sensitive personal information.

The bigger over-buying mistake is companies that do need HIPAA jumping straight to HITRUST certification because a prospect's security team mentioned it. HITRUST is a heavyweight, expensive certification that many enterprise health buyers will accept as proof of HIPAA compliance, but it is rarely the actual gate. Most US health tech buyers just need evidence of a functioning Security Rule program and a signed BAA. Building a full HITRUST program before you have product-market fit in the US market is spending compliance budget you could put toward the sale itself.

HIPAA Readiness vs. Full HITRUST Certification

This is the distinction most vendors get wrong. HIPAA itself has no official certification body, there is no "HIPAA certified" badge issued by the government. What buyers actually want is evidence: documented administrative, physical, and technical safeguards under the Security Rule, a risk assessment, breach notification procedures, and a BAA you can sign without your lawyer flagging gaps. That is HIPAA readiness, and it is achievable for a lean digital health startup in a matter of weeks, not the six to twelve months a full HITRUST CSF certification typically takes.

HITRUST makes sense once you are selling to large health systems or payers with mature vendor risk programs that specifically require it, or once your deal volume justifies the cost. Before that point, a properly built HIPAA readiness program covers the vast majority of buyer requests and lets you sign BAAs with confidence. Our HIPAA compliance for digital health service is built around this reality: get your Security Rule program, risk assessment, and BAA-ready documentation in place without paying for certification overhead your current sales stage doesn't need.

Why Canadian Digital Health Companies Should Run HIPAA Alongside SOC 2

Nearly every Canadian SaaS company selling into US health tech is also being asked for SOC 2, because US buyers use it as the default trust signal for any vendor handling their data, health-related or not. The efficient move is running HIPAA readiness and SOC 2 as a single program rather than two separate ones. Both frameworks overlap heavily on access controls, encryption, incident response, and vendor risk management, so building them together avoids duplicating evidence collection and audit prep. We work with founders across Canada's tech hubs, Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, who are building for the US health market while still operating under PIPEDA and, where applicable, Quebec's Law 25. That dual context matters: your compliance program needs to satisfy US buyer expectations without ignoring the Canadian privacy obligations you're already subject to at home. See our broader compliance advisory services for how we structure combined SOC 2 and HIPAA engagements for Canadian companies selling south of the border.

How to Tell Which Category You're In

Ask three questions before committing budget to a HIPAA program:

• Does your product store or process data for a US covered entity, or for a vendor that is itself a business associate?
• Has a prospect or customer asked you to sign a BAA, or referenced HIPAA in a security questionnaire?
• Is the data in question protected health information, meaning it's tied to an identifiable individual's health status, treatment, or payment for care, not just general wellness or demographic data?

If you answered yes to the first two and the data genuinely qualifies as PHI, you need a real program, and you need it before your next enterprise deal stalls in security review. If you answered no across the board, save the budget and revisit the question when your go-to-market shifts toward the US health system.

Get an Honest Read on Your HIPAA Exposure

Most digital health founders don't need a guess, they need someone who has scoped these programs before to look at their actual customer contracts and data flows and tell them plainly whether HIPAA applies, and if so, how much program they actually need to close the deal in front of them. That's the conversation worth having before you sign a HITRUST proposal or, worse, before a BAA request stalls your pipeline. Contact traztech for a straight read on where you stand.

What a Business Associate Agreement Actually Commits You To

Founders treat the BAA as a signature formality and then discover, six months later, that it is the most operationally demanding contract in the company. Read the clauses before you sign. A standard BAA obliges you to use PHI only for the purposes the covered entity permits, to apply the Security Rule safeguards directly (business associates have been directly liable since the HITECH-driven Omnibus Rule of 2013), to report security incidents and breaches to the covered entity, to flow the same terms down to every subcontractor that touches the data, to make PHI available for access and amendment requests, and to return or destroy PHI at termination.

Two of those clauses cause most of the pain. The subcontractor flow-down means your infrastructure providers and any vendor in the data path need their own BAAs with you. AWS, Google Cloud, and Azure all offer one, but signing it does not cover every service in the catalogue; each provider publishes a list of HIPAA-eligible services, and using something outside that list to process PHI voids the arrangement for that data flow. The same applies to observability tools, support desks, email providers, and any AI API you call. If PHI is in a prompt, the model provider is a subcontractor.

The other trap is the return-or-destroy clause. Most SaaS platforms cannot actually destroy a customer's data at termination, because it is entangled in backups, log archives, analytics warehouses, and support ticket attachments. The BAA usually allows you to retain data where return or destruction is infeasible, provided you extend protections and limit further use, but you have to know that carve-out exists and reflect it in the contract and in your retention documentation. Signing a BAA that promises complete destruction in thirty days when your backup retention is ninety is a breach of contract on day one.

Required Versus Addressable Safeguards, and Why the Distinction Trips People

The Security Rule splits implementation specifications into required and addressable. Addressable does not mean optional. It means you assess whether the specification is reasonable and appropriate for your environment, and if you decide it is not, you document why and implement an equivalent alternative measure. Encryption at rest is the classic example. It is addressable, not required, which is why some vendors claim they do not need it. In practice, no health system security reviewer in the United States accepts an unencrypted database in 2026, and the encryption safe harbor in the Breach Notification Rule means properly encrypted data that goes missing is generally not a reportable breach at all. That single fact is worth more than any policy document you will write.

The specifications that actually get tested in vendor reviews are audit controls, access management with unique user identification, automatic logoff, integrity controls, transmission security, and the workforce sanction policy. Auditors and reviewers ask for the same evidence over and over: a current risk analysis, an access review record showing who was removed and when, a sample of audit logs demonstrating that record-level access to PHI is attributable to a named user, evidence that your workforce completed security training, and a tested incident response plan.

The Risk Analysis Is the Artifact Everyone Asks For

If there is one deliverable worth doing properly, it is the Security Rule risk analysis under 164.308(a)(1)(ii)(A). It is the most commonly cited deficiency in HHS Office for Civil Rights enforcement actions, and it is the document a covered entity's privacy officer will ask to see when your questionnaire answers look thin. A defensible risk analysis enumerates every system and location where PHI is created, received, maintained, or transmitted, identifies threats and vulnerabilities against each, rates likelihood and impact, and records the risk management decisions that follow. A generic template with your company name at the top does not survive a competent reviewer, because the first question is always which systems were in scope, and a template cannot answer that.

The related artifact is your data flow map. Most digital health companies cannot produce one on request, and building it usually surfaces something uncomfortable: PHI in a Slack channel, PHI in a spreadsheet a customer success manager uses for onboarding, PHI in a staging environment refreshed from production. Those findings are the real output of a readiness engagement. The policy binder is the easy part.

Breach Notification Mechanics You Should Know Before You Need Them

As a business associate you notify the covered entity, not individuals and not the regulator, unless your BAA delegates that duty to you. The outer statutory deadline is sixty days from discovery, and discovery means the first day the incident was known or reasonably should have been known by anyone in your workforce. Many BAAs shorten that to something far tighter, commonly twenty-four to seventy-two hours for initial notice, and negotiating that clause when the contract is drafted is much cheaper than discovering it during an incident.

An impermissible use or disclosure of unsecured PHI is presumed to be a breach unless you can demonstrate low probability of compromise through a four-factor assessment: the nature and extent of the PHI involved, who the unauthorized recipient was, whether the PHI was actually acquired or viewed, and the extent to which risk has been mitigated. Write that assessment down at the time. Reconstructing it a year later for a regulator or a plaintiff's counsel is a bad position to be in. Breaches affecting 500 or more individuals in a single state or jurisdiction go to HHS and to media within sixty days, and they appear publicly on the enforcement portal your future prospects can read.

De-identification Is Narrower Than Your Product Team Thinks

Product and data science teams routinely assume that stripping names makes a dataset free of HIPAA obligations. There are exactly two lawful routes. Safe Harbor requires removal of all eighteen specified identifiers, which includes all elements of dates other than year, geographic subdivisions smaller than a state, ages over 89, device identifiers, IP addresses, and any other unique identifying number or code. Full dates of service are an identifier, and almost every clinical analytics use case wants them. The alternative is expert determination, where a qualified statistician certifies that the re-identification risk is very small and documents the methodology. That is a real engagement with a real report, and it is the route most companies training models on clinical data should be taking. Limited data sets under a data use agreement are a third path that permits dates and city-level geography for research, public health, and health care operations, but they remain PHI and remain regulated.

What Drives the Cost of a HIPAA Program

The variables that move the number are the count of distinct environments holding PHI, whether you have a single production tenant model or per-customer deployments, how many subprocessors are in the data path, whether you already have centralized identity and logging, and whether the covered entity's security review is a questionnaire or a full assessment with a live evidence walkthrough. A single-tenant AWS deployment with SSO, centralized logging, and eight vendors is a straightforward engagement. A platform with three clouds, a legacy on-premise install base at two hospital customers, and forty vendors is not, and no fixed price should be quoted before someone has looked. Our published SKU pricing gives you the floor and the shape of the work; the scoping call sets the rest.

When You Should Not Buy This From Us

If no prospect has raised a BAA and you are selling to consumers or to Canadian custodians, do not run a HIPAA program. Spend the money on the readiness work later, when a real US health system deal exists, and read our PHIPA guide instead, because Ontario law is what actually binds you. If your entire PHI footprint is one integration and one database, and you have a competent infrastructure lead with time available, you can build the risk analysis, policy set, and access review cadence yourself using the HHS Security Risk Assessment tool and the NIST 800-66 guidance. It will take longer and it will be rougher, but it will pass most vendor reviews and it costs nothing but your team's hours.

If a customer contract explicitly names HITRUST r2 certification as a delivery condition, we are the wrong first call. Go to a HITRUST authorized external assessor directly, because only they can validate and submit, and we would be adding a layer between you and the firm doing the work. We are worth hiring when the review is stalled, when the BAA has clauses you cannot operationally meet, when PHI has spread into systems nobody mapped, or when HIPAA needs to run alongside SOC 2 without doing the evidence work twice.