HIPAA Compliance for Law Firms: What Your Practice Needs to Know

HIPAA compliance involves more than technology. Law firms need to understand their obligations, their IT environment and how sensitive information is accessed, protected, backed up and managed.

Updated August 2026: I originally wrote this article after working with a small law firm that handled personal injury and workers' compensation matters and regularly worked with medical information. I decided to revisit it because HIPAA compliance for law firms is an area where there can be confusion about when HIPAA actually applies and what that means for the technology a firm uses to store and protect sensitive information.

A law firm does not automatically become subject to HIPAA simply because medical records or other health information are stored in its systems. Whether HIPAA applies depends on the firm's role, its relationship with a covered entity or Business Associate, why it receives the information, and what it is doing with that information.

That distinction matters because I do not want a law firm assuming it is a HIPAA Business Associate simply because it handles medical records, and I also do not want a firm that does have HIPAA obligations overlooking technical safeguards because everyone assumed the technology was already taken care of.

My role in that process also needs to be clear. I am an IT provider, not the person making the legal determination that a law firm is or is not a HIPAA Business Associate. If there is a question about whether HIPAA applies to a particular firm or client relationship, I want that determination made with the appropriate legal or compliance guidance. My job is to understand the technology environment, identify technical gaps, implement and document the appropriate safeguards, and make sure the systems I manage support the requirements the business has determined apply to it. The law firm that originally led me to write this article is a good example of why I think that distinction is so important, because once I started looking deeper into its technology, HIPAA was only one part of a much larger conversation about how the firm's information was being protected.

Does HIPAA Apply to Law Firms?

A law firm can be a HIPAA Business Associate, but the fact that an attorney possesses medical records does not make that determination by itself. Under HIPAA, a Business Associate generally performs certain functions or provides certain services to or for a covered entity when that work involves creating, receiving, maintaining, or transmitting Protected Health Information, commonly called PHI. Legal services are specifically recognized as one of the professional services that can create a Business Associate relationship when the necessary conditions are present. An attorney providing legal services to a health plan and accessing PHI as part of those services is one example.

That is different from saying that every personal injury, workers' compensation, employment, medical malpractice, or other law firm that receives medical information is automatically a HIPAA Business Associate. A law firm may possess highly sensitive medical information without that fact alone determining its status under HIPAA. The relationship between the parties, the reason the information is being provided, and the role the firm is performing all matter. If a firm does not meet the definition of a covered entity or Business Associate, HIPAA does not suddenly apply simply because health information happens to be in its possession.

That does not make the information any less sensitive. A law firm may still be responsible for confidential client information, medical records, case files, financial information, settlement information, attorney communications, and other data that deserves strong protection even when HIPAA is not the regulation driving those protections. This is why I think the first question should be “Does HIPAA apply to us, and why?” rather than immediately buying technology that someone has marketed as “HIPAA compliant.”

If the firm determines that it is functioning as a Business Associate, Business Associate Agreements become part of that conversation. HIPAA establishes requirements for written arrangements between covered entities and their Business Associates, and Business Associates can also have subcontractors that create, receive, maintain, or transmit PHI on their behalf. From the IT side, I can help identify the technology companies and service providers involved in storing, transmitting, backing up, or otherwise interacting with the firm's information. The legal determination about which relationships require a BAA and whether the agreements themselves are appropriate belongs with the people responsible for the firm's legal and compliance decisions.

What I Found When I Started Looking at This Law Firm's Technology

My involvement with this law firm did not begin with someone handing me a HIPAA checklist and asking me to configure a few settings. The attorney had concerns about the firm's technology, including email security and backup, and once I started reviewing the environment, what initially appeared to be a few individual problems expanded into a much larger IT Baseline Assessment and eventually a significant overhaul of the firm's technology.

One of the biggest concerns was the firm's shared data. Years of confidential client information and case files were stored on a PC that was also being used by an employee as their everyday workstation. Other employees relied on that computer to access the firm's shared files, and they were using shared credentials to do it. From the firm's perspective, this arrangement worked because employees could open the files they needed and the computer was running every day. From my perspective, I needed to understand what would happen if that computer failed, who could access the information, how activity could be traced back to an individual user, and whether the data was actually being protected the way the attorney thought it was.

