How to Get HIPAA: A Step-by-Step Guide

Getting HIPAA compliant means implementing the administrative, physical, and technical safeguards the HIPAA Security Rule requires, then documenting them well enough to hold up under a covered entity's vendor risk review. There is no HIPAA "certification" issued by the government, so the real goal is a defensible compliance posture, typically built over 8 to 14 weeks, that satisfies the Business Associate Agreements (BAAs) US healthcare customers will demand before they sign.

For Canadian digital health companies selling into the US market, this catches founders off guard. You assumed there would be an exam, a badge, a certificate to put on the website. Instead there is a body of evidence: policies, risk assessments, access controls, and a signed BAA, all of which a hospital system's procurement team or a health plan's security office will pick apart line by line. Here is how to build that evidence set without over-engineering it.

Step 1: Confirm You Actually Need HIPAA (and What Kind)

Before spending a dollar, nail down your role under HIPAA. Most digital health startups fall into one of two buckets:

• Business Associate (BA): you handle Protected Health Information (PHI) on behalf of a covered entity (a hospital, clinic, insurer, or another BA). This is the common case for SaaS vendors, EHR integrations, and remote monitoring platforms.
• Covered Entity: you are a healthcare provider or health plan yourself, which is rarer for a startup but happens with telehealth and direct-to-consumer clinical services.

If you never touch, store, or transmit PHI, you may not need HIPAA at all, though your customer's legal team will still want that determination in writing. This step alone saves companies weeks of unnecessary work, and it is where a partner who has scoped this before earns their fee immediately.

Step 2: Run a HIPAA Risk Assessment

The Security Rule's Risk Analysis requirement, 45 CFR 164.308(a)(1)(ii)(A), is the foundation everything else sits on. It is also the single most-requested artifact in vendor security reviews. A proper risk assessment inventories:

• Every system, database, and third-party service that stores or processes PHI
• Threats and vulnerabilities against each asset (unencrypted backups, shared admin credentials, unpatched servers)
• The likelihood and impact of each risk, with a remediation plan and owner

Skip the generic checklist template. Auditors and enterprise security teams can tell within a page whether a risk assessment reflects your actual infrastructure or was copied from a boilerplate. Expect this step to take one to two weeks for a typical SaaS stack on AWS, Azure, or GCP.

Step 3: Build the Required Policies and Procedures

HIPAA does not prescribe a specific framework, but it does require documented policies covering access management, incident response, breach notification, workforce training, device and media controls, and business continuity. Most digital health companies need 15 to 20 policies at minimum. The trap here is writing policies nobody follows, an examiner or customer will ask for evidence, not just the document, so build policies your team can realistically operate day to day.

This is also where it pays to think ahead to SOC 2. Many of the same controls, access reviews, change management, vendor management, satisfy both frameworks, and running HIPAA readiness alongside a SOC 2 engagement avoids duplicating the same evidence collection twice. We cover this overlap in detail on our HIPAA compliance for digital health page, which is worth reviewing before you scope the work.

Step 4: Implement Technical Safeguards

This is the engineering-heavy phase. At minimum you need:

• Encryption for PHI at rest and in transit (AES-256 and TLS 1.2+ are the practical defaults)
• Access controls with unique user IDs, role-based permissions, and automatic session timeouts
• Audit logging that captures who accessed PHI, when, and what they did with it
• Multi-factor authentication on any system touching PHI, including admin consoles and cloud infrastructure
• Backup and disaster recovery procedures with tested restoration

Most modern cloud-native health tech companies already have a good chunk of this in place. The work is usually closing gaps, tightening logging, and documenting configurations rather than rebuilding infrastructure from zero. Budget two to four weeks depending on how much of your stack is already hardened.

Step 5: Execute Business Associate Agreements

Every vendor that touches PHI on your behalf, your cloud host, your email provider, your analytics tool, needs a signed BAA. And every covered entity or upstream BA that sends you PHI will require one from you before go-live. Build a BAA tracking log early. Sales cycles stall for weeks when a customer's legal team sends a BAA and nobody on the vendor side knows who owns getting it signed.

Step 6: Train Your Workforce

HIPAA requires documented security awareness training for anyone with access to PHI, delivered at onboarding and at least annually after. For a small team this can be a half-day session covering phishing, password hygiene, incident reporting, and acceptable use, but it has to be tracked with completion records. Customers will ask for training logs during due diligence.

Step 7: Decide Between a Readiness Assessment and Full HITRUST Certification

