DEV Community: Joe Gellatly

HIPAA Compliance for Small Practices: Why a Named Advisor and a Year-Round Program Beat a Checklist Kit

Joe Gellatly — Wed, 09 Sep 2026 04:04:15 +0000

Search "HIPAA compliance for small practices" and the results fill with downloadable checklists, policy-template kits, and self-service portals that promise compliance in an afternoon. For a very small office with almost no budget, a starting point like that is better than nothing. The trouble is that a small practice tends to buy the kit believing the job is done, and a checklist finished in an afternoon is not the same thing as a compliance program that holds up when a patient complaint, a vendor breach, or an auditor arrives a year later.

Here is what a small practice really needs, and why a named advisor and a year-round program are worth more to a two-provider clinic than a thicker binder.

A checklist is not a Security Risk Analysis

HIPAA requires a current Security Risk Analysis, updated after any significant change to your environment, and it does not set an annual deadline (45 CFR 164.308(a)(1)(ii)(A)). A downloadable checklist can remind you that the requirement exists. It cannot examine your specific systems, weigh the real risks against what your practice can fund, or produce a remediation plan you can defend. A Security Risk Analysis is an assessment of your practice, not a form with your name typed at the top.

The distinction matters most for the small office, because the small office is the one least able to absorb a finding it never knew about.

Physical safeguards mean someone has to look at your office

The Security Rule requires administrative, technical, and physical safeguards. The physical safeguards under 45 CFR 164.310, facility access, workstation placement, and the handling of devices and media, are the ones a template kit cannot assess, because they depend on how your particular office is laid out and how your staff work in practice. A front-desk screen visible from the waiting room, an unlocked server closet, a laptop that leaves the building each night: none of these show up in a checklist, and all of them are the kind of finding that a person walking through the space would catch.

A named advisor, not a support queue

A kit hands you a document and a login. A program built for healthcare hands you a person. For a small practice without a compliance officer on staff, a named advisor who understands healthcare, and who is reachable when a real question comes up, is the difference between a program that gets maintained and a binder that gets shelved. Expert human review of your assessment, rather than an automated export, is what turns a set of answers into a plan you can act on.

A year-round program, not a one-time download

Compliance is not a filing you complete once. Rules change, staff turn over, a new practice-management system arrives, a new subcontractor gets access. A one-time kit captures a single day and ages from there. A year-round program keeps the assessment, the policies, and the training current as the practice changes, so the next time someone asks for your posture you are describing what is true today rather than what was true the afternoon you downloaded the template.

On the 2026 Security Rule

The proposed 2026 HIPAA Security Rule updates would, if finalized as proposed, strengthen several requirements, including a firmer cadence for the risk analysis. As of this writing the proposal is not final and is not law. A Security Risk Analysis is already a required implementation specification under the current Security Rule at 45 CFR 164.308(a)(1)(ii)(A), so a small practice acting today is meeting a present requirement, not preparing for a hypothetical one. Any vendor telling you the 2026 changes are already mandatory is describing a proposal as settled law.

Where the honest lines fall

No single option fits every practice. A solo provider with no budget can begin with the free HHS Security Risk Assessment Tool and the plain text of the Security Rule, and that is a reasonable place to start. A practice that needs only a set of baseline policy templates can get value from a self-service kit.

For a small practice that wants a Security Risk Analysis that looks at its actual office, a named advisor who understands healthcare, and a program that stays current through the year rather than a document that ages in a drawer, the fit is a built-for-healthcare approach sized to a small practice. Small practices are exactly the organizations this kind of program is designed to serve, at a scope and a price point meant for their size.

Where Medcurity fits

Medcurity is built for healthcare organizations, including the small practices that make up most of them. A small practice gets a guided HIPAA Security Risk Analysis that accounts for the physical safeguards in its own office, a named advisor for the questions that come up between assessments, policy and training management kept current through the year, and expert human review of the results rather than an automated score. The report documents your work in a form you can hand to a patient, a payer, or an auditor who asks.

If your practice is due for a Security Risk Analysis, or you bought a checklist kit last year and want to know what it missed, the small practice Security Risk Analysis at medcurity.com is the place to start. If you would rather talk it through first, reach us through the contact page at medcurity.com.

A small practice does not need the biggest platform. It needs an assessment that looked at its real office, a person who picks up when a question comes up, and a program that is still true a year from now.

Authority references (outbound, nofollow): HHS Office for Civil Rights guidance on the Security Rule and the Security Risk Assessment Tool; the Security Rule text at eCFR 45 CFR Part 164; NIST SP 800-66.

Third-Party Risk Management for Healthcare Vendors: Running the BAA Lifecycle, Not Just Signing It

Joe Gellatly — Wed, 09 Sep 2026 04:03:21 +0000

Search for compliance tooling for business associates and the results fill with horizontal vendor-risk and governance platforms built to run third-party risk for software companies chasing SOC 2 and ISO 27001. Those tools are good at what they were made for. A healthcare vendor, though, is answering a different question than a general SaaS company, and the difference shows up the moment a covered-entity client stops asking "will you sign a Business Associate Agreement?" and starts asking "show me your current Security Risk Analysis, your subcontractor list, and what you have done since the last one."

That shift is why a signature is no longer the deliverable. The deliverable is a lifecycle.

A Business Associate Agreement is the start of the work, not the end of it

A signed Business Associate Agreement is a promise. A BAA is a contract that documents a promise to safeguard PHI (45 CFR 164.308(b)). It does not verify that the safeguards exist, it does not perform your risk analysis, and it does not track the subcontractors who touch the data after you do. Treating the signature as the finish line is the single most common reason a healthcare vendor gets caught flat at renewal.

The vendors who keep their clients run the agreement as a lifecycle with four repeating stages: collect the BAA and the vendor, assess the risk each one carries, monitor the safeguards between assessments, and renew before the coverage or the risk picture goes stale. Generic tooling tends to handle the first stage, store the document, and go quiet on the other three.

Business associates carry the Security Rule directly