The backup question became particularly important because the attorney was already concerned about whether his data was protected. During the Baseline Assessment, I discovered that the backup solution he believed was protecting the firm's information was not actually backing anything up. That meant years of confidential client and case information were sitting on an employee's everyday computer without the working backup protection the attorney believed he had. If something had happened to that workstation or its hard drive before we corrected the environment, the firm was at risk of losing years of information it depended on.

That experience is one reason I do not consider “we have a backup solution” a sufficient answer when I review a business environment. I want to know what is actually included in the backup, whether the jobs are completing successfully, whether failures are being noticed, and how we would restore the information if the business actually needed it. A backup product sitting in an environment and a verified recovery process are two very different things.

As part of the overhaul, I moved the firm's shared company files off the employee's everyday workstation and onto dedicated network storage. I moved away from the shared username and created individual user accounts with separate passwords, configured access around those identities, and enabled logging so there was better visibility into user activity. I also configured cloud backup for the firm's shared data and documented the recovery process. The purpose was not simply to replace one storage device with another. I wanted the business data separated from an employee's everyday workstation, identifiable users accessing the information, better visibility into what was happening, and an actual backup and recovery path for the information the firm depended on.

Why Shared Accounts and Logging Matter When HIPAA Applies

For a law firm that is actually subject to the HIPAA Security Rule, individual identity and auditability become particularly important. The current Security Rule includes a required unique user identification implementation specification, which means regulated entities need a unique name or number for identifying and tracking user identity. The Security Rule also requires audit controls capable of recording and examining activity in information systems that contain or use electronic Protected Health Information, or ePHI.

The practical reason for those requirements is something I can explain without turning it into compliance language. If five employees access sensitive files using the same username and I later need to determine who opened, changed, moved, or deleted something, a log showing activity from that shared account may only tell me that the shared account did it. It does not necessarily tell me which employee was sitting at the computer. When users have individual identities and the systems are configured to log meaningful activity, I have a much better starting point for understanding what happened.

That does not mean simply creating separate usernames makes an organization HIPAA compliant, and it does not mean every log that a product can generate has to be collected forever. The larger environment, risk analysis, systems containing ePHI, access requirements, monitoring processes, and applicable Security Rule requirements all matter. For the businesses I manage, I also look at logging from a practical IT perspective because I want enough visibility to troubleshoot problems and investigate suspicious activity even when HIPAA is not involved.

Microsoft 365 Does Not Make a Law Firm HIPAA Compliant

Microsoft 365 became another significant part of this firm's project, and this is an area where I think small business owners can easily misunderstand what they are buying. Microsoft offers services and contractual commitments that can support organizations with HIPAA obligations, including a Business Associate Agreement covering Microsoft's in scope services for customers that are covered entities or Business Associates. Microsoft is also very clear that having its BAA and using Microsoft services does not, by itself, make the customer's organization HIPAA compliant.

I think that distinction is important because it is very similar to what I see with Microsoft 365 security in general. A business may own Microsoft 365 Business Premium or another license that includes security and management capabilities, but purchasing the license does not mean those capabilities have been configured for the business. Someone still has to understand the environment, configure the appropriate controls, test them, document them, monitor what needs monitoring, and revisit the configuration as the business and Microsoft environment change.

That is why a Microsoft 365 Tenant Security Review is different from simply checking which licenses appear on the Microsoft bill. When I review a tenant, I want to understand what the business owns, what has actually been configured, who has access, how identities are protected, how devices are managed, what security policies are active, what third party applications have access, and whether the environment still makes sense for the business as it operates today.

For this law firm, the Microsoft work became substantial because the email security issue led me into a deeper investigation. I reviewed sign in activity and found that the attorney's email account had been compromised for several months. I also discovered that another mail server was being used to send email as the firm's domain. Addressing that required much more than turning on a single anti spoofing rule. I upgraded and cleaned up the Microsoft licensing as needed, strengthened authentication, disabled older email authentication methods such as POP and IMAP where they were not needed, configured DKIM and DMARC, set the firm's DMARC policy to p=reject, and implemented additional Microsoft Defender protections around domain and user impersonation.

I cover that investigation in much more detail in Microsoft 365 Email Security for Law Firms: How One Law Firm Got Spoofed and What I Did to Fix It. I do not want to duplicate the entire email story here because the important point for this article is what the experience showed about Microsoft 365 management. The firm already had Microsoft services when I arrived. What mattered was understanding how those services were configured and then doing the backend work necessary to build the security controls around the way the business actually operated.

Managed Computers Became Part of the Security Strategy

The computers also needed attention as the environment was rebuilt. As older PCs were replaced, I moved the new Windows computers into Microsoft Entra ID rather than continuing to build the environment around isolated local Windows accounts. I configured device management and compliance policies and then used Conditional Access as part of the access strategy. For this client, that included policies designed so that managed, compliant devices could be required when accessing the Microsoft web applications I was protecting, along with location based policies appropriate for the firm's environment.

This is another place where I separate the technology I chose to implement from a claim that HIPAA requires every law firm to use the exact same Microsoft configuration. Entra ID, Intune, Conditional Access, device compliance, location based controls, and the other Microsoft security tools I use can help me build a much more manageable environment, but the current HIPAA Security Rule is designed to be flexible and technology neutral. A regulated organization has to implement the safeguards and requirements that apply to it based on its environment and risks. HIPAA does not say every Business Associate must buy a particular Microsoft license or create the exact Conditional Access policies I created for this client.

For this law firm, however, moving toward centrally managed business identities and devices made sense as part of the larger environment I was building. I go much deeper into that part of the project in Microsoft Entra ID vs. Local Accounts: What an IT Baseline Assessment Revealed at a Law Firm. That project is a good example of why I separate owning technology from actually managing it. The firm's computers worked before I changed them, just as the shared files worked and Microsoft 365 worked. What the Baseline Assessment exposed was everything underneath that everyday functionality that needed attention.

I also configured Microsoft Defender protection on the Windows endpoints and made sure the files employees accessed through the network shares were included in that endpoint protection strategy. I want to be precise about what that means. Defender was protecting the Windows computers as users accessed and worked with files from the network storage. I am not saying Microsoft Defender was installed directly on the network storage device itself.

Security monitoring became part of the Microsoft work as well. I configured Microsoft security alerting and created a dedicated mailbox for those notifications so there was a central location for security alerts from the tenant. I do not consider a security control fully implemented simply because I turned it on. I also want to understand how I am going to know when that control detects something that needs attention and what happens after the alert arrives.

HIPAA Security Is Bigger Than Microsoft 365

For an organization that is actually subject to HIPAA, the Security Rule is much broader than Microsoft 365. The current rule establishes administrative, physical, and technical safeguards for ePHI and addresses areas such as risk analysis and risk management, workforce security, information access management, security incident procedures, contingency planning, access control, audit controls, authentication, transmission security, policies, procedures, and documentation. That is why I would be very cautious about any product or provider promising that one firewall, one Microsoft license, one backup product, or one security setting is going to make a business HIPAA compliant.

Risk analysis is particularly important because the organization first needs to understand where its ePHI exists and the risks surrounding it. If the business does not know where the information is stored, which systems create or transmit it, who has access to it, and what could reasonably threaten its confidentiality, integrity, or availability, it becomes very difficult to make meaningful decisions about the safeguards around it. The current Security Rule gives regulated entities flexibility in choosing reasonable and appropriate security measures based on factors such as their size, capabilities, technical infrastructure, costs, and the probability and criticality of risks to ePHI.

That flexibility is also why I distinguish formal HIPAA requirements from the security recommendations I make as an IT professional. I may strongly recommend MFA, phishing resistant authentication, Conditional Access, managed devices, stronger email authentication, network changes, or other controls because they make sense for a particular client's environment. I should not tell a business that HIPAA specifically requires my preferred Microsoft configuration unless the regulation actually establishes that requirement.

This distinction is especially important right now because HHS has proposed substantial changes to the HIPAA Security Rule. Those proposed changes include stronger and more specific cybersecurity requirements in areas such as multifactor authentication, encryption, network mapping, vulnerability scanning, penetration testing, incident response, backups, and other technical safeguards. As of August 2026, those changes remain proposed. HHS specifically states that the current Security Rule remains in effect while the rulemaking process continues. I think businesses should understand the direction HHS is moving, but I do not want to present proposed requirements as though they are already current law.

Backup, Recovery and Incident Response Need to Work Together

The attorney's original concern about backup remained important throughout this project because discovering that the existing solution was not actually protecting the firm's shared data changed the way I looked at the rest of the environment. When I configured the new backup approach for the firm's shared storage, I also documented how the data could be restored. A successful backup job tells me that another copy of the data exists. Recovery planning asks whether we can actually get that information back when the business needs it and whether we know how to do it.

For organizations subject to the HIPAA Security Rule, contingency planning includes requirements involving data backup, disaster recovery, and emergency operations. Security incident procedures are also required, including identifying and responding to suspected or known security incidents, mitigating harmful effects when appropriate, and documenting security incidents and their outcomes. I created an Incident Response Plan for this law firm as part of the work the firm needed, but I do not view an incident response plan as useful simply because a document with that title exists. The plan needs to reflect the actual organization, the people who may need to respond, the systems involved, and the environment the business is trying to protect.

From an IT management perspective, backup, recovery, and incident response become closely connected when something actually goes wrong. If an account is compromised, ransomware affects files, hardware fails, or important data disappears, the business may need to understand what happened, determine which systems or information were affected, contain the problem, review available logs, restore information, and return people to work. That is why I want those processes designed around the real environment rather than a collection of products and documents that nobody has ever tried to connect.

Documentation Became an Important Part of the Project

Once the implementation work was complete, I did not want the resulting environment to exist only in my head. I created a Microsoft 365 runbook documenting the environment and the policies I implemented. I included screenshots of the actual policy configurations, maintained version history as the environment changed, and used an understandable naming convention so it was easier to identify what a policy was intended to do. I also provided a network diagram and documented the recovery process for the firm's cloud backup solution.

For a regulated entity, documentation is also part of the HIPAA Security Rule. The current rule requires regulated entities to maintain required policies and procedures in written form and maintain written records of actions, activities, or assessments that the Security Rule requires to be documented. Required Security Rule documentation generally has to be retained for six years from the later of its creation date or the date when it last was in effect, and it has to be periodically reviewed and updated in response to environmental or organizational changes affecting the security of ePHI.

I am careful not to turn that requirement into a claim that every screenshot, naming convention, network diagram, or section of the Microsoft 365 runbook I created is specifically required by HIPAA. Some of that documentation is part of my approach to managing an IT environment well. Some of it can also support regulatory, contractual, insurance, or internal business requirements. I think the distinction matters because I want clients to know when I am implementing a formal requirement and when I am doing something because experience has shown me that it makes the environment easier to support, troubleshoot, recover, and manage.

The same thinking went into the physical network. I replaced network equipment, including the firewall and switch, and labeled the equipment so individual devices could be easily identified. If I am troubleshooting remotely and need someone onsite to reboot or reseat a particular device, I do not want an employee standing in front of several pieces of equipment trying to guess which one I mean. I also created the network diagram so there was a record of how the environment was structured. Those things may not be as interesting as Conditional Access or Defender, but they make a real difference when an environment needs to be supported over time.

I also configured emergency access accounts in the Microsoft tenant and protected those accounts with YubiKey security keys, with the appropriate keys provided to the client. That was part of my approach to making sure the business had an appropriate emergency path into an environment it owned. I may manage a client's Microsoft tenant, but I do not believe good IT management should leave the client completely dependent on me as the only possible path back into its own environment.

What Should a Law Firm Ask Its IT Provider About HIPAA?

If your law firm has determined that it is subject to HIPAA as a covered entity or Business Associate, I would not stop at asking an IT provider, “Are we HIPAA compliant?” That question is so broad that a simple yes does not tell the business owner much about what was actually reviewed, what controls are in place, what remains the responsibility of the firm, or what documentation exists to support the answer. I would rather see an owner or managing attorney ask specific questions that force everyone involved to understand how the technology actually works.

Some of the questions I would ask include:

• Where does our ePHI actually exist?

• Does every employee have an individual account?

• How is access approved, changed, and removed?

• Are the systems containing or using ePHI recording appropriate user activity?

• Who receives and reviews security alerts?

• How are our computers protected and managed?

• How is remote access controlled?

• What Microsoft 365 security policies are actually configured?

• Which outside vendors create, receive, maintain, or transmit ePHI on our behalf?

• Have the appropriate Business Associate Agreements been addressed?

• What information is actually included in our backups?

• How do we know the backups are completing successfully?

• How would we restore our data if we needed it tomorrow?

• Do we have documented procedures for responding to a security incident?

• Is the environment documented well enough that we know how it is configured?

• When was the organization's HIPAA risk analysis last reviewed?

A good IT provider should be able to explain the technical environment in language the business owner understands and provide documentation showing what has actually been implemented. The IT provider should also know where the boundary of the IT role ends. I can tell a client what I found technically, what I configured, what is being monitored, and what gaps still need attention. I should not give a blanket legal determination about the firm's regulatory status or tell an owner that one technology product has made the entire organization compliant.

HIPAA Compliance Is Bigger Than an IT Checklist

What I find most useful about this law firm's story is how ordinary the environment looked before I started examining it. Employees could use their computers, Microsoft 365 was working, the shared files were accessible, the network was running, and the attorney believed the firm's data was being backed up. From the perspective of someone trying to run a law practice every day, there was no obvious reason to know everything happening underneath those systems.

The IT Baseline Assessment changed that picture. The backup solution the attorney believed was protecting years of client and case information was not actually backing anything up. Shared files were dependent on an employee's everyday workstation. Employees were accessing those files using shared credentials. The Microsoft environment needed a deeper security review. The attorney's email account had been compromised. Another mail server was sending as the firm's domain. Computers needed a better management structure. Logging, monitoring, backup, recovery, emergency access, network infrastructure, and documentation all needed attention.

None of those findings meant that one product was going to solve everything, and that is probably the most important lesson I would give another small business owner reading this. Security and compliance work starts with understanding what you actually have. For an organization subject to HIPAA, the technology then needs to support the applicable Privacy, Security, and Breach Notification Rule obligations and the organization's risk management decisions. For a law firm that determines HIPAA does not apply, many of the same technical questions still matter because confidential client information and the ability to keep the business operating are important regardless of which regulation applies.

That is the role I want SNL Tech Services to play for the businesses I support. I can assess the IT environment, perform a Microsoft 365 Audit, identify and document technical gaps, implement the appropriate security controls, improve identity and device management, strengthen backup and recovery, improve logging and monitoring, and document the resulting environment. When legal or compliance requirements are involved, I can work alongside the appropriate specialists so the technical implementation supports the requirements they have identified.

If your law firm or professional services business is not sure what is actually happening inside its technology environment, SNL Tech Services Business IT Solutions can help establish that baseline and determine what technical work makes sense from there.

Frequently Asked Questions About HIPAA Compliance for Law Firms

Does HIPAA apply to every law firm that handles medical records?

No. Simply possessing medical records or other health information does not automatically make a law firm a HIPAA covered entity or Business Associate. A law firm can become a Business Associate when it provides certain services to or for a covered entity and those services involve PHI. The firm's role, relationship with the covered entity, and reason it receives or maintains the information all matter. If there is uncertainty about whether a particular firm or client relationship falls under HIPAA, that determination should involve the appropriate legal or compliance guidance.

Does Microsoft 365 make a law firm HIPAA compliant?

No. Microsoft provides a HIPAA Business Associate Agreement covering in scope services for qualifying covered entity and Business Associate customers, but Microsoft specifically states that using its services does not, by itself, achieve HIPAA compliance. The organization remains responsible for its own compliance program and for appropriately configuring and using the technology.

Are shared user accounts a HIPAA problem?

For organizations subject to the HIPAA Security Rule, unique user identification is a required implementation specification, and audit controls are required for systems containing or using ePHI. Shared credentials also create a practical accountability problem because activity associated with one common account may not identify the individual who performed it. This is why I generally prefer individual user identities even in environments where HIPAA does not apply.

Does HIPAA require MFA?

The current HIPAA Security Rule does not simply state that every regulated entity must implement the exact Microsoft MFA configuration I might recommend for a client. HHS has proposed changes that would make multifactor authentication an explicit requirement with limited exceptions, but as of August 2026 those changes remain proposed and the current Security Rule remains in effect. I may still strongly recommend MFA and stronger phishing resistant authentication based on the environment and risk, but I distinguish that security recommendation from a requirement that has not yet become final.

Does HIPAA require backups?

For regulated entities, the current HIPAA Security Rule's contingency planning requirements include a required data backup plan and a required disaster recovery plan. That means the organization needs procedures to create and maintain retrievable exact copies of ePHI and procedures to restore lost data. From my perspective as the IT provider, I also want to verify that backups are actually running and understand how the data will be restored rather than assuming the existence of backup software means the requirement has been effectively addressed.

Does HIPAA require an Incident Response Plan?

The current Security Rule requires regulated entities to implement policies and procedures addressing security incidents, including identifying and responding to suspected or known security incidents, mitigating harmful effects to the extent practicable, and documenting incidents and their outcomes. I created an Incident Response Plan for the law firm discussed in this article as part of its larger technology and security work, but the plan needs to reflect the actual organization rather than exist as a generic document nobody knows how to use.

Can an IT provider make a law firm HIPAA compliant?

An IT provider can play an important role in assessing the technical environment, identifying security gaps, configuring systems, implementing technical safeguards, improving backup and recovery, establishing monitoring, and documenting what has been implemented. HIPAA compliance is broader than IT, however, and also involves administrative, physical, contractual, policy, procedural, and legal considerations. My role is to handle the technical work and documentation within my scope and work alongside the firm's appropriate legal or compliance professionals when their expertise is needed.

ADDITIONAL RESOURCES

U.S. Department of Health and Human Services: Business Associates

Current HHS guidance explaining when a person or organization becomes a Business Associate, including legal services, subcontractors, Business Associate Agreements, and an example involving an attorney providing legal services to a health plan.HHS Business Associates Guidance

U.S. Department of Health and Human Services: Covered Entities and Business Associates

HHS guidance explaining which organizations are subject to HIPAA and clarifying that an organization that does not meet the definition of a covered entity or Business Associate is not required to comply with HIPAA simply because it possesses health information.HHS Covered Entities and Business Associates

U.S. Department of Health and Human Services: Summary of the HIPAA Security Rule

HHS's current August 2026 overview of the Security Rule currently in effect, including risk analysis, administrative safeguards, physical safeguards, technical safeguards, access controls, audit controls, authentication, contingency planning, and documentation requirements.HHS Summary of the HIPAA Security Rule

U.S. Department of Health and Human Services: Guidance on Risk Analysis

HHS guidance explaining the risk analysis requirement, documentation, risk management, and the need to revisit risk as the organization's environment changes.HHS Guidance on Risk Analysis

U.S. Department of Health and Human Services: HIPAA Audit Protocol

HHS audit guidance covering areas including unique user identification, audit controls, security management, incident response, contingency planning, backup, recovery, and documentation.HHS HIPAA Audit Protocol

U.S. Department of Health and Human Services: Business Associate Contracts

HHS guidance explaining the required elements of Business Associate Agreements between covered entities, Business Associates, and applicable Business Associate subcontractors.HHS Business Associate Contract Guidance

U.S. Department of Health and Human Services: Proposed HIPAA Security Rule Changes

HHS information about the proposed changes to strengthen the HIPAA Security Rule. The proposed rule includes stronger cybersecurity requirements, but HHS confirms that the current Security Rule remains in effect while rulemaking continues.HHS HIPAA Security Rule NPRM

Microsoft: HIPAA and HITECH Compliance

Microsoft's current guidance explaining its HIPAA Business Associate Agreement, in scope Microsoft services, and the important distinction that Microsoft's BAA and cloud services can support a customer's HIPAA compliance efforts but do not themselves make the customer HIPAA compliant.Microsoft HIPAA and HITECH Guidance