This is the decision point where most Canadian founders overspend. HITRUST CSF certification is a rigorous, expensive, multi-month undertaking that some large health systems require, but it is overkill for an early-stage company trying to close its first few US healthcare deals. A properly documented HIPAA readiness assessment, backed by a risk analysis, policy set, and technical safeguards, satisfies the vast majority of enterprise vendor security reviews and BAAs. Save HITRUST for the point where a specific deal genuinely requires it, not as a default starting posture.

Realistic Timelines

For a digital health company with a reasonably modern cloud stack:

• Weeks 1 to 2: scoping and risk assessment
• Weeks 3 to 6: policy development and technical remediation
• Weeks 7 to 10: BAA execution, training rollout, evidence collection
• Weeks 11 to 14: internal review, gap closure, readiness sign-off

Companies that already have SOC 2 controls in place, or that run SOC 2 and HIPAA readiness in parallel, often move faster because access management, logging, and vendor management evidence carries over between the two.

Where a Compliance Partner Actually Helps

The parts of this process that eat the most founder time, translating generic policy templates into something specific to your product, scoping the risk assessment correctly, and knowing which controls double up with SOC 2, are exactly where an experienced partner shortens the timeline. traztech works with Canadian digital health and healthtech companies selling into the US, building HIPAA readiness that stands up to enterprise procurement without the cost or timeline of a full HITRUST engagement. We serve teams in Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, and we build compliance programs that account for Canadian obligations too, including PIPEDA and Quebec's Law 25, alongside the US requirements your customers are asking about. If your roadmap includes broader security work, our compliance solutions page outlines how HIPAA readiness fits alongside SOC 2 and other frameworks.

Get Your HIPAA Readiness Roadmap

If you are fielding a security questionnaire from a US health system or preparing to sign your first BAA, get in front of it now rather than during a stalled deal. Contact traztech to scope a HIPAA readiness engagement built around your actual stack, your actual sales timeline, and the deals you are trying to close.

Required and Addressable Do Not Mean Mandatory and Optional

The Security Rule splits its implementation specifications into two kinds, and this is the single most misread thing in HIPAA. Required specifications must be implemented. Addressable specifications, which include encryption at rest, encryption in transit, and automatic logoff among others, give you a choice: implement the specification, implement an equivalent alternative measure, or document why neither is reasonable and appropriate for your environment. What you may not do is skip it silently. An addressable specification you ignored without a written analysis is a finding, and it is a finding that reads badly, because it shows the risk analysis was never connected to the decisions.

In practice, for a cloud-native product handling PHI, there is almost never a defensible argument against encryption, so the analysis is short and the answer is to implement. Where the flexibility genuinely helps is on things like automatic logoff intervals on clinical workstations you do not control, or media reuse controls for physical devices you do not own. Write the reasoning down at the time. Reconstructing it eighteen months later, in front of a customer's security office, is a bad afternoon.

The Privacy Rule Reaches You Through the Contract

Business associates are directly liable for the Security Rule and the Breach Notification Rule, and for a defined subset of the Privacy Rule, principally the minimum necessary standard and the limits on uses and disclosures. The rest of the Privacy Rule reaches you through the BAA itself, because the agreement obliges you to support the covered entity's obligations. That is where founders get surprised. Your customer has to give patients access to their records, account for disclosures, and honor amendment requests, and if their data sits in your system, the BAA will push those duties onto you as a contractual matter.

So before you sign, ask whether your product can actually do these things. Can you produce, on request, every record associated with one individual, including from backups and logs? Can you amend a record and keep the prior version? Can you produce an accounting of who accessed a given patient's data over a period? If the answer to any of those is no, you have signed up to a product commitment, not a policy commitment, and engineering needs to hear about it before legal signs.

What Actually Gets Negotiated in a BAA

Most first-time vendors sign whatever the health system sends. A handful of clauses are worth pushing back on, and pushing back is normal rather than a red flag.

The breach notification window. The rule allows a business associate up to sixty days from discovery to notify the covered entity. Health systems routinely draft five days, or twenty-four hours, and sometimes "immediately". A short window is survivable if it is triggered by confirmed breach rather than by any suspected security incident, and unworkable if it is not, because your monitoring will generate suspected incidents most weeks.

Subcontractor flow-down. You must have BAAs with every subcontractor that handles PHI on your behalf. Some agreements go further and require prior written approval for each one, which means every future infrastructure change needs a customer signature. Negotiate for notice with a right to object instead.