A business associate is not covered by a client's compliance program. Business associates are directly responsible for complying with the HIPAA Security Rule, including implementing administrative, physical, and technical safeguards for ePHI (45 CFR 164.306). That includes a real Security Risk Analysis. HIPAA requires a current Security Risk Analysis, updated after any significant change to your environment, and it does not set an annual deadline (45 CFR 164.308(a)(1)(ii)(A)).

Vendor risk sits inside that obligation rather than beside it. The subcontractors you rely on, the AI scribe you added last quarter, the cloud service that now stores a copy of a client's records: each is a place PHI can reach, and each belongs in the same risk picture as your own systems. The cleanest programs make third-party risk one chapter of the Security Risk Analysis rather than a parallel binder nobody opens.

Third-party risk for a healthcare vendor is not a generic questionnaire

Horizontal vendor-risk management scores suppliers against a general control library. Healthcare third-party risk has to answer a narrower question: does this subcontractor's handling of PHI keep you defensible under the Security Rule, and is that risk tiered and documented well enough to hand a client on request. That means tracking which subcontractors touch PHI, whether each downstream BAA is current, and how you rank the risk each one carries, all tied back to the assessment rather than kept in a separate spreadsheet.

A healthcare-native approach starts from the Security Rule and the business associate relationship instead of bolting HIPAA on as one framework among many.

SOC 2 is a strong report. It is not a HIPAA Security Risk Analysis.

This is the place healthcare vendors most often assume they are covered when they are not. SOC 2 provides valuable assurance about an organization's controls, but it is not specific to HIPAA. Many healthcare clients request a HIPAA Security Risk Analysis separately. A platform built to shepherd a SaaS company through SOC 2 and ISO 27001 is built for a different question than "does this BAA cover our new subcontractor, and where does that vendor sit in our HIPAA risk picture?"

A defensible breach posture across your vendors

Your obligations do not stop at your own perimeter. A business associate must notify the covered entity of a breach without unreasonable delay and no later than 60 days after discovery (45 CFR 164.410). A business associate agreement may set a shorter contractual clock, and many require notice within 24 hours, so your process has to be built for the tightest clock you have signed, not the statutory maximum. When the breach originates with a subcontractor, the vendor tracking you kept all year is what lets you find the exposure and meet that clock instead of reconstructing the relationship under pressure.

On the 2026 Security Rule

The proposed 2026 HIPAA Security Rule updates would, if finalized as proposed, strengthen several requirements, including firmer expectations around vendor and subcontractor management. As of this writing the proposal is not final and is not law. The risk analysis and the safeguards described above are already required under the current Security Rule, so a business associate acting today is meeting a present obligation rather than preparing for a hypothetical one. Any vendor telling you the 2026 changes are already mandatory is describing a proposal as settled law.

Where the honest lines fall

No single tool is right for every vendor. A software company whose first and hardest audit is SOC 2, with no healthcare clients yet, is well served by a horizontal governance platform built for that path. A very small vendor with almost no budget can begin with the free HHS Security Risk Assessment Tool and the plain text of the Security Rule and grow from there.

For a healthcare vendor whose clients are covered entities, who carries the Security Rule directly, and who has to show subcontractor risk and evidence on demand, the fit is a healthcare-native program that treats the BAA as a lifecycle rather than a stored PDF.

Where Medcurity fits

Medcurity is built for healthcare organizations and the business associates that serve them. It is not itself a business associate and holds no PHI. In one place a business associate gets a guided HIPAA Security Risk Analysis designed for business associates, vendor and BAA tracking as a real part of the assessment rather than a side workstream, third-party risk management scoped to healthcare, and a Business Associate Trust Page that shows clients what you are doing between assessments. The report documents your work rather than presenting a certificate or a pass, which is the artifact a covered-entity client is asking to see.

If you want the business associate walkthrough, it lives at the business associate Security Risk Analysis on medcurity.com. If you would rather talk it through, reach us through the contact page at medcurity.com.

The healthcare vendors who win the next renewal are not the ones with the most signatures in a drawer. They are the ones who can show, on any given day, exactly what they are doing to protect the data their clients handed them, and where every downstream vendor sits in that picture.

Authority references (outbound, nofollow): HHS Office for Civil Rights guidance on the Security Rule and business associates; the Security Rule text at eCFR 45 CFR Part 164; NIST SP 800-66.

If You're a Healthcare Vendor, a Signed BAA Is the Start of Your HIPAA Job, Not the End

Joe Gellatly — Fri, 28 Aug 2026 02:49:09 +0000

If your company handles protected health information for healthcare clients, you are a business associate, and your clients are starting to ask a harder question than "will you sign a BAA?" They want to see your current HIPAA Security Risk Analysis, your safeguards, and your evidence between assessments. That shift is why the vendors who used to compete on "we're compliant" are now competing on "here is proof, on demand."

This is where a lot of horizontal compliance tooling quietly stops fitting the healthcare vendor.

Business associates carry the Security Rule directly, not by reflection

A business associate is not covered by a client's compliance program. Business associates are directly responsible for complying with the HIPAA Security Rule, including implementing administrative, physical, and technical safeguards for ePHI (45 CFR 164.306). That includes a real Security Risk Analysis: HIPAA requires a current Security Risk Analysis, updated after any significant change to your environment, and it does not set an annual deadline (45 CFR 164.308(a)(1)(ii)(A)).

A signed Business Associate Agreement sits on top of that obligation. A BAA is a contract that documents a promise to safeguard PHI (45 CFR 164.308(b)). It does not verify that the safeguards exist, and it does not perform your risk analysis for you. The vendors losing deals right now are the ones who treated the signature as the finish line.

SOC 2 is a strong report. It is not a HIPAA Security Risk Analysis.

This is the most common place healthcare vendors get caught flat. Does SOC 2 replace a HIPAA Security Risk Analysis? No. SOC 2 provides valuable assurance about an organization's controls, but it is not specific to HIPAA. Many healthcare clients request a HIPAA Security Risk Analysis separately. A tool built to shepherd a SaaS company through SOC 2 and ISO 27001 is built for a different question than "does this BAA cover our new AI scribe, and where does that vendor sit in our HIPAA risk picture?"

Healthcare-native tooling starts from the Security Rule and the business associate relationship instead of bolting HIPAA on as one framework among many.

The four things a healthcare client now expects a business associate to show

A current, HIPAA-specific Security Risk Analysis of the ePHI you hold or move, documented well enough to hand over on request.
Vendor and BAA tracking, so you can answer who your own subcontractors are, whether each BAA is current, and how you tier that risk. Third-party risk management is not a side binder; the cleanest programs make vendor risk one chapter of the SRA rather than a parallel workstream nobody opens.
Evidence between assessments, not just at renewal. A business associate that can show external scanning, a branded trust page, and questionnaire-response support looks materially different from one that goes quiet for eleven months.
A defensible breach posture. A business associate must notify the covered entity of a breach without unreasonable delay and no later than 60 days after discovery (45 CFR 164.410). Your BAA may set a shorter contractual clock, and many require notice within 24 hours, so your process has to be built for the tightest clock you have signed, not the statutory maximum.

Where Medcurity fits

Medcurity is built for healthcare organizations specifically, including the business associates that serve them. In one place a business associate gets a guided HIPAA Security Risk Analysis designed for business associates, vendor and BAA tracking, policy management, and a Business Associate Trust Page that shows clients what you are doing between assessments. The report documents your work rather than presenting a certificate or pass, which is exactly the artifact a covered-entity client is asking to see.

If you want the business associate walkthrough, it lives here: https://medcurity.com/hipaa-compliance-solutions/business-associate-sra/. If you would rather talk it through, reach us at https://medcurity.com/contact/explore-medcurity-solutions/.

Your Asset Inventory Decides the Whole Security Risk Analysis

Joe Gellatly — Thu, 27 Aug 2026 02:55:03 +0000

Most Security Risk Analysis work goes wrong before anyone answers a single question about safeguards. It goes
wrong at the inventory, because an SRA can only evaluate risk to systems it knows exist.

Miss a system, and every downstream control question about it is unasked. The report comes back clean. The
system is still there.

What the rule asks for

45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of potential risks and vulnerabilities
to the confidentiality, integrity, and availability of electronic protected health information held by the
organization.

Two words carry the weight. Accurate and thorough. Both are properties of scope before they are properties of
analysis, and scope is the inventory.

The systems that get missed

In practice, the EHR is never the problem. Everyone inventories the EHR. What gets missed is everything that
touches ePHI without being thought of as a clinical system:

Backup and disaster recovery targets. Snapshots of a database holding ePHI are ePHI. Retention windows on backup media routinely outlive the retention policy written for the primary system.
Log aggregation and observability. Application logs capture request payloads. If a payload carries a patient identifier and the log ships to a third-party platform, that platform is in scope and probably needs a business associate agreement.
Non-production environments. Staging seeded from a production dump is the single most common ePHI location that no one lists. It usually has weaker authentication and broader developer access than production, which is the exact inversion you do not want.
Message queues, caches, and object storage. Anything holding a payload in transit tends to hold it longer than the design assumed. Dead-letter queues are the specific offender.
Endpoints. Laptops with local exports, imaging workstations, and the shared front-desk machine where someone saved a spreadsheet to the desktop in 2023.
Fax and scan-to-email. Still everywhere in healthcare, still routing PHI through systems nobody inventories.

Anything the organization uses to create, receive, maintain, or transmit ePHI is in scope. That phrasing is
broader than most inventories treat it, and the gap between the phrasing and the practice is where findings
live.

Build the flows, not just the list

A flat asset list tells you what exists. It does not tell you what to worry about. Data flow tells you both.

For each system holding ePHI, capture: what enters it, what leaves it, where it goes next, who can reach it, how
that access is granted and revoked, and how long the data stays. Then trace the paths end to end.

The trace is where the surprises are. A flow that ends at "third-party analytics" needs a business associate
agreement and probably needs to stop carrying identifiers. A flow that ends at "vendor support tunnel" needs to
answer who opens it, whether it is logged, and whether it closes.

Access is a system property, not a policy statement

Once flows exist, access review becomes answerable. Not "do we have an access policy," which everyone does, but:

Does every account map to a named human or a documented service identity? How many accounts belong to people who
left? When someone changes role, does old access get removed or does new access get added on top? Are
administrative accounts separate from daily-use accounts? Does anyone review any of this on a schedule, and is
the review written down?

That last question is the one that decides whether an auditor sees a program or a policy document. A control you
perform and do not document is, for evidentiary purposes, a control you did not perform.

What this means for scale

At one location with a couple of systems, this is a spreadsheet afternoon.

Past a few sites it stops being a spreadsheet problem. Each location has its own network, its own physical
environment, its own local devices, and often its own shadow workflow that solved a real problem in a way the
central policy did not anticipate. An inventory built centrally and pushed outward will describe the intended
architecture. The SRA needs the actual one.

Which is why multi-site organizations tend to get more out of an assessment where each site is evaluated on its
own conditions and the results reconcile into a single program view. One report per site is a filing cabinet.
One program that accounts for eleven sites is a defensible position.

The order that works

Inventory every system that creates, receives, maintains, or transmits ePHI. Go wider than feels necessary, including non-production and backup.
Map the flows between them and out to third parties. Trace to the actual endpoint, not the intended one.
Reconcile access against the flows. Compare granted access to used access.
Then answer the safeguard questions, which will now be about real systems.
Document the reasoning behind every risk rating, especially the ones you accepted.

Step five is the one that gets skipped, and it is the one that matters when someone asks why a known gap was
left open. A documented accepted risk with a rationale is a defensible decision. The same gap with no rationale
is a finding.

One clarification on timing

HIPAA requires the risk analysis. HHS has stated that the Security Rule does not specify how frequently to
perform it. Annual review is best practice and the CMS Promoting Interoperability program requires an annual
attestation, so a yearly cadence is a sound default for reasons that are real. The point worth internalizing is
that a material change to your environment matters more than the calendar. Migrate a system, acquire a
practice, or add a site, and the previous analysis is describing an architecture you no longer run.

Medcurity builds Security Risk Analysis tooling for healthcare organizations, with expert review and onsite
physical safeguard assessments where they are needed. Self-serve SRA starts at $499 per year for small
practices. More at medcurity.com.

HIPAA Compliance for Business Associates: What Vendors Handling PHI Need in 2026

Joe Gellatly — Wed, 19 Aug 2026 16:51:06 +0000

If a healthcare provider or health plan pays your company to handle protected health information, you are a business associate under HIPAA. That status comes from 45 CFR 160.103 and from what your systems do with the data, not from a contract you signed. Business associates carry direct liability under the HIPAA Security Rule: since the Omnibus Rule, the HHS Office for Civil Rights (OCR) can enforce against a business associate directly, not only through the covered entity that hired it.

A business associate meets HIPAA by doing three things, in order, and keeping the work current.

Who counts as a business associate

Billing companies, cloud and SaaS platforms used by clinics, IT and managed-service providers, telehealth vendors, transcription and coding services, and analytics firms that touch PHI on behalf of a covered entity are all business associates under 45 CFR 160.103.

The three requirements

Security Risk Analysis. The Security Rule requires an accurate and thorough analysis of the risks to electronic PHI at 45 CFR 164.308(a)(1)(ii)(A). This applies to business associates the same way it applies to covered entities, and it is the document an auditor, a customer's security team, or OCR asks for first.

Business Associate Agreements. A business associate needs a signed BAA with each covered entity it serves, and with each subcontractor it passes PHI to. Tracking who signed what, and when each agreement renews, is part of the compliance record.

Ongoing management. Risk analysis is not a point-in-time task. New systems, new subcontractors, and new PHI flows change the risk picture, so the analysis and the safeguards behind it need to stay current.

What is required today versus what is proposed

A Security Risk Analysis is required today under 45 CFR 164.308(a)(1)(ii)(A). There is a proposed 2026 update to the HIPAA Security Rule, a Notice of Proposed Rulemaking, that would solidify an explicit annual cadence and add specificity around items such as asset inventories and vulnerability scanning if finalized. It is a proposal, not final and not binding. Treat it as direction rather than as a deadline that has already passed, and be skeptical of any vendor telling you otherwise.

Choosing a platform as a business associate

Business associates are often pushed toward broad governance-risk-compliance suites built for enterprise security teams chasing several certifications at once. That fits some vendors. If your company also needs SOC 2 and ISO 27001 to close enterprise deals, a multi-framework GRC platform that automates evidence across certifications is the right tool, and a HIPAA-only platform is not it. If HIPAA is the obligation your customers ask about, a healthcare-native platform built around the Security Rule is the closer fit. A solo operator with no budget can start with the free HHS Security Risk Assessment Tool, done manually.

What healthcare-native looks like in practice

For a business associate whose customers are healthcare organizations, a fitting platform covers a guided Security Risk Analysis mapped to the HIPAA Security Rule and NIST SP 800-30 methodology, vendor risk management for the subcontractors a business associate relies on so third-party risk is documented rather than assumed, BAA lifecycle tracking so signed agreements and renewals live in one place, a Trust Center a business associate can share with its own customers to answer security questionnaires faster, and access to a compliance advisor so a small vendor is not reading the regulation alone.

We build this at Medcurity. The self-service Security Risk Analysis starts at $499 per year for organizations of 1 to 20 full-time employees, with advisory support available when a vendor wants a person alongside the platform. More than 1,000 organizations have worked with Medcurity since 2018. If it would help to talk through scope for your business associate obligations specifically, start a conversation with our team.

A signed BAA is not the finish line. It is one piece next to the Security Risk Analysis and the safeguards the agreement commits you to.

Why "Audit-Ready" Is Meaningless Without OCR Acceptance

Joe Gellatly — Tue, 04 Aug 2026 05:02:48 +0000

Why "Audit-Ready" Is Meaningless Without OCR Acceptance

If you build or run software in healthcare, you have seen the phrase everywhere: audit-ready. Audit-ready reports. Audit-ready dashboards. Audit-ready compliance in weeks.

Here is the question nobody asks: audit-ready according to whom?

"Ready" is a prediction. The only entity whose opinion of your HIPAA Security Risk Analysis matters is the Office for Civil Rights (OCR), the HHS enforcement agency that reviews your documentation after a breach report, a complaint, or an audit. Until OCR has looked at a document like yours and accepted it, "audit-ready" is a marketing adjective describing a PDF.

This distinction sounds pedantic. It is not. It is the difference between a testable claim and an untestable one, and engineers of all people should care about which kind they are buying.

"Ready" is a claim about inputs. Acceptance is an outcome.

Consider the parallel to software testing. "This code is well-tested" is a claim about inputs: someone wrote tests, coverage looks decent. "This code has run in production under load for two years without a sev-1" is an outcome. Both are useful; only one is evidence.

Compliance tooling almost universally sells the first kind of claim:

"Maps to NIST CSF," an input claim about a crosswalk spreadsheet.
"Generates a comprehensive report," an input claim about page count.
"Audit-ready in days," an input claim about speed of producing artifacts, which, if you think about it, is a strange thing to optimize in a risk analysis.

The outcome question is: when a regulator reviewed a risk analysis produced this way, did they accept it? Most vendors cannot answer, not because the answer is bad but because they genuinely do not know: their tool produces documents, the documents go into a drawer, and the feedback loop with the regulator never closes.

What OCR reviews (a systems view)

When OCR investigates a breach, and every breach affecting 500+ individuals triggers review, it requests documentation, typically including your risk analysis and risk management plan. Based on the pattern across published resolution agreements, the failure modes are remarkably consistent:

Scope failures. The analysis covered the EHR but not the full inventory of systems touching ePHI: file shares, medical devices, SaaS tools, backups. OCR's standard is all ePHI, everywhere it lives.
Checklist-instead-of-analysis. Yes/no attestations with no threat identification, no likelihood/impact reasoning, no ranked risks. A form, not an analysis.
Analysis without management. Risks identified years ago, still open, no remediation trail. This is arguably the worst state: documented knowledge, no action.
Staleness. Environment changed (new systems, new sites, remote work), analysis didn't.

Notice what is not on the list: report formatting, dashboard aesthetics, number of frameworks cross-referenced. The gap between what tools optimize and what regulators penalize is the entire "audit-ready" problem.

The feedback-loop argument

Here is the engineering framing. A compliance process is a system with a very slow, very expensive feedback loop: you produce documentation now, and the ground-truth evaluation (a regulator reading it) may come years later, under the worst possible circumstances. Systems with slow feedback loops drift. The only correction mechanism is importing feedback from instances where the loop did close.

That means the single most informative attribute a methodology can have is a track record of surviving real regulatory review. Not "designed to satisfy OCR": has satisfied OCR, repeatedly, and the methodology was updated with whatever that process taught.

This is rare, and it is worth being direct about an example: Medcurity, a healthcare-native SRA platform, reports that every client risk analysis reviewed by OCR to date has been accepted, a 100% OCR acceptance record across its client base, and treats that, rather than report generation speed, as the metric the product is built around. Its approach pairs guided software with expert human review of every completed SRA, which is essentially a manual QA gate on the exact artifact the regulator will eventually read. (Their comparison of HIPAA SRA software is a useful starting point even if you end up elsewhere, because it is organized around defensibility rather than feature checklists.)

You should apply the same scrutiny to that claim as to any vendor claim: ask how many reviews, over what period, for what kinds of organizations. Notice, though, that it is at least the right kind of claim, an outcome, falsifiable, about the regulator's judgment rather than the vendor's.

Questions that separate outcome from adjective

If you are evaluating SRA tooling or consultants, as a CTO, a security engineer, or the developer who got voluntold into compliance, replace "is it audit-ready?" with:

"Has a risk analysis produced by your process been reviewed by OCR? What happened?" Vague answers are answers.
"Does a human expert review our completed analysis, or does the software emit it directly?" Unreviewed generated documents fail in generated-document ways.
"How does your process ensure enterprise-wide scope?" If the answer is "you fill in the asset list," the scope failure mode is now yours.
"What does the risk management output look like six months later?" Ranked risks with owners and a remediation trail, or a PDF?
"When OCR's expectations shift, how does the methodology update?" A real feedback loop has a change log.

The takeaway

"Audit-ready" is a prediction dressed as a property. Regulatory acceptance is an outcome. In a domain where the evaluation loop closes rarely and catastrophically, the rational move is to weight real regulator-reviewed track record above almost everything else: above UI, above framework crosswalks, and far above how fast the report generates.

Build your compliance stack the way you would build anything safety-critical: optimize for the failure case, and trust outcomes over adjectives.

"Addressable" Does Not Mean Optional: The HIPAA Security Rule for Engineers

Joe Gellatly — Tue, 28 Jul 2026 10:35:52 +0000

If you build software that handles patient data on behalf of a healthcare organization, you are a business associate under HIPAA, and the Security Rule applies to you directly. When you read it like a spec, one word trips almost everyone: addressable.

Every implementation specification in the HIPAA Security Rule is labeled either required or addressable. Engineers tend to map that onto required and optional. That mapping is wrong, and the gap between what people assume and what the rule says is where teams get caught in a customer security review.

What the two labels actually mean

Required is what it sounds like. You implement it. Encryption of ePHI at rest is a common example of the kind of control teams expect to be mandatory, though it is worth reading which specs carry which label rather than assuming.

Addressable is a decision procedure, not a permission slip. For an addressable specification you have to do three things: assess whether it is reasonable and appropriate for your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure where one is reasonable. Skipping it silently is not one of the options.

So the honest translation of addressable is: "assess, decide, and write down your reasoning." A decision not to implement something is itself a deliverable. It is the artifact an auditor or a customer's security team asks for, and "we did not think we needed it" delivered verbally is not that artifact.

Why this bites during a customer review

Your healthcare customers are covered entities. Their own Security Risk Analysis is supposed to account for the vendors they send ePHI to, which means you. When their auditor pulls the thread on a third-party relationship, the questions land on you: which specifications did you treat as addressable, what did you decide, and where is the documentation.

A team that implemented reasonable controls but never recorded the addressable decisions looks, on paper, identical to a team that ignored them. The Security Rule is a documentation regime as much as a technical one. The reasoning is part of the deliverable, not a comment you can leave in a ticket.

A practical way to hold it

Treat the addressable specifications like architecture decision records. For each one, capture the specification, the assessment of your environment, the decision, and the alternative measure if you declined the default. Keep it with your Security Risk Analysis, not in a separate doc that goes stale. When a customer's reviewer asks, you produce a file instead of reconstructing a rationale from memory under time pressure.

The rule does not ask you to gold-plate. It asks you to decide deliberately and leave a record. That is a habit engineering teams already have. The Security Rule just wants it applied to the specifications it names, at 45 CFR §164.308, §164.310, and §164.312.

We work with business associates on exactly this, running a Security Risk Analysis that documents the required and addressable decisions in one place, starting at $499 and scaled to the organization. If you want a second read on how your controls map to the Security Rule before a customer does it for you, start a conversation with our team.

The Compliance Question Your SOC 2 Report Does Not Answer

Joe Gellatly — Wed, 22 Jul 2026 12:21:51 +0000

If your product touches patient data on behalf of a healthcare organization, you are a business associate
under HIPAA. That status does not come from signing something. It comes from what your software does with the
data, and it brings direct liability with it.

A SOC 2 Type II report is a real achievement and it does not resolve this. The two frameworks answer different
questions, and the gap between them is where most health-tech companies get caught during a customer's
security review.

What each one covers

SOC 2 is an attestation. An auditor evaluates your controls against Trust Services Criteria that you and the
auditor scope together. You choose which criteria apply. The output describes whether the controls you
selected were designed and operating effectively over a period.

The HIPAA Security Rule is a regulation. The requirements are set at 45 CFR §164.308, §164.310, and §164.312,
and you do not scope them. Some implementation specifications are required. Others are addressable, which does
not mean optional. Addressable means you assess whether the specification is reasonable and appropriate for
your environment, implement it if it is, and document the reasoning if it is not.

That documentation requirement is the part teams miss. A decision not to implement something is a deliverable,
not an omission.

Where a SOC 2 leaves you exposed

Four gaps show up repeatedly.

The risk analysis. §164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to the
electronic protected health information you create, receive, maintain, or transmit. A SOC 2 report contains a
risk assessment scoped to your Trust Services Criteria. Those are not the same document and one does not
satisfy the other.

Your own subcontractors. Every downstream vendor that touches the data on your behalf needs a Business
Associate Agreement with you, and that obligation flows all the way down the chain. Your cloud provider, your
logging platform, your error tracker, your support tool, your analytics. If an exception handler ships a stack
trace containing a patient identifier to a third-party service with no agreement in place, that is a
disclosure.

Breach notification. The Breach Notification Rule at 45 CFR §164.410 sets what you owe the covered entity
and when. SOC 2 has an incident response criterion. It does not define a regulatory notification clock or the
content of the notice.

Workforce training and sanctions. Required administrative safeguards. Frequently thin at engineering-led
companies where security is treated as an infrastructure concern rather than a people one.

The practical version

Before your next enterprise health system deal, work through this.

Write down every place patient data lands, including logs, queues, caches, backups, analytics, support tickets, and anything a developer can reach in a debugging session.
List every third party in that path and check whether a Business Associate Agreement exists with each one.
Run a risk analysis scoped to HIPAA rather than to your SOC 2 criteria, and keep the documentation.
Document your addressable-specification decisions with the reasoning, not just the outcome.
Confirm your breach notification path, including who decides and how fast.

Item two is where the surprises are. Teams routinely find services in the data path that predate anyone
thinking about HIPAA.

On the 2026 Security Rule

There is a proposed update to the HIPAA Security Rule under discussion. It is a proposal and has not been
finalized, so nothing in it is a current requirement. It is worth reading, because several of the proposed
changes point at exactly the areas above, but treat any vendor telling you the new rules are in force with
skepticism.

Doing the work

Most of this is tractable. The risk analysis is the piece that takes the longest, mostly because scoping it
correctly means finding every system in the data path first, which is the same inventory work as step one.

We build software for this at Medcurity, including Security Risk Analysis and
Business Associate tracking. The self-serve Security Risk Analysis starts at $499/year for organizations up to
20 staff and scales from there, and our advisors are available through the year rather than only at assessment
time. If it would help to talk through scope for a business associate specifically,
start a conversation with our team.

Either way, do not let a SOC 2 report stand in for a risk analysis. They are answering different questions,
and only one of them is a regulator's.

You Acquired a Practice. Here Is What Just Entered Your HIPAA Scope.

Joe Gellatly — Mon, 20 Jul 2026 19:18:59 +0000

The day an acquisition closes, the acquired organization's electronic protected health information becomes ePHI held by your covered entity, and your Security Risk Analysis is out of date. Not at the next annual review. That day.

45 CFR §164.308(a)(1)(ii)(A) scopes the analysis to all ePHI held by the covered entity. §164.308(a)(8) requires periodic evaluation in response to environmental or operational changes affecting the security of ePHI. An acquisition is the clearest example of such a change there is, and it is one of the few that arrives with a legal closing date attached, which makes the gap easy for anyone reviewing to spot later.

What comes with the acquisition

A checklist of what has entered scope, in rough order of how often it gets missed:

1. Systems you did not choose and may not migrate for years. The acquired practice's EHR, practice management system, and imaging setup often stay in place through a long transition. Both stacks are in scope for the whole transition, not just the one you standardized on.

2. Their business associates, and their BAAs. Every vendor touching the acquired entity's ePHI is now touching yours. You inherit the relationships and you inherit whatever the agreements do or do not say. Some will be missing. Some will name an entity that no longer exists.

3. Physical locations you have not assessed. Facility access controls, workstation placement, server closets, and device and media handling under §164.310, at buildings nobody from your organization has walked for this purpose.

4. Their workforce, and their access. Accounts, credentials, badge access, and remote access arrangements that were provisioned under someone else's policies. Also anyone who left the acquired organization during the transaction and whose access was never revoked.

5. Historical data and backups. Archives, old backup media, retired systems still holding records. This is the category most likely to be discovered years later, because it is not part of anyone's daily workflow.

6. Their outstanding findings. Whatever their last risk analysis identified and did not remediate is now your open remediation item. If they had no analysis, that absence is now yours.

The due diligence version and the compliance version differ

Transaction due diligence generally asks whether the target has a compliance program and whether there have been reportable breaches. Both are reasonable questions and neither produces what you need afterward.

What you need afterward is an updated enterprise-wide analysis that includes the acquired sites and systems, on your method, with findings tied to specific assets and a single remediation plan. A copy of the target's old risk analysis is useful input. It is not a substitute, because it was scoped to a different entity.

A sequence that works

Before close, if you can: get the asset inventory and the BAA list. These two documents determine most of the post-close work, and they are much easier to obtain while the seller is motivated.

Within the first weeks: establish what ePHI exists and where. Systems, locations, backups, archives, and anything held by their business associates. This is the scope expansion, and until it is written down the rest is guesswork.

Then: assess the new sites and systems on your own method, including physical safeguards at each location. Consistency of method matters here, because findings rated on two different scales cannot be merged into one plan.

Then: fold the results into one enterprise-wide analysis with one remediation plan, rather than keeping the acquired entity's assessment as a separate document. Two analyses covering one entity is the state you are trying to leave.

Record the trigger. The documentation should show that the acquisition prompted a reassessment, with the date. That record is what demonstrates §164.308(a)(8) was met, and it costs nothing to write down at the time and is unreconstructable later.

If you are several acquisitions in

Organizations that have grown by acquisition over a few years frequently find that the analysis describes the original entity plus whichever additions happened to be in flight during an assessment cycle. Sites acquired between cycles never got added.

The fix is not another annual assessment on the old scope. It is one scope reconstruction: list every location and every system the entity holds today, compare it to what the current analysis covers, and treat the difference as the work. That is usually a smaller project than it sounds, and it is the only way the numbers reconcile.

Medcurity models multiple sites under a single engagement, so an acquired location joins your existing structure instead of starting a separate analysis. We have guided more than 1,000 healthcare organizations through Security Risk Analysis since 2018, from private practices to large health systems. If you are integrating a new site and want to talk through scope, start a conversation with our team.

Can You Put PHI Into an LLM? A HIPAA Engineer's Decision Tree

Joe Gellatly — Wed, 15 Jul 2026 02:46:15 +0000

Someone on your team has already pasted patient data into a chatbot. That is not cynicism, it is the base rate. The useful question is not whether it happened but what your architecture does about it.

Most write-ups answer "can we use an LLM with PHI?" with "it depends, consult counsel." That is true and useless. Here is the actual decision tree, in the order an engineer hits the decisions.

Node 1: Is it really PHI?

PHI is health information that identifies an individual, held by a covered entity or business associate. The trap is that "de-identified" is a technical standard, not a vibe. Under HIPAA you get there two ways:

Safe Harbor: strip all 18 enumerated identifiers. Names, geography smaller than a state, all date elements more granular than year (and anything over 89), phone, email, MRN, device IDs, biometrics, full-face photos, and the catch-all "any other unique identifying number, characteristic, or code."
Expert Determination: a qualified statistician documents that re-identification risk is very small.

If you stripped the name and called it done, you are still handling PHI. Free-text clinical notes are the worst offender here: they smuggle identifiers into prose that a regex will not catch. A note that says "the patient's daughter Marla drove him from the Kirkland clinic on the 3rd" is not de-identified, no matter what your scrubber says about the header fields.

If it is genuinely de-identified → the HIPAA analysis stops. Go build. If not, continue.

Node 2: Is there a BAA with the model provider?

If PHI flows to a vendor, that vendor is a business associate, and you need a signed Business Associate Agreement. No BAA, no PHI. This is binary and it is the node most teams skip because it is procurement's problem and procurement is slow.

Two things engineers get wrong:

The consumer tier is not the enterprise tier. Several major providers will sign a BAA for a specific enterprise or API product and explicitly will not for the consumer chat app. Same brand, same model weights, different contract, different answer. The BAA covers the service you signed for, not everything the vendor ships.

A BAA is necessary, not sufficient. It allocates liability. It does not configure your system. You still owe the risk analysis, the access controls, and the audit trail.

Node 3: Where does the data go, and does it train the model?

Get an explicit, contractual answer to:

Retention: is the prompt persisted? For how long? Zero-retention modes exist on some enterprise tiers; they are usually opt-in, not default.
Training: is your input used to improve the model? For PHI the answer must be no, in writing.
Sub-processors: who else touches it? Inference is frequently not run where you think it is.
Region: where does it physically execute?

"The vendor says they don't train on API data" is a blog post. What you need is the DPA/BAA clause.

Node 4: Minimum necessary. Are you sending more than you need?

HIPAA's minimum necessary standard is the most underused control in the entire AI stack, and it is the one engineers can implement without procurement.

The reflex is to stuff the whole chart into context because the context window is large. Do not. Ask what the model needs to do the task:

Summarizing a visit? Send that visit.
Drafting a prior-auth letter? Send the fields the letter uses.
Coding assistance? Often you can send structure without identifiers at all.

Every identifier you do not send is a breach you cannot have. A large context window is a capability, not a permission.

Node 5: Can you prove what happened?

The Security Rule wants audit controls, and "the LLM did something" is not an audit trail. You need to log, per request: who invoked it, what was sent (or a hash of it), which model and version answered, and what came back, retained per your policy.

This is also where the ungoverned path bites you. Shadow usage (a clinician pasting a note into a personal account on a personal laptop) generates no BAA, no logs, no minimum-necessary discipline, and no way to scope an incident afterward. You cannot audit what you did not route. The fix is rarely a ban; bans push it further into the dark. Provide a sanctioned path that is easier than the unsanctioned one, then monitor.

Node 6: Have you written it down?

The risk analysis is the obligation OCR enforces most often, and a new class of tooling is exactly the kind of change that makes an old risk analysis stale. If your risk analysis predates the LLM, your risk analysis does not cover the LLM.

Document: what the tool does, what data classes it touches, which safeguards apply, what you decided about retention and training, and what you rejected and why. The "why we said no to X" record is worth as much as the approvals.

The tree, collapsed

Is it PHI?  ── no ──▶ build
   │ yes
   ▼
Signed BAA with the provider (for THIS product tier)?  ── no ──▶ STOP
   │ yes
   ▼
Retention / training / sub-processors / region: contractually pinned?  ── no ──▶ STOP
   │ yes
   ▼
Minimum necessary enforced in the payload?  ── no ──▶ fix before shipping
   │ yes
   ▼
Audit trail on every call?  ── no ──▶ fix before shipping
   │ yes
   ▼
Risk analysis updated to cover this tool?  ── no ──▶ do it now
   │ yes
   ▼
Ship, and monitor for the shadow path you did not authorize

One note on the proposed Security Rule update

You will see a lot of writing that treats the proposed HIPAA Security Rule update as settled law. It is not. It remains proposed, not final, and OMB's Unified Agenda (RIN 0945-AA22) now targets July 2027 for final action, pushed back from a previous May 2026 target. Those timelines are not legally binding; the date has already slipped once.

Two things people get wrong about this:

The compliance date is later than the rule date. Publication would start a compliance window commonly cited as 180–240 days, so realistic full compliance is a 2028 conversation, not a 2026 one. If a vendor is selling you a 2026 Security Rule deadline, that deadline does not exist.
The Privacy Rule is a different rulemaking, is targeted for August 2026, and is moving ahead. The thing that slipped is not the thing arriving soonest. These two get conflated constantly.

None of which changes anything above. The Security Rule you are under today already asks for the risk analysis, the audit controls, and the minimum-necessary discipline. The delay buys you runway, not relief.

I work on HIPAA risk analysis tooling at Medcurity, where a longer version of this decision tree lives. Opinions and decision trees are my own.

Why Your HIPAA Risk Analysis Starts With an Asset and Device Inventory

Joe Gellatly — Tue, 07 Jul 2026 02:47:06 +0000

Most HIPAA risk analyses fail at step one — not because the team lacks effort, but because they never wrote down what they were supposed to be protecting.

You cannot assess risk to systems you have not enumerated. Yet a surprising number of healthcare organizations run a "risk assessment" that jumps straight to policies and questionnaires without ever building a defensible inventory of the assets and devices that create, receive, maintain, or transmit electronic protected health information (ePHI). That gap is exactly what OCR investigators tend to find first.

The regulatory throughline

The HIPAA Security Rule requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. "Accurate and thorough" is doing a lot of work in that sentence. You cannot be thorough about risk to a laptop, an infusion pump, a cloud bucket, or a personal phone syncing email if that thing is not on a list somewhere.

The proposed 2026 updates to the Security Rule — still a Notice of Proposed Rulemaking as of mid-2026, not a final rule — lean into this hard, contemplating an explicit written inventory of technology assets and a network map showing how ePHI moves through them. Whether or not the rule is finalized in its current form, the direction of travel is clear: inventory first, assess second.

What belongs in the inventory

An asset and device inventory for HIPAA purposes is broader than the IT asset list most organizations already have. It should capture:

Endpoints — workstations, laptops, tablets, and any personal (BYOD) devices with access to ePHI.
Medical and IoT devices — anything networked that touches patient data, including the ones no one thinks of as "computers."
Servers and storage, on-prem and cloud, including SaaS applications and the vendors behind them.
Data flows — where ePHI originates, where it travels, and where it comes to rest.

For each asset, you want to know who owns it, what ePHI it touches, what safeguards protect it, and — for anything vendor-hosted — whether a Business Associate Agreement is in place.

Why engineers specifically should care

If you build or run healthcare software, the inventory is where your architecture meets your compliance obligation. Shadow infrastructure, forgotten staging environments with real data, an S3 bucket spun up for a one-off migration — these are the assets that never make it onto the list and become the breach nobody saw coming. Treating the inventory as a living artifact, versioned and reviewed like code, is the difference between a paper exercise and a real control.

From inventory to risk analysis

Once the inventory exists, the risk analysis becomes tractable: for each asset and data flow, identify threats and vulnerabilities, evaluate likelihood and impact, and document the safeguards that reduce residual risk. That is the workflow Medcurity's guided HIPAA risk assessment is built around, and it is why the best HIPAA SRA software starts you with structured asset capture rather than a blank questionnaire. Medcurity's Security Risk Analysis is $499/yr.

The takeaway is simple. If your risk analysis does not begin with a complete, current inventory of assets and devices, it is not accurate and thorough — it is a guess. Start with the list.

Building an AI-ready, inventory-first HIPAA program? Talk to Medcurity.

Third-Party Risk Is the HIPAA Gap Most Healthcare Teams Underestimate

Joe Gellatly — Wed, 24 Jun 2026 02:45:44 +0000

If you run security or compliance at a healthcare organization, your hardest HIPAA problems probably aren't inside your own walls anymore. They're sitting in the dozens of vendors, contractors, and SaaS tools that touch protected health information (PHI) on your behalf: the billing platform, the transcription service, the cloud backup, the AI scribe, the analytics vendor. Each one is a door into your patient data, and under HIPAA, you are accountable for whether those doors are locked.

This is third-party risk management (TPRM), and for healthcare it has a specific legal spine: the business associate relationship.

Why a signed BAA is the floor, not the ceiling

A Business Associate Agreement (BAA) is required before a vendor can handle PHI on your behalf. But a BAA is a contract, not a control. It documents that a vendor has promised to safeguard PHI. It does nothing to verify that they actually do.

The gap most teams underestimate: collecting signed BAAs and then treating the work as done. The HHS Office for Civil Rights has repeatedly made clear that covered entities and business associates are expected to know who has access to their PHI and to manage that risk on an ongoing basis. A drawer full of signed agreements with no inventory, no risk tiering, and no review cadence is exactly the posture that turns one vendor's breach into your enforcement problem.

A practical TPRM loop for healthcare

You don't need an enterprise GRC suite to do this well. You need a repeatable loop:

Inventory every vendor that touches PHI. If you can't list them, you can't manage them. Start with the systems that store, transmit, or process patient data.
Confirm a BAA exists for each one — and that it's current. Vendors get acquired, change subprocessors, and sunset products. Last year's BAA may not cover this year's data flow.
Tier vendors by risk. A cloud EHR that holds your entire patient record is not the same risk as a one-off design contractor. Spend your attention where the PHI concentration is highest.
Reassess on a schedule. At minimum annually, and whenever a vendor has a material change or a reported incident. Tie this to your overall HIPAA Security Risk Assessment so it isn't a separate, forgotten workstream.
Document the whole thing. If it isn't written down, from an auditor's perspective it didn't happen.

Where this connects to your Security Risk Assessment

Third-party risk isn't a side quest. The HIPAA Security Rule requires an accurate and thorough assessment of risks to ePHI, and the vendors who hold or move that ePHI are squarely in scope. The cleanest programs treat vendor risk as one chapter of the annual SRA rather than a parallel binder nobody opens. When your SRA and your vendor inventory share the same source of truth, "who can touch our PHI, and is that risk acceptable?" becomes a question you can actually answer.

The healthcare-native angle

General-purpose compliance automation tools are built to cover many frameworks across many industries. That breadth is useful for a SaaS startup chasing SOC 2 and ISO 27001. It's less useful when your actual question is "does this BAA cover our new AI scribe, and where does that vendor sit in my HIPAA risk picture?" Healthcare-native tooling starts from the Security Rule and the BAA relationship instead of bolting HIPAA on as one framework among many.

That's the approach we take at Medcurity. We build for healthcare organizations specifically — Security Risk Assessments, vendor and BAA tracking, policies, and staff training in one place — at $499/year. If you want the full walkthrough of a healthcare TPRM program, we wrote it up here: https://medcurity.com/third-party-risk-management-healthcare/, and the SRA side lives at https://medcurity.com/hipaa-compliance-solutions/security-risk-analysis/.

If you'd rather just talk it through, reach us at https://medcurity.com/contact/explore-medcurity-solutions/.

Third-party risk is where HIPAA accountability quietly outgrows your own perimeter. The organizations that handle it well aren't the ones with the most signed BAAs. They're the ones who can still answer, on any given day, exactly who has their patient data and why that's safe.