HIPAA Security Rule Update Get ahead of the rule.

    Loading...

    Would You Bet an Audit on an App That Looked Ready?

    > TL;DR: AI coding tools can produce an app that looks like a five-year-old product in a weekend. HIPAA did not get shorter in that weekend. If the app creates, receives, maintains, or transmits PHI for a covered entity, it is in the business-associate world — a signed BAA, satisfactory assurances, a real risk analysis, unique user IDs, audit controls you actually review, and a chain of subcontractors (host, model, email, analytics, error logs) that can say the same. The UI is not evidence of any of that. Print the ten-question worksheet before PHI moves.

    A polished login screen used to mean something. It meant someone had been in business long enough to have a security official, a risk analysis, and a vendor list they could produce.

    That signal is gone.

    You can now sit through a demo of a patient-intake tool, an AI scribe, a staff scheduler, a referral portal, that looks like it has been in market for years. Pricing page. Status page. A "HIPAA" line in the footer. It might have been generated on Tuesday. The people who built it may be earnest, talented, and trying to help. The Privacy Rule and the Security Rule did not get shorter because the interface got better.

    I get it. Staff find these tools because the old ones are slow. A practice administrator is wearing four other hats. Someone on the team pastes a chart note into a new app because it "just works." Nobody is trying to leak a patient. The gap is quieter than that: visual maturity and regulatory maturity used to travel together. They don't anymore.

    This is the same paperwork-versus-reality problem I've watched across 500+ organizations — now wearing a better coat of paint.

    What "vibe-coded" means here

    People use that phrase for software built, fast, with AI coding tools: a prompt, a generated interface, a hosted database, a payment link, a launch.

    I am not picking a fight with the tools, or with builders. Speed is not the violation. Treating a generated product surface as proof of a privacy and security program is the trap.

    A weekend can now produce:

    A weekend cannot produce, by itself, the things OCR actually asks for: an accurate and thorough risk analysis, written policies that match how the system works, unique user identification, activity records someone reviews, subcontractors bound to the same rules, and a way to return or destroy PHI when the relationship ends.

    If you have ever signed a BAA because the vendor's site said "HIPAA-compliant," you already know this pattern. The tool being marketed as compliant does not make your use of it compliant. That was true of Drive folders. It is true of a new app that showed up in a Slack channel.

    Privacy and Security are two different jobs

    HIPAA is not one blob called "compliance." For an app that touches patient data, two rulebooks both have to be true at the same time.

    Privacy is about whether PHI may be used or disclosed, to whom, and for what. A covered entity or business associate may not use or disclose protected health information except as the Privacy Rule permits or requires (45 CFR 164.502(a)). When they do, they have to make reasonable efforts to limit PHI to the minimum necessary for the purpose (45 CFR 164.502(b)) — with listed exceptions such as treatment, the individual, and a valid authorization. (Source: 45 CFR 164.502.)

    Security is about electronic PHI: confidentiality, integrity, and availability. Covered entities and business associates must protect against reasonably anticipated threats and against uses and disclosures the Privacy Rule does not permit (45 CFR 164.306(a)). (Source: 45 CFR 164.306.)

    An app can fail either side without looking broken. A beautiful intake form that pipes names and symptoms to an analytics pixel is a Privacy problem. The same form with a shared "admin" login and no activity log is a Security problem. Most of the new tools I get asked about have not been designed against either list. They have been designed against a screenshot.

    PHI, in the rule, is individually identifiable health information a covered entity (or a business associate holding it for one) transmits or maintains — including in electronic form (45 CFR 160.103). PII is a broader everyday term: name, email, phone, IP address, anything that points at a person. HIPAA does not use "PII" as its test. If the data is health-related and identifies someone, and a covered entity or its vendor is holding it, you are in PHI territory. If the app is not a HIPAA entity, you may still be in federal health-privacy territory under the FTC. More on that below.

    What the rule actually says

    Skip the badge on the website. Read the words the rule uses.

    1. If it handles PHI for you, it is probably a business associate

    A business associate is a person who, on behalf of a covered entity, creates, receives, maintains, or transmits protected health information — or who provides services that involve a disclosure of PHI (45 CFR 160.103). That definition includes a subcontractor that creates, receives, maintains, or transmits PHI on behalf of the business associate. (Source: 45 CFR 160.103.)

    OCR's cloud guidance is blunt on the "we never look at the data" line. When a covered entity engages a cloud service to create, receive, maintain, or transmit ePHI on its behalf, the cloud provider is a business associate. Not looking at the PHI does not take them out. (Source: HHS OCR, Guidance on HIPAA & Cloud Computing.)

    So: the new scribe, the new intake app, the new "AI layer" on your EHR export — if it is doing that work for a clinic, it is in this definition. So is the host behind it. So is the model provider if PHI is sent to that API. So is the error-logging service if stack traces contain patient content. The definition does not ask whether the product looks mature.

    2. A BAA documents satisfactory assurances. It is not the assurance.

    A covered entity may disclose PHI to a business associate only if it obtains satisfactory assurance that the associate will appropriately safeguard the information (45 CFR 164.502(e)(1)(i)). The Security Rule says the same for ePHI (45 CFR 164.308(b)(1)). The written contract is how you document those assurances (45 CFR 164.502(e)(2), 164.308(b)(3)). (Source: 45 CFR 164.502; 45 CFR 164.308.)

    We wrote the longer version of this in A Signed BAA Isn't "Satisfactory Assurance". The short version for a new app: a PDF of a BAA in a week-old Google Drive is not evidence the safeguards exist.

    What the contract itself must contain is not a mystery. 45 CFR 164.504(e)(2) requires, among other things, that the associate will not use or disclose PHI except as the contract permits; will use appropriate safeguards and comply with the Security Rule for ePHI; will report unauthorized uses and disclosures, including breaches under 45 CFR 164.410; will bind subcontractors to the same restrictions; will support access, amendment, and accounting of disclosures; will make its relevant books available to the Secretary; and will, at termination, return or destroy PHI it still maintains, or explain why that is not feasible. (Source: 45 CFR 164.504.)

    Ask a one-person app company to walk that list out loud. Not to be cruel. To find out whether anyone has read it.

    3. Required is required. Addressable is not optional.

    This is the distinction a landing page always fudges, and it is load-bearing.

    Under 45 CFR 164.306(d), every Security Rule standard must be implemented. Implementation specifications are marked Required or Addressable. Addressable does not mean "skip it." It means: assess whether the specification is reasonable and appropriate; implement it if it is; or if it is not, document why and implement an equivalent alternative if reasonable and appropriate. (Source: 45 CFR 164.306.)

    Encryption of ePHI at rest (45 CFR 164.312(a)(2)(iv)) and encryption in transit (45 CFR 164.312(e)(2)(ii)) are addressable. Unique user identification (45 CFR 164.312(a)(2)(i)) is required. Audit controls — recording and examining activity in systems that contain or use ePHI — are a standard (45 CFR 164.312(b)). Information system activity review is required (45 CFR 164.308(a)(1)(ii)(D)). Person or entity authentication is a standard (45 CFR 164.312(d)). Risk analysis is required (45 CFR 164.308(a)(1)(ii)(A)). (Source: 45 CFR 164.312; 45 CFR 164.308.)

    A vendor who says "HIPAA doesn't require encryption" has confused addressable with optional. A vendor who says "we don't keep logs because we're a small app" has missed a standard. Both mistakes show up in tools that look finished.

    We broke out the logging half — record and regularly review — in HIPAA Audit Log Requirements. If the new app cannot tell you who opened which record last Tuesday, you cannot bound an incident. The absence of a log does not make the event smaller. It makes it bigger, on paper, by default.

    4. The program has to be written down, and it has to keep up with change

    Business associates must implement reasonable and appropriate policies and procedures, keep them in writing, and retain that documentation for six years (45 CFR 164.316). They must also perform a periodic technical and nontechnical evaluation, including in response to environmental or operational changes affecting the security of ePHI (45 CFR 164.308(a)(8)). (Source: 45 CFR 164.316; 45 CFR 164.308.)

    A vibe-coded rewrite is an operational change. Shipping a new database, swapping model providers, turning on a support widget — each of those changes the risk picture. The rule already asked for a new look when the environment changed. It did not wait for AI coding tools to arrive.

    Covered entities still have their own Privacy Rule homework: a designated privacy official, workforce training on privacy policies, administrative/technical/physical safeguards for privacy, a complaint process, sanctions, mitigation (45 CFR 164.530). Putting PHI in a new app without touching training, policies, or the vendor list is how a living compliance program goes stale. (Source: 45 CFR 164.530.)

    The chain behind the login screen

    The product you see is rarely the whole system.

    A typical new healthcare app, even a careful one, sits on a stack that might include a hosting provider, a managed database, an authentication vendor, a large-language-model API, a transcription service, an email or SMS vendor, an error tracker, a session-replay tool, a payments processor, and a chat widget that files tickets. Each of those, if it creates, receives, maintains, or transmits PHI, is in the business-associate / subcontractor chain (45 CFR 160.103; 164.308(b)(2); 164.502(e)(1)(ii); 164.504(e)(2)(ii)(D)).

    The business associate has to obtain satisfactory assurances from its subcontractors. You, the covered entity, are not required to contract directly with those subcontractors. You are required to obtain satisfactory assurances from the vendor you hired. If they cannot name the chain, they cannot give you that assurance.

    This is also where "we don't look at your data" stops being an answer. OCR has already said a cloud provider that stores ePHI is a business associate whether or not they view it. A model API that receives chart text to generate a summary is receiving PHI. An error log that captures a request body with a medical record number is maintaining PHI. Session replay that records an authenticated chart view is transmitting PHI.

    None of that is visible in the demo. All of it is visible if you ask for the subprocessor list and the BAAs behind it.

    Analytics and pixels deserve their own sentence. OCR has published guidance on online tracking technologies used by covered entities and business associates. If a tracker, pixel, or SDK is sent PHI, that disclosure has to be permitted under the Privacy Rule — typically a business-associate relationship, or a valid authorization. A privacy policy is not a BAA. (Source: HHS OCR, Use of Online Tracking Technologies.)

    Default analytics on an authenticated intake form is one of the fastest ways a "HIPAA-ready" app stops being ready.

    The tells that still work

    The UI will lie to you. A few questions will not.

    They offer a BAA only after you ask, or they send a one-page "HIPAA addendum" that never mentions subcontractors, breach reporting, or return-or-destroy. That is a contract written to close a sale. Compare it to 45 CFR 164.504(e)(2). We covered the required pieces in Business Associate Agreements: What They Are and Why You Need One.

    They say "hosted on HIPAA-compliant infrastructure." AWS, Azure, and Google can all sign BAAs. Hosting on a platform that will sign a BAA is necessary and nowhere near sufficient. The Security Rule still sits on the app: access control, authentication, audit controls, integrity, transmission security, risk analysis, workforce access, incident procedures, backup. The hyperscaler does not run those for a generated app unless someone configured them.

    Shared logins, a single "clinic" user, or magic links with no way to tell people apart. Unique user identification is required (45 CFR 164.312(a)(2)(i)). If you cannot name the person, you cannot produce an access report that means anything.

    No story for backup, restore, or emergency access. Data backup is required (45 CFR 164.308(a)(7)(ii)(A)). Emergency access procedure is required (45 CFR 164.312(a)(2)(ii)). "It's in the cloud" is not a backup plan.

    **No named security official, no written risk analysis, no policies that mention this product.** Assigned security responsibility is a standard (45 CFR 164.308(a)(2)). Risk analysis is required. Documentation is required. A trust-center page generated from a template is not a risk analysis.

    They cannot tell you what happens to PHI in model-provider logs, support tickets, or browser replay. If they have not mapped it, they have not analyzed the risk. 45 CFR 164.308(a)(1)(ii)(A) asks for an accurate and thorough assessment of the potential risks and vulnerabilities to the ePHI they hold — not a generic PDF about "AI safety."

    Breach notification is "we'll email you." A business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery, and the notice has to identify the individuals involved to the extent possible (45 CFR 164.410). Sixty days is the ceiling, not a target. If they have never written an incident procedure, they will not meet it on a Friday night. (Source: 45 CFR 164.410.)

    At offboarding they shrug. The BAA requires return or destruction of PHI, or a documented reason it is not feasible (45 CFR 164.504(e)(2)(ii)(J)). Backups, log drains, and model logs are how "we deleted the database" becomes untrue.

    None of these tells requires you to be unkind. They require you to stay in the conversation past the demo.

    If they say they're not even under HIPAA

    Sometimes that is true. A consumer wellness app a patient installs on their own, with no relationship to a covered entity, may not be a business associate. HHS published health-app scenarios for exactly this line-drawing. (Source: HHS, Resources for Mobile Health Apps Developers.)

    "Not HIPAA" is not "no federal duty."

    The FTC Health Breach Notification Rule applies to vendors of personal health records, PHR-related entities, and their third-party service providers that are not HIPAA-covered entities or business associates acting as such (16 CFR 318.1(a)). The 2024 amendments — effective July 29, 2024 — clarified that many health apps sit in that bucket, and that a "breach of security" includes unauthorized disclosures, not only a hacker in the network. (Source: 16 CFR 318.1; FTC, April 26, 2024.)

    So the fork is simple:

    Either way, a pixel leaking health data is someone's problem. It is often yours if you pointed patients at the app.

    The federal-and-state AI map — what is in effect, what is proposed, what already applies because HIPAA never needed an "AI section" — lives at AI in healthcare: the rules, in plain English. There is still no AI exemption in HIPAA. An AI vendor that sees PHI is a business associate.

    How to vet one of these before PHI moves

    Do this before the pilot, not after the first real patient.

    Print the PHI App Readiness worksheet. It is ten questions. Each one maps to a citation above. Fill it with the vendor on the phone, or send it and see what comes back.

    You are listening for evidence, not adjectives.

    If the answers are "we're working on SOC 2" and "our host is HIPAA-compliant," you do not have satisfactory assurance. You have a roadmap. Roadmaps do not receive PHI.

    Covered entities still own the outcome. That is the system, not a moral failing of a small vendor. Most of these shops are smart and well-intentioned. Many have never been told that a BAA is a regulatory contract attesting to safeguards, not a sales PDF. When the gap surfaces, the organization that handed over the PHI is the one holding the exposure.

    Same pattern as the MSP BAA gap. New coat of paint.

    How Live Compliance closes it

    Live Compliance is built for the part a new app cannot fake: the living program around every tool that touches PHI. Vendor attestations and BAA tracking so "satisfactory assurance" is a record, not a folder. Risk analysis that has to be redone when the environment changes — including when someone adds an AI tool. Training that names your privacy and security officials. Policies that have to match the practice, not a template. Continuous monitoring of system activity, so logs are reviewed instead of stored. Incident workflow with a clock.

    The new app, if it is a real business associate with real safeguards, can sit inside that program. The program is what tells you whether it belongs there.

    We have spent 16 years watching the gap between what a product page promises and what a vendor can actually show — across 500+ organizations, with a 100% audit success rate. See how the platform fits together, or talk to us before the next tool on your floor gets a patient name.

    If you only do one thing this week: print the worksheet and run it against the last app someone asked you to "just try."

    Frequently Asked Questions

    Does a vibe-coded app automatically violate HIPAA?

    No. How the app was built is not a HIPAA test. What it does with PHI is. If it creates, receives, maintains, or transmits PHI for a covered entity, the business-associate rules apply the same way they apply to any other vendor (45 CFR 160.103, 164.308(b), 164.502(e)). A carefully built new app with a real BAA, a real risk analysis, and a real subcontractor chain can be fine. A polished app with none of those is not.

    Does a signed BAA make the app HIPAA-compliant?

    No. The BAA is how you document satisfactory assurances. It is not the assurance, and it is not a Security Rule implementation. You still need the safeguards the contract attests to (45 CFR 164.502(e), 164.308(b), 164.504(e)). See satisfactory assurances.

    If the app runs on AWS, Azure, or Google Cloud, are we covered?

    Not by itself. Those providers can be business associates when they store or process ePHI, and they will sign BAAs. The app on top of them still has to implement access control, authentication, audit controls, risk analysis, incident procedures, and the rest of 45 CFR 164.308–164.316. "Hosted on HIPAA-eligible infrastructure" is one control in a much longer list.

    Is encryption required under HIPAA?

    Encryption of ePHI at rest and in transit is addressable, not required (45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii)). Addressable means implement it if reasonable and appropriate, or document why not and implement an equivalent alternative (45 CFR 164.306(d)). It does not mean optional. For an internet-facing app holding ePHI, "we skipped encryption" is almost never a documented, equivalent alternative. Get the label right anyway. Precision is the point.

    What's the difference between PHI and PII for these apps?

    PHI is a HIPAA term: individually identifiable health information held or transmitted by a covered entity or business associate (45 CFR 160.103). PII is a broader everyday term for data that identifies a person. An email address in a newsletter tool is PII. An email address sitting next to a diagnosis in a clinic's new app is PHI. If you are unsure, treat it as PHI until counsel or your risk analysis says otherwise.

    Do consumer health apps have to follow HIPAA?

    Only if they are a covered entity or a business associate of one. A consumer app a patient uses on their own may fall outside HIPAA and still be covered by the FTC Health Breach Notification Rule (16 CFR Part 318) and the FTC Act. "We're not under HIPAA" is the start of a vendor conversation, not the end of it. (Source: 16 CFR 318.1; HHS health apps guidance.)

    What should I ask a new vendor this week?

    Use the ten-question worksheet. If you only have five minutes: Will you sign a BAA before PHI moves? Who else sees this data (host, model, email, analytics, logs)? Can you show a risk analysis of this system? Can you show unique users and activity logs? What happens to our PHI if we leave?

    > Accuracy & legal note. This article is a plain-language summary of HIPAA requirements as of August 2026, based on the HIPAA Rules (45 CFR Parts 160 and 164), the FTC Health Breach Notification Rule (16 CFR Part 318), and HHS/FTC guidance current as of that date. Regulations, OCR guidance, and enforcement priorities change. This is general educational information, not legal advice — verify current requirements at hhs.gov/hipaa or with your compliance counsel before acting. Platform capabilities described reflect Live Compliance as of the publish date. Last updated: August 2026.