Indemnity and liability caps. Breach-related indemnities are often carved out of the general liability cap. For an early-stage company, an uncapped indemnity on a contract worth a modest annual figure is a genuine existential exposure, and it is one your insurer will want to know about.

Return or destruction on termination. The rule expects PHI to be returned or destroyed at the end of the relationship where feasible. Decide now what feasible means for your backups and your archives, and write it into the agreement rather than discovering it during an offboarding.

Audit rights. A right for the customer to audit you directly can consume more effort than any framework audit. It is usually negotiable down to an annual questionnaire plus your existing report.

Breach Notification, and Why the Clock Is Worse Than It Looks

An impermissible use or disclosure of unsecured PHI is presumed to be a breach unless you can demonstrate a low probability of compromise through a documented four-factor risk assessment, covering the nature and extent of the PHI, who received or accessed it, whether it was actually acquired or viewed, and the extent to which the risk has been mitigated. That assessment is the artifact that decides whether you are notifying anyone. Do it in a template you prepared in advance, because you will not write a good one during the event.

Timing: as a business associate you notify the covered entity without unreasonable delay and no later than sixty days from discovery, and discovery means the first day the incident was known or should reasonably have been known to anyone in your organization. That "should have known" clause is why unmonitored alert queues are a compliance problem and not just a security one. Covered entities then carry their own obligations to individuals, to HHS, and, for incidents affecting 500 or more residents of a state, to prominent media outlets, with the larger incidents reported to HHS within the same sixty days rather than in the annual batch.

One thing that materially changes this picture: encryption to the standard HHS recognizes moves data out of the "unsecured PHI" definition, which means a lost laptop with a properly encrypted disk generally is not a reportable breach. That is the highest-leverage control on this list, and it is cheap.

Shrink the Scope Before You Spend on It

The cheapest compliance work is the work you designed out. Two moves matter. The first is segregating PHI into a defined part of your architecture rather than letting it spread through logs, analytics pipelines, support tooling, and the data warehouse. Every system that touches PHI expands your risk analysis, your access reviews, your BAA list, and your incident scope. Most breaches we see in this sector involve PHI somewhere nobody intended it to be, usually application logs or a support ticket attachment.

The second is de-identification, where your use case allows it. HIPAA gives two routes: Safe Harbor, which requires removing eighteen specified categories of identifier and having no actual knowledge that the remainder could identify someone, and Expert Determination, where a qualified statistician documents that the re-identification risk is very small. Properly de-identified data is no longer PHI, which takes it out of scope entirely. This is the analysis that saves companies real money on analytics and machine learning workloads, and it is worth doing before you build the pipeline rather than after.

HIPAA Is an Annual Obligation, Not a Project

The risk analysis is not a one-time deliverable. It has to be reviewed and updated as your environment changes, which for a growing product means at least annually and in practice whenever you add a major system or a new data flow. Alongside it: training records renewed each year, access reviews on a stated cadence, policies re-approved with version history, BAAs tracked against renewal and against every new subprocessor, and evidence that your incident procedure has been exercised rather than only written. A readiness assessment that is two years stale is worse than none, because a customer will ask for the date and the date will answer for you.

If you are also carrying SOC 2, run the two calendars together. The access reviews, vendor reviews, training, and incident exercise satisfy both, and maintaining them once is the whole argument for an ongoing compliance retainer rather than repeating a readiness project every year.

When You Should Not Pay Us, or Anyone, for This

Some companies asking about HIPAA readiness should not buy it yet. If you have no US healthcare customer and no BAA in front of you, and your product is not yet handling PHI, the right spend is on the controls every framework assumes anyway: single sign-on, MFA, encryption, removal of standing production access, real logging with retention, and a tested restore. Those close most of what a readiness engagement would otherwise write up, and they are not wasted if the healthcare plan changes.

If you handle Canadian health data only, HIPAA is not your law, and buying it because it is the famous acronym is a genuine waste. Ontario's PHIPA and the applicable provincial and federal privacy regimes are what apply, and the answers differ in ways that matter, particularly around consent and the custodian relationship. Our digital health page covers both sides, and if you are unsure which set you fall under, that determination is a short conversation rather than an engagement.

And if a single customer sent a BAA and a questionnaire, start by answering them honestly, including the gaps, with dates against the remediation. A surprising share of health system reviews pass on an honest posture with a credible plan. Buying a full program before anyone has told you what they need is how founders end up with a binder and a stalled deal at the same time. If you want to know which of these situations you are actually in, talk to us and we will tell you when the answer is to do nothing yet.