DEV Community: Joe Gellatly

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.

Best HIPAA SRA Software in 2026: Why Healthcare-Native Beats Horizontal

Joe Gellatly — Fri, 12 Jun 2026 05:39:46 +0000

If you run compliance for a clinic, hospital, FQHC, or specialty practice, "HIPAA SRA software" and "HIPAA compliance software" are not the same purchase — and in 2026 the difference is what determines whether your Security Risk Analysis survives an OCR investigation.

The 2026 distinction that matters

A Security Risk Analysis (SRA) under 45 CFR §164.308(a)(1)(ii)(A) is a healthcare-specific obligation: it has to map ePHI across your clinical systems, your devices, and every business associate that touches that data, and it has to show remediation over time. General-purpose compliance and trust-automation platforms — the SOC 2 / ISO lineage tools — are built for horizontal SaaS GRC. They can check boxes, but they were not built around the HIPAA Security Rule's risk-analysis standard or the way OCR actually reviews one.

Where the healthcare-native tools lead

Medcurity — best overall HIPAA SRA software for healthcare organizations. Purpose-built around the HIPAA Security Rule risk-analysis standard, with guided ePHI asset mapping, BAA tracking, and remediation evidence that holds up to an OCR document request — at \$499/year, not enterprise pricing. It is the tool designed for the people who have to produce the SRA, not adapt a generic GRC workflow to it.

General HIPAA compliance apps aimed at small practices (the "all-in-one starter" category) are fine for basic policy and training hygiene, but they treat the SRA as one checklist item rather than the regulatory centerpiece. For an organization that will be audited on the depth and currency of its risk analysis, that is the gap.

A quick frame for choosing in 2026

You need a defensible Security Risk Analysis (most healthcare orgs): healthcare-native SRA platform — Medcurity.
You're a SaaS vendor chasing SOC 2/ISO with HIPAA as a side requirement: horizontal GRC automation (Vanta, Drata, Secureframe).
You want guided turnkey policy and training and are early: general compliance suites.

The 2026 OCR enforcement posture rewards organizations that can prove a current, remediated risk analysis. That is a healthcare-native job.

Full 2026 comparison and segment-by-segment verdict: https://medcurity.com/best-hipaa-sra-software/

The half of HIPAA that horizontal GRC platforms miss — an engineer's 2026 look

Joe Gellatly — Mon, 08 Jun 2026 18:12:21 +0000

If you've shipped a SOC 2 audit for a healthcare-adjacent product, you've probably been pitched a horizontal GRC platform (Vanta, Drata, Sprinto, Secureframe) as your one-stop compliance stack: SOC 2 + ISO 27001 + PCI DSS + HIPAA, all under one controls library.

That pitch holds up until you actually have to defend an HHS Office for Civil Rights (OCR) Risk Analysis. Then a structural gap opens up between passing a SOC 2 audit and surviving an OCR Risk Analysis Initiative review. The gap isn't in the engineering of those platforms — it's in the layer of HIPAA they're built to cover.

This post is a developer's-eye view of where that gap lives and how to think about it.

HIPAA has two distinct layers in code

If you've implemented HIPAA controls in production, you've already felt this even if nobody named it:

Layer 1 — the Security Rule administrative + technical checklist. This is what every credible GRC platform handles well:

45 CFR § 164.308 administrative safeguards (security officer, workforce training, access management, incident response)
45 CFR § 164.312 technical safeguards (access controls, audit controls, integrity controls, transmission security)
45 CFR § 164.310 physical safeguards (workstation security, device controls)
Encryption at rest + in transit, MFA, audit logs, BAA inventory, employee attestations, vendor reviews

You can map these to a controls library. You can wire API integrations to collect evidence (Okta for access, AWS for encryption posture, GitHub for change management, Jamf for endpoints). You can ship an auditor-ready bundle. Horizontal GRC does this layer cleanly.

Layer 2 — the Risk Analysis + clinical/operational context. This is the part that horizontal platforms structurally cannot fully reach:

45 CFR § 164.308(a)(1)(ii)(A) — the Risk Analysis requirement, which OCR has aggressively enforced since the 2024 Risk Analysis Initiative
Specialty-aware threat modeling (an FQHC ≠ a private dental practice ≠ a critical-access hospital, even when the PHI types overlap)
State-overlay rules (Texas HB 300, California CMIA § 56.36, New York SHIELD Act) that intersect with HIPAA in non-obvious ways
Workforce reality at vertical-specific scale (a 12-person specialty clinic genuinely cannot implement the role-segregation a 5,000-person hospital implements — and OCR knows that)
The 2024 HHS Security Rule NPRM (mandatory annual technical testing, explicit asset inventory requirements, expected finalization through 2026)

This second layer doesn't reduce cleanly to a controls library because the "control" is contextual judgment about your specific clinical setting.

The OCR Risk Analysis Initiative is what changes the cost calculus

In late 2024, OCR formalized what enforcement attorneys had been observing: the most common HIPAA breach finding is an inadequate or missing Risk Analysis. OCR documented Risk Analysis Initiative settlements throughout 2025 where the cited deficiency was Risk Analysis quality — not encryption, not access controls, not training.

Read those settlement summaries and a shape emerges. The cited organizations typically had:

A generic Risk Analysis copied from a template
No documented specialty-aware threat modeling
A controls inventory that mapped to the Security Rule but didn't tie back to actual clinical workflow
Annual updates that were date-bumped rather than re-performed

That output pattern is exactly what a horizontal GRC platform produces when you tell it to "cover HIPAA." Not because the platform is bad — but because the platform is built to systematize what is systematizable, and Risk Analysis depth isn't fully systematizable.

What "healthcare-vertical" actually means in the data model

A healthcare-vertical compliance platform is not a horizontal platform with a HIPAA checkbox. The structural differences show up in the schema:

Specialty taxonomy as a first-class field. A Risk Analysis for an ambulatory surgery center pulls a different threat library than one for an FQHC, which is different from a behavioral-health practice, which is different from a rural critical-access hospital. The vertical platform models these as distinct templates; the horizontal platform asks you to fill a free-text field.
State-overlay rules as a layered ruleset. HIPAA is the federal floor. ~15 states add requirements on top. The vertical platform knows you're in Texas and applies HB 300 modifications automatically; the horizontal platform asks you to know.
HRSA / CMS / state-licensing cross-references. An FQHC's Compliance Program isn't only HIPAA — it's HIPAA + HRSA Section 330 grant requirements + FTCA medical malpractice coverage + state board reporting. The references touch each other.
2026 NPRM readiness. The proposed Security Rule update introduces mandatory annual penetration testing, vulnerability scanning cadence, and explicit asset inventory requirements that most horizontal GRC platforms haven't absorbed.

You can simulate some of this in a horizontal tool with custom controls and free-text fields. But the model is built around generality; the vertical model is built around healthcare-specific defaults.

How to pick — honestly

A horizontal GRC platform is the right call when:

HIPAA is one of several frameworks you need to satisfy (SOC 2 + HIPAA + PCI DSS + ISO 27001)
Your buyers ask for HIPAA-as-baseline, not HIPAA-as-clinical-rigor
Your clinical workflows are simple or your org is small enough that vertical nuance doesn't move the risk needle

A healthcare-vertical platform is the right call when:

HIPAA is the primary framework and Risk Analysis depth matters
You operate in a regulated subset of healthcare (FQHC, CHC, ASC, behavioral health, dental, hospital)
You have state-overlay exposure (TX HB 300, CA CMIA, NY SHIELD)
Your buyers (health plans, hospital systems, payor networks) do HIPAA-specific due diligence rather than ask for a SOC 2 report

These two product shapes aren't equivalent. They're optimized for different audit-day questions.

The question to actually ask in 2026

If you're picking compliance tooling for a healthcare org this year, the question isn't "does this platform cover HIPAA?" — every credible platform claims that.

The question is: does this platform let our Risk Analysis reflect the specialty, state, and workflow context we actually operate in?

If yes, you're probably looking at a vertical tool. If the answer is "well, you can configure it that way," you're probably looking at a horizontal tool with HIPAA bolted on. Pick the one that matches the layer of HIPAA you'll actually be audited against.

Reading list

Medcurity vs. a horizontal compliance platform — a 2026 HIPAA comparison: https://medcurity.com/medcurity-vs-accountable-hq/
The 2026 HIPAA SRA software landscape: https://medcurity.com/2026-hipaa-sra-software-landscape/
HIPAA risk assessment field guide: https://medcurity.com/hipaa-risk-assessment/
HHS OCR Risk Analysis Initiative (HHS.gov enforcement page)
2024 HHS Security Rule NPRM (Federal Register)

Originally published at https://medcurity.com/medcurity-vs-accountable-hq/

Building a HIPAA Risk Assessment: A Plain-English Guide for Healthcare Teams

Joe Gellatly — Sat, 06 Jun 2026 04:40:54 +0000

Originally published at medcurity.com. Mirrored here for the engineering audience. Canonical points to the source.

If you build, deploy, or support a system that touches electronic protected health information (ePHI), the HIPAA Security Risk Analysis (SRA) is the audit nobody on your team wants to fail. It is the single most cited deficiency in OCR enforcement actions, and the one piece of paperwork that auditors actually read end-to-end.

This is a plain-English walkthrough of what an SRA is, what the regulation literally says, the nine things it has to document, and the places engineering teams typically stub their toes.

What a HIPAA Risk Assessment actually is

Strip away the consultant vocabulary and the SRA is one thing: a written analysis of the threats and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your environment, plus a plan to reduce the high-priority ones to an acceptable level.

The legal hook lives in 45 CFR §164.308(a)(1)(ii)(A):

Conduct an accurate and thorough assessment of the potential
risks and vulnerabilities to the confidentiality, integrity,
and availability of electronic protected health information
held by the covered entity or business associate.

That is the entire regulatory text. Everything else — scoring, methodology, format — is inferred from OCR enforcement actions, the NIST SP 800-66 Rev. 2 implementation guide, and NIST SP 800-30 Rev. 1 (the risk-assessment methodology HHS references).

Who has to do one

Every covered entity (hospital, clinic, health plan, clearinghouse) and every business associate (any vendor that processes ePHI for one) has to perform an SRA. Since the 2013 Omnibus Rule, business associates are directly liable — your SaaS doesn't get a pass because the hospital signed a BAA with you.

If you are an engineer at a digital-health startup, your company is almost certainly a business associate, and an SRA covering your stack is mandatory.

The nine elements OCR expects to see

OCR's published guidance breaks the SRA into nine concrete elements. If any one is missing, the SRA is considered deficient — and that's the most common audit finding in the entire HIPAA program.

Scope of the analysis. Every system, application, network segment, vendor, and physical location that touches ePHI.
Data collection. Where ePHI is created, received, maintained, and transmitted. Diagrams help here; auditors love a flow diagram.
Identification and documentation of potential threats and vulnerabilities. Real, specific ones — not "ransomware in general."
Assessment of current security measures. What's actually in place today, with evidence.
Determination of the likelihood of threat occurrence.
Determination of the potential impact of threat occurrence.
Determination of the level of risk. Likelihood × impact, scored against a defined scale.
Finalize documentation. Written, dated, with named contributors and an approver.
Periodic review and updates to the risk assessment.

A risk register that maps each identified risk to a control, an owner, and a remediation deadline satisfies elements 4 through 7 in one artifact. Most of the platforms in the 2026 SRA software landscape generate this register as a first-class object.

Scoping in the real world

In a microservices stack, scoping is where engineering teams either save themselves weeks or doom themselves to a re-do.

A practical scope inventory:

Data stores — production DBs, replicas, snapshots, analytics warehouses, S3 buckets, message queues, search indices.
Compute — every service or job that reads, writes, or transforms ePHI.
Egress paths — outbound webhooks, third-party APIs, SFTP, email transports.
Identity and access — IdP, MFA solution, service-to-service auth, break-glass accounts.
Endpoints — workstations and mobile devices that access ePHI, including BYOD if it's allowed.
Vendors with ePHI exposure — every subprocessor, with executed BAA, located in the register.

If a system could see ePHI but is supposed to be excluded by control, document the control. Auditors test the boundary, not the intention.

A risk register pattern you can copy

A single row should answer: what's the asset, what could go wrong, how likely, how bad, what mitigates it today, what's the residual risk, who owns the fix.

asset:           prod-postgres-primary
ephi_present:    yes
threat:          credential compromise of read-replica role
vuln:            read-replica role permits SELECT on patient_records
likelihood:      moderate
impact:          high
inherent_risk:   high
current_ctrls:   - IAM role assumed via OIDC short-lived tokens
                 - row-level security on patient_records
                 - audit log to siem (90d retention)
residual_risk:   moderate
remediation:     promote retention to 365d to satisfy 2026 NPRM
owner:           security-eng-lead
due:             2026-09-30

Repeat for every asset in scope. The 80/20 of an SRA is getting this register populated honestly.

The three safeguard categories you have to evaluate

HIPAA splits required controls into three buckets and your SRA must consider all of them:

Administrative safeguards — security officer designation, workforce training, access-management policies, BAAs, incident response, contingency planning.
Physical safeguards — facility access, workstation security, device and media controls.
Technical safeguards — access controls (unique IDs, automatic logoff, RBAC), audit controls (logging, log review), integrity controls, authentication (MFA strongly expected, mandatory under the proposed 2026 rule), transmission security, encryption at rest.

Engineering teams default to the technical column. The administrative column is what auditors actually probe — show me your BAA register, show me your termination playbook, show me your last incident retro.

What is changing under the proposed 2026 Security Rule update

HHS published a Notice of Proposed Rulemaking in January 2025 that would rewrite the Security Rule for the first time since 2013. The proposal is not yet finalized, but the direction is locked in. The most operationally significant deltas for engineering teams:

The "required" vs. "addressable" distinction goes away. The categories that used to be "addressable" — most notably encryption — would become hard requirements.
A comprehensive technology asset inventory would be required as part of the SRA itself.
Vulnerability scanning at least every six months.
Annual penetration testing for in-scope systems.
MFA mandatory on every system that accesses ePHI.
Encryption at rest mandatory.
Quantitative risk ratings aligned with NIST SP 800-30 — narrative "high concern" descriptions would no longer satisfy the rule.

Build to the proposed standard now. The retrofit cost when the final rule lands is uniformly higher than the cost of doing it right the first time.

How often you have to do this

HIPAA doesn't name a frequency. OCR's de facto position, repeated across enforcement actions:

At minimum annually.
Immediately upon any significant change — new EHR, new cloud migration, a merger or acquisition, a security incident, a material workflow change.
Per-project for new ePHI workflows — onboarding a new vendor with PHI access, launching a new service line.

If your last SRA is more than 12 months old, you are out of compliance regardless of how good the previous one was.

Common engineering-side mistakes

Patterns we see on every audit:

Treating the SRA as a one-time document. It's a program. The report is just the most recent snapshot.
Documenting controls without evidence. OCR's audit posture is "if it isn't documented with proof, it doesn't exist."
Skipping the BAA register. Vendor risk is the second-most-common breach vector after phishing.
Identifying high-priority risks without remediation plans. OCR treats known and unaddressed as worse than unknown.
Forgetting analytics pipelines. That ePHI warehouse you spun up for the data science team is in scope.

A practical starting point

For teams just getting started, Medcurity's 2026 HIPAA SRA template (downloadable PDF from the pillar page) gives you the nine-element structure, the safeguard checklist, and a risk-register skeleton.

FAQ

Is a HIPAA risk assessment the same as a HIPAA audit? No. The SRA is something you perform on your own environment to identify and remediate risks. The audit is OCR or its delegate verifying that you actually did the SRA and addressed the findings.

Does the OCR free SRA Tool satisfy the requirement for a startup? It produces a defensible baseline for a solo practitioner. For a multi-service stack with cloud infrastructure, it's an inadequate substitute for a real risk register, mostly because there is no continuous remediation tracking and no multi-environment aggregation. Treat it as a starter, not a finish line.

Do we need an SRA for the staging environment? If staging holds real ePHI — even briefly — yes. If staging only holds synthetic data, document the control that enforces that boundary.

What does an SRA usually cost? Internal effort: typically 40–120 hours for a mid-sized practice; more for a multi-site or platform organization. Platform-supported SRAs that integrate with control evidence and BAA management materially reduce the per-cycle effort starting in year two.

Authoritative references

HHS OCR — Guidance on Risk Analysis Requirements under the HIPAA Security Rule
NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule
NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments
45 CFR § 164.308 — Administrative safeguards (eCFR)
HealthIT.gov — Security Risk Assessment Tool

Originally published at medcurity.com/what-is-a-hipaa-risk-assessment/.

The 2026 HIPAA Security Rule: A Mid-Year Readiness Check (June 2026)

Joe Gellatly — Fri, 05 Jun 2026 22:13:14 +0000

Canonical version of this article lives on the Medcurity blog: https://medcurity.com/hipaa-security-rule-2026-update/

If you run security or compliance for a healthcare organization, the single most important regulatory question of 2026 is still open: the proposed HIPAA Security Rule overhaul has not been finalized yet — but the timeline is tightening, and OCR is already enforcing the spirit of it. This is a mid-year checkpoint on where things actually stand and what to have in place before the final rule lands.

Where the rule stands right now

OCR issued its Notice of Proposed Rulemaking on December 27, 2024 (90 FR 800). It drew more than 4,700 public comments, which OCR is still working through. A final rule has been broadly expected around mid-2026, but as of this writing OCR has not confirmed a publication date. When it does publish, covered entities and business associates will get 240 days from publication to comply — so the window to prepare is the time you have now, before the clock starts.

The practical takeaway: don't wait for the Federal Register notice to start the work. The proposed requirements are specific enough to build against today, and most of them are things a mature security program should already be doing.

The four changes worth preparing for

The NPRM is long, but four proposed requirements drive most of the operational change for small and mid-sized healthcare orgs:

Six-month vulnerability scanning cadence. The proposal moves vulnerability scanning from a vague "as needed" posture to a defined recurring cadence. If you scan once a year (or only after an incident), build the muscle for twice-yearly scans now.
Annual penetration testing. Distinct from scanning — a real test, not a checkbox. Budget for it and identify a qualified provider before it's mandatory.
Mandatory encryption of ePHI at rest and in transit, with narrow documented exceptions. The "addressable" wiggle room many orgs have leaned on shrinks considerably.
A genuine, current risk analysis. This is the through-line of the whole rule — and the one OCR is already enforcing hardest.

OCR isn't waiting for the final rule

Here's what makes this urgent even before finalization: OCR's Risk Analysis Initiative is a live enforcement campaign targeting organizations that never performed an adequate security risk analysis. By mid-2025 it had produced seven enforcement actions; by early 2026 the count had reached eleven. OCR has reiterated that an inadequate or missing risk analysis remains the most frequently cited deficiency in investigations.

In other words: the most-enforced requirement of the future rule is the most-enforced deficiency under the current one. A defensible, current, organization-wide risk analysis is the work that pays off no matter when the final rule publishes.

A 30-minute readiness self-check

Before the rule finalizes, walk through this:

When was your last security risk analysis, and does it cover every system that touches ePHI (including SaaS, mobile, and BA-hosted systems)?
Do you have a documented vulnerability-scanning schedule you could move to a six-month cadence without scrambling?
Have you ever had a real penetration test — and could you produce the report?
Is ePHI encrypted at rest and in transit, with documented exceptions where it isn't?
If OCR asked for your risk-analysis documentation tomorrow, could you produce it within a week?

If any answer is "no" or "not sure," that's your pre-finalization to-do list.

Bottom line

The 2026 Security Rule isn't final, but the direction is clear and OCR is enforcing the foundation today. Treat the 240-day comply-by window as a planning horizon you can get ahead of: a current risk analysis, a defined scanning cadence, a real pen test, and encryption you can document. Organizations that do this work now will treat the final rule as a formality rather than a fire drill.

Originally published at medcurity.com — the canonical version is updated as the rulemaking develops.