Encrypted Email Is Not a Compliance Program: HIPAA Security for Therapy Practices

The call usually goes the same way. A therapist has heard from a colleague, or a licensing board newsletter, or an intake platform's onboarding email, that they need HIPAA compliant email. They want a quote.

Two questions in, it becomes clear that encrypted email is somewhere around item fourteen on a list nobody has started. Client notes are in a folder on a laptop that also has a family member's user profile on it. There is no backup, or there is a backup running to a personal cloud drive that nobody has a contract with. The scheduling tool was picked because it was free. Nothing is written down.

The assumption is that this is a new practice problem. It is not. Practices that opened last quarter have this conversation, and so do practices that have been seeing clients for fifteen years. The established ones often look worse on inspection, because time adds inventory without adding structure: vendors signed up one at a time as needs came up, a business associate agreement executed in 2017 that nobody has looked at since, three laptops retired to a closet with client data still on them, a former front desk employee whose EHR login was never disabled. A new practice is starting from zero. An older practice is often starting from a mess, which is harder.

This is not a criticism of therapists. Clinical training does not include systems administration, and nothing about hanging a shingle tells you that the federal government expects you to run an information security program. But that is the situation, and the gap between what practice owners think HIPAA requires and what it actually requires is one of the widest we see in health care IT.

This article is about the Security Rule side of that gap: the technology and operational requirements that apply to a solo or small behavioral health practice, whether it opened last month or last decade. It also flags the Privacy Rule material you need to know exists so you can go research it properly, because that side is a clinical and legal question more than an IT one.

First: are you actually a covered entity?

Worth confirming before you spend money, because the answer determines whether any of this applies. Worth reconfirming periodically too, because the answer can change without anyone noticing.

Start with the practical answer, because for most readers it is the right one: if your practice touches insurance in any way, assume you are covered. Submitting claims, verifying benefits, checking eligibility, requesting prior authorization, or letting your practice management platform do any of that on your behalf all put you squarely inside HIPAA. Most behavioral health EHRs bundle these functions, and most practices use them. If that describes you, skip ahead. The rest of this section is for the practices where the answer is less obvious.

The actual test is narrower than most people assume, and it is narrow in a specific direction. HIPAA reaches a health care provider who transmits health information in electronic form in connection with a transaction for which HHS has adopted a standard. Those standard transactions are enumerated in 45 CFR Part 162: claims, eligibility inquiries, claim status, referral certification and authorization, enrollment and disenrollment, premium payments, coordination of benefits, and remittance advice.

The trigger is the transaction, not the technology. Keeping records electronically does not by itself make you a covered entity. Neither does using a cloud EHR, running a paperless office, conducting telehealth, emailing clients, or taking card payments. HHS's own guidance on cloud computing frames a covered entity as a provider who conducts certain billing and payment related transactions electronically, which is a description of billing activity rather than a description of where data lives. Uploading a progress note to a vendor's servers is an electronic transmission of health information, but it is not one of the transactions HHS has adopted a standard for.

HHS has said this about mental health professionals specifically. In FAQ 513, addressing whether schools are covered entities, HHS explains that a school employing nurses, physicians, psychologists, or other health care providers is generally not a covered entity, because those providers do not engage in covered transactions such as billing a health plan electronically. Being a psychologist is not the trigger. Employing one is not the trigger. The transaction is.

This distinction is worth holding onto because published guidance frequently blurs it. You will see the test written as "conducts electronic transactions or maintains electronic health records," which fuses two unrelated things. Whether information is electronic determines what is protected once you are covered. It does not determine whether you are covered. The Security Rule governs ePHI, but it only reaches you if you are a covered entity or a business associate to begin with.

Two corollaries follow, and both run opposite to intuition.

The first concerns outsourcing. If a billing service, clearinghouse, or your EHR vendor submits claims electronically on your behalf, you are still conducting the transaction. Handing the task to someone else does not move the obligation.

The second concerns business associate agreements, and it runs the other direction from how people usually reason about it. A business associate is defined with respect to a covered entity. If you are not a covered entity, your cloud EHR vendor is not your business associate, and HIPAA does not require a BAA between you, because HIPAA does not reach either party. A vendor's willingness to sign a BAA does not pull you into HIPAA's scope. You may still want one as a matter of contract, and state law may impose its own requirements, but that is a different argument than the federal one.

Superbills are where cash pay practices most often sit, and the analysis there depends on mechanics rather than labels. The question is not whether a superbill exists. It is whether you transmitted a standard transaction electronically. Generating a document a client files themselves is a different act than filing on their behalf, and third party out of network billing platforms vary in who they name as the submitting party. If you use one, read the agreement and look at what the system actually does rather than what it is called. This is a determination to make with counsel, not by analogy.

So a genuinely cash pay practice that never submits an electronic claim, never runs an electronic eligibility check, and never transmits a covered transaction is generally not a covered entity. That is a real category, but it is smaller and more fragile than the people in it usually believe. Accepting one insurance client changes the answer. So does credentialing with a single payer, adding a clinician who bills insurance, or switching to a platform that verifies benefits in the background as a convenience feature. Practices that correctly determined they were outside HIPAA years ago sometimes crossed the line since without revisiting the question. Verify your actual workflows. Do not assume that "cash pay" or "solo practice" settles it.

Two things remain true even if you land outside HIPAA. You can still become a business associate of someone else, which carries direct Security Rule obligations of its own, if you contract with a covered group practice or agency to provide services involving their PHI. And state confidentiality law, licensing board requirements, and professional ethics apply regardless. In several states those obligations are close enough to HIPAA that the practical difference is smaller than it looks on paper.

If you are not certain, this is the one question in this article worth putting in front of a health care attorney before you build anything.

The requirement is a risk analysis, not a product

Here is the structural thing that trips people up. The Security Rule does not contain a list of approved products. It contains standards, and under those standards, implementation specifications marked either Required or Addressable. The flexibility language at 45 CFR 164.306(b) explicitly directs covered entities to consider their size, complexity, technical infrastructure, security capabilities, and the cost of security measures when deciding how to implement.

A solo counselor with one laptop and one EHR is not expected to build what a hospital builds. But that flexibility is not a pass. It is a requirement to make and document reasoned decisions, and the mechanism for making those decisions is the risk analysis at 45 CFR 164.308(a)(1)(ii)(A). That specification is Required, not Addressable. You must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the electronic protected health information you hold.

The reason this matters practically: OCR's risk analysis enforcement initiative has made this the most commonly cited failure in Security Rule investigations. When a small practice gets a complaint or reports a breach, the first document OCR asks for is the risk analysis. Not the encryption receipts.

HHS publishes a free Security Risk Assessment Tool built specifically for small and medium providers, developed by OCR with the Assistant Secretary for Technology Policy (ASTP/ONC). The current release is version 3.6, with an updated installer designated 3.6.1 that carries a refreshed certificate and no functional changes. It ships in two forms: a desktop application that runs only on Windows, and an Excel workbook covering the same content. If your practice runs on Macs, which many solo practices do, the workbook is your version. All data stays local to your machine either way. It walks through the standards, tracks assets and vendors, and produces a report you can retain. It does not make you compliant by itself, and HHS says as much. It does give a practice with no IT background a structured starting point and, critically, documentation.

Before you can run it usefully, you need an inventory: every device, application, and vendor that creates, receives, maintains, or transmits ePHI. Laptop, phone, tablet, EHR, telehealth platform, email, cloud storage, backup, billing service, transcription or AI note tools, appointment reminder service, the answering service. Most practice owners are surprised by how long the list gets, and by how many of the items on it are consumer grade services that were never intended to hold clinical records.

For an established practice, the inventory needs a second column: things that used to be in service and never got dealt with. The old workstation in the storage room. The EHR you migrated off of three years ago, which may still be holding your historical records under a contract you are still paying for or, worse, one that lapsed. The external drive from the backup scheme you abandoned. The phone you replaced. Disposal and media re-use at 45 CFR 164.310(d)(2)(i) and (ii) are both Required specifications, and they are the ones most likely to be quietly failing in a practice that has been running long enough to accumulate hardware.

Business associate agreements are contracts, not badges

Any vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate, and you need a written agreement with them. The obligation sits at 45 CFR 164.308(b)(3), with the required contract terms specified at 45 CFR 164.314(a).

Four things practices get wrong here.

The first is treating a vendor's marketing claim as sufficient. A website that says "HIPAA compliant" is a marketing statement. A signed BAA is a contract. If the vendor will not sign one, the product cannot hold your ePHI, whatever the homepage says.

The second is assuming the BAA is automatic on services that do offer one. Google Workspace is the clearest example. Google will enter into a HIPAA business associate amendment, but a super administrator has to affirmatively review and accept it in the Admin console, and it only covers specific in scope services when configured correctly. A practice that signed up for Workspace and started emailing clients has a signed BAA only if somebody went and accepted it. Free consumer Gmail is not covered at all. Microsoft handles this differently, incorporating HIPAA business associate terms into its commercial licensing terms rather than requiring separate acceptance, which means the practical question for Microsoft 365 shifts to which plan you hold and how you configured it. Either way, download and retain a copy of what you agreed to.

The third is missing the vendors that do not feel like health care vendors. Cloud backup, file sync, IT support providers, virtual assistants, answering services, and increasingly AI scribes and note summarization tools all touch PHI. If a person or system on the other end can see client information, that relationship needs a contract.

The fourth is specific to practices that have been running a while: a BAA signed once is not a BAA maintained. Vendors get acquired. Products get rebranded and re-papered under new terms. Free tiers you signed up for years ago quietly added an AI feature that processes your notes. A practice that adopted a scheduling tool in 2018 and never revisited it may be operating under an agreement that no longer describes the product, or under no agreement at all if the original entity no longer exists. Pull the file once a year and confirm each agreement still matches a vendor you still use.

The technical safeguards that apply to a small practice

Section 164.312 is short. For a practice of one to five clinicians, five things in it deserve attention.

Unique user identification is Required. 45 CFR 164.312(a)(2)(i) requires assigning a unique name or number for identifying and tracking user identity. In practice this kills the shared login. If a spouse or roommate uses the same Windows or macOS account you use for client records, you cannot identify who did what, and you have failed a Required specification. The multi clinician version of the same failure is the shared front desk account that everyone at the front uses, or the generic billing login that two people know the password to. Separate accounts for separate humans, on every system. This is free.

Emergency access procedure is Required. 45 CFR 164.312(a)(2)(ii) requires procedures for obtaining necessary ePHI during an emergency. For a solo practice this is usually a documented answer to a simple question: if you are hospitalized tomorrow, how does a covering clinician get to the records your clients need? Write down the answer, and write down who the designated person is by name, because a procedure that does not identify anyone is not a procedure. Store the credentials somewhere that person can actually reach without you: a password manager with an emergency access feature, or a sealed envelope with your attorney. That store is itself holding the keys to ePHI, so it needs the same protection as anything else on your inventory. For a group practice, the same question applies to whoever holds the administrator account on the EHR, the domain registrar, and the email tenant. Practices discover they have a single point of failure at exactly the worst moment.

Audit controls is a Required standard. 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems containing ePHI. There are no implementation specifications under it, which means there is no flexibility about whether it applies. In a small practice this generally means using an EHR that keeps an access log and knowing how to pull it. The companion requirement at 45 CFR 164.308(a)(1)(ii)(D), information system activity review, is also Required and asks you to actually look at those records periodically. Logs you have never opened are not a review.

The regulation does not specify how often. That is deliberate, and it is also a trap, because a requirement with no stated interval is easy to defer forever. Pick an interval you will actually hold to, write it into your policy, and record the date each time you do it. A short note saying you reviewed the EHR access log on a given date and found nothing unusual is worth considerably more than a vague intention to check occasionally. What you are looking for in a small practice is simple: logins at hours nobody works, access to charts by someone with no treatment relationship to that client, and accounts active for people who no longer work there.

Encryption is Addressable, and that word does not mean optional. 45 CFR 164.312(a)(2)(iv) covers encryption of ePHI, and 45 CFR 164.312(e)(2)(ii) covers encryption in transmission. Both are Addressable. Under 45 CFR 164.306(d)(3), an Addressable specification requires you to assess whether it is reasonable and appropriate in your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative where reasonable. For a laptop carrying client records in 2026, the honest assessment is that full disk encryption is reasonable and appropriate. BitLocker on Windows and FileVault on macOS are included with the operating system. Turning them on takes minutes.

There is a second reason to care. The Breach Notification Rule turns on unsecured PHI, and PHI encrypted to the standard HHS has specified is not unsecured. Encryption is the difference between a lost laptop being a notification event and a lost laptop being a bad afternoon.

Automatic logoff is Addressable under 45 CFR 164.312(a)(2)(iii). Screen lock timeouts on every device that touches records. Also free.

Once you have staff, offboarding becomes a compliance control

The moment a practice adds a second person, a set of administrative safeguards switches on that a solo practitioner can mostly reason through in an afternoon.

Workforce security at 45 CFR 164.308(a)(3) carries three Addressable specifications: authorization and supervision, workforce clearance procedure, and termination procedures. Termination procedures at 45 CFR 164.308(a)(3)(ii)(C) require procedures for ending access to ePHI when someone's employment or arrangement ends. Addressable, again, meaning assess and either implement or document an equivalent.

In a practice with turnover, this is where the real exposure lives. An intern rotated out eighteen months ago and their EHR account is still active. A biller you stopped working with still has the portal login. A clinician who left for a competing practice was removed from the EHR but not from the shared email account or the file sync folder. None of that requires malice to become a breach, and all of it is discoverable in an audit log if anyone looks.

Build a written offboarding list keyed to your vendor inventory: every system, who disables it, and by when. Run it the day someone leaves, not the week after.

Security awareness and training at 45 CFR 164.308(a)(5) applies to all workforce members including management, and the sanction policy at 45 CFR 164.308(a)(1)(ii)(C) is Required. A solo practitioner still has to document training for themselves, which feels absurd until you are asked to produce it.

The requirement almost nobody meets: contingency planning

If there is one section of the Security Rule that small practices skip entirely, regardless of how long they have been open, it is 45 CFR 164.308(a)(7). Three of its five implementation specifications are Required:

A data backup plan, to create and maintain retrievable exact copies of ePHI. A disaster recovery plan, to restore any loss of data. An emergency mode operation plan, to continue critical processes while protecting ePHI security during an emergency.

Testing and revision procedures and applications and data criticality analysis are Addressable, which still means assess and document.

Ransomware is the reason this section has teeth. A small practice with a cloud EHR has partially outsourced the problem, but only partially, and only if the vendor's actual backup and recovery commitments are in the contract rather than the sales deck. A practice keeping records locally, or keeping anything locally that is not also in the EHR, needs a backup that is separate from the machine it protects and that has been restored from at least once. A backup nobody has tested is a theory.

What you need to know exists on the Privacy Rule side

This is the material that is genuinely clinical and legal rather than technical. It is out of scope for an IT vendor to advise you on, and you should work through it with your professional association, licensing board, or counsel. But you should know it is coming.

Notice of Privacy Practices. 45 CFR 164.520 requires providing patients with a notice describing how you use and disclose PHI, their rights, and how to complain.

Right of access. Patients can inspect and obtain copies of PHI in the designated record set. You must act on a request within 30 days under 45 CFR 164.524(b)(2)(i), with one possible 30 day extension on written notice. Fees are limited to reasonable, cost based amounts, and you cannot bill for time spent searching for or retrieving records. Failure to respond to access requests is one of the most common sources of OCR complaints.

Psychotherapy notes. 45 CFR 164.501 defines these as notes recorded by a mental health professional documenting or analyzing the contents of a counseling session and separated from the rest of the individual's medical record. They exclude medication prescription and monitoring, session start and stop times, modalities and frequencies of treatment, clinical test results, and summaries of diagnosis, functional status, treatment plan, symptoms, prognosis, and progress. Almost any use or disclosure requires a specific authorization under 45 CFR 164.508(a)(2), and they are excluded from the right of access under 45 CFR 164.524(a)(1)(i).

There is a real IT question buried in that definition, and it is the one behavioral health practices most often get wrong. Separation from the medical record is part of the definition, not a best practice layered on top. So: does your EHR actually implement a separate psychotherapy notes container with its own access control, or does it give you a text field that happens to be labeled that way inside the same chart? If you cannot answer that, ask the vendor directly and get the answer in writing. A naming convention is not separation.

Minimum necessary, disclosures to family and others involved in care under 45 CFR 164.510(b), and authorization requirements at 45 CFR 164.508 all warrant real study. HHS has published guidance specific to mental health situations that is worth reading.

42 CFR Part 2 imposes additional confidentiality requirements on federally assisted substance use disorder programs. Read that phrase carefully, because it is narrower than it sounds and private practitioners get it wrong in both directions.

Part 2 attaches only when two separate tests are both met. You must be federally assisted, defined at 42 CFR 2.12(b), which covers a broad range including Medicare or Medicaid participation, federal funding, tax exempt status, and DEA registration related to substance use disorder treatment. Most clinicians who bill any federal program clear that bar without thinking about it. And you must be a program as defined at 42 CFR 2.11, meaning you hold yourself out as providing, and do provide, substance use disorder diagnosis, treatment, or referral for treatment. Holding yourself out means any activity that would lead someone to reasonably conclude you offer those services, which includes how you describe yourself in a directory listing or on your website.

Meeting one test without the other does not make you a Part 2 program. A therapist who accepts Medicaid and treats substance use as one presenting concern among many, without advertising SUD services, is generally outside it. A clinician who lists themselves as a substance use specialist and bills Medicare is generally inside it. 42 CFR 2.12(a) names private practitioners explicitly as a category that can be covered, so solo status is not a defense.

The February 2024 final rule aligning Part 2 more closely with HIPAA carried a compliance date of February 16, 2026, which has now passed. If there is any chance this applies, make the determination deliberately rather than by assumption in either direction.

State law is often stricter. HIPAA is a floor. Many states impose tighter mental health confidentiality requirements, and some impose their own breach notification timelines. Follow the more protective rule.

Breach notification, and why logs matter

If a breach of unsecured PHI occurs, you must notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery, under 45 CFR 164.404(b).

The reporting obligations to HHS and to the media are separate and frequently conflated. Under 45 CFR 164.408(b), breaches involving 500 or more individuals are reported to the Secretary contemporaneously with individual notice. Under 45 CFR 164.408(c), breaches involving fewer than 500 individuals are logged and reported not later than 60 days after the end of the calendar year in which they were discovered. Media notification under 45 CFR 164.406(a) is a distinct obligation triggered by a breach involving more than 500 residents of a single state or jurisdiction.

For a small practice these thresholds mean most incidents fall into the annual reporting bucket. That does not make them optional, and it does not remove the individual notification clock.

The operational point for a practice with no IT: you cannot determine whether an incident is a reportable breach if you have no way to know what was accessed. The risk assessment that determines breach status depends on facts, and facts come from logs. This is the practical argument for the audit controls requirement that looks like paperwork until the day you need it.

Documentation, and how long you keep it

45 CFR 164.316 requires written policies and procedures and written records of required actions and assessments. Under 45 CFR 164.316(b)(2)(i), those must be retained for six years from creation or from the date they were last in effect, whichever is later. Training records, risk analyses, BAAs, incident documentation, and the reasoning behind your Addressable decisions all belong in that file.

A small practice can meet this with a folder and discipline. What it cannot meet it with is nothing.

What may be coming

OCR published a proposed overhaul of the Security Rule in the Federal Register on January 6, 2025. Among other changes, it would eliminate the Addressable designation entirely, making every implementation specification Required, and would mandate encryption and multi factor authentication.

That rule has not been finalized. The comment period closed March 7, 2025, a target of May 2026 for final action passed without publication, and the Unified Agenda now shows a July 2027 target. More than a hundred hospital and provider organizations have asked HHS to withdraw or narrow it. It may be finalized as written, changed substantially, delayed again, or dropped.

Treat it as a signal about direction rather than a deadline. A practice that turns on disk encryption and MFA today is making a defensible Addressable decision under the current rule and will not have to scramble if the proposal lands.

A reasonable order of operations

Whether you are opening next month or auditing a practice that has been running since 2011, the sequence that produces the most protection per dollar looks roughly the same.

Confirm whether you are a covered entity, and reconfirm if your billing arrangement has changed. Inventory every device, application, and vendor that touches client information, including the ones you stopped using but never decommissioned. Get BAAs signed, or replace the vendors that will not sign one, and verify that the agreements you already have still match the vendors you actually use. Separate user accounts and turn on full disk encryption and screen locks on every device, which costs nothing but time. Audit who currently has access to each system and remove anyone who should not. Set up a backup that is not on the same machine as the data, and restore from it once to prove it works. Run the HHS SRA Tool and keep the report. Write down the policies that describe what you actually do. Document your training, including your own. Then, when the foundation exists, buy the tools that fill the gaps the risk analysis identified.

A new practice works that list top to bottom. An established practice usually finds the first two steps take the longest, because the inventory turns up things nobody remembered. That is the point of doing it.

Encrypted email is often on that list. It is rarely at the top of it.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

45 CFR Part 164, Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164

45 CFR 164.306, Security standards: General rules: https://www.ecfr.gov/current/title-45/section-164.306

45 CFR 164.308, Administrative safeguards: https://www.ecfr.gov/current/title-45/section-164.308

45 CFR 164.312, Technical safeguards: https://www.ecfr.gov/current/title-45/section-164.312

45 CFR 164.316, Policies and procedures and documentation requirements: https://www.ecfr.gov/current/title-45/section-164.316

45 CFR 164.404, 164.406, and 164.408, Breach notification: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D

45 CFR 164.501, Definitions, including psychotherapy notes: https://www.ecfr.gov/current/title-45/section-164.501

45 CFR 164.508, Uses and disclosures for which an authorization is required: https://www.ecfr.gov/current/title-45/section-164.508

45 CFR 164.524, Access of individuals to protected health information: https://www.ecfr.gov/current/title-45/section-164.524

45 CFR 160.103, Definitions, including covered entity and business associate: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103

45 CFR Part 162, Administrative requirements and standard transactions: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162

HHS, Covered Entities and Business Associates: https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html

HHS FAQ 513, Does the HIPAA Privacy Rule apply to an elementary or secondary school: https://www.hhs.gov/guidance/document/faq-513-does-hipaa-privacy-rule-apply-elementary-or-secondary-school

HHS, Guidance on HIPAA and Cloud Computing: https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html

42 CFR 2.11, Definitions, including program: https://www.ecfr.gov/current/title-42/chapter-I/subchapter-A/part-2/subpart-B/section-2.11

42 CFR 2.12, Applicability, including federally assisted: https://www.ecfr.gov/current/title-42/chapter-I/subchapter-A/part-2/subpart-B/section-2.12

HHS Security Risk Assessment Tool, ASTP/ONC: https://healthit.gov/privacy-security/security-risk-assessment-tool

HIPAA Security Rule Notice of Proposed Rulemaking, 90 FR 898, January 6, 2025: https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information

Google Workspace HIPAA compliance and business associate amendment, Google Workspace Admin Help: https://support.google.com/a/answer/3407054