HIPAA Security Rule: Technical Requirements
This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. HIPAA requirements and enforcement practices evolve, and you should consult with a qualified compliance professional about your specific situation.
The Security Rule is where IT lives when it comes to HIPAA. This regulation defines what technical controls you need to protect patient data, and it reads like it was written to be as vague as humanly possible. It doesn't say "use AES-256 encryption" or "deploy this specific firewall." Instead, it says things like "implement appropriate safeguards" and "ensure confidentiality, integrity, and availability." The vagueness is intentional—the regulation is technology-neutral because healthcare security needs vary enormously depending on organization size, infrastructure complexity, and risk profile. Your job is understanding what the regulation actually requires conceptually, then translating that into real controls that fit your specific environment.
Administrative Safeguards: The Foundation Nobody Talks About
The Security Rule breaks down into three categories of safeguards, and this is where many organizations get it wrong. They focus obsessively on technical controls—encryption, firewalls, intrusion detection—and neglect administrative safeguards, which are actually where compliance failures happen. Administrative safeguards are the policies, procedures, and governance that support a secure environment. This includes workforce security, authorization, supervision and monitoring, and incident response procedures.
Workforce security means you have to manage access based on the principle of least privilege. People should have access only to the patient data they need to do their job. A billing clerk doesn't need access to clinical notes. A clinician in oncology doesn't need access to neurology records. The regulation requires documented job descriptions and role-based access policies that tie system access directly to job function. In practice, this means your systems need to support granular role-based access control, and you need to maintain documentation showing that access is aligned with documented job responsibilities. Too many organizations grant broad access and then hope nobody misuses it. HIPAA requires you to prevent misuse before it happens.
Authorization means you define what each role is allowed to do. Who can view records? Who can edit them? Who can delete them? Who can run reports? Who can export data? This is a policy question that's supported by technical access controls. Many organizations fail here because they treat access control as purely a technical problem—grant access in the system—without the administrative foundation—document what access is appropriate for each role. The regulation requires both. You need policies saying "clinical staff in the emergency department can view, but not edit, records of patients currently under their care." Then you need systems that enforce that policy.
Supervision means you're actively managing who has access over time. New employees get access for their role. Employees who change roles get access updated. Employees who leave get access removed immediately. This seems obvious but organizations fail audits regularly because employees who left six months ago still have active system access to patient data. Workforce access reviews—regularly checking who has access and verifying it's still appropriate—are a required administrative safeguard that gets missed constantly. This is not a one-time task. It's ongoing.
Physical Safeguards: The Non-Digital Layer
Physical safeguards cover the non-digital security aspects: data center access controls, locked server rooms, visitor policies, workstation use, device management, and disposal of hardware and media containing patient data.
Data center and facility access means you have actual mechanisms to prevent unauthorized people from walking into the server room and stealing drives or equipment. This includes locks on doors, visitor logs, security badges for authorized personnel, and camera surveillance if the risk profile justifies it. It sounds obvious—healthcare organizations know patient data matters—but physical access controls are often overlooked because they're not automated and they don't integrate with your security tools. Someone actually has to enforce the policy, and enforcement requires discipline.
Workstation use and security means you have documented policies about where and how staff can access patient data, and those policies are actually enforced. Mobile workstations (laptops) should automatically lock after inactivity. Desktops in open clinic areas should have privacy screens so people can't read the monitor from nearby. Workstations shouldn't have default credentials. Shared workstations should require re-authentication between users so one clinician's login doesn't accidentally leave access open for the next person. These requirements are partly technical (auto-lock settings, screen configuration, password policies) and partly procedural (policies about where workstations can be used and what staff training requires).
Device and media disposal is another physical safeguard that gets neglected. When you decommission old servers, hard drives, or storage media, you can't just toss them in a dumpster. Hard drives still contain patient data even after you think you've deleted it. Data recovery tools can often retrieve files from drives that have been formatted or deleted. The regulation requires that media and hardware be destroyed in a way that makes data unrecoverable—certified destruction services, secure wiping using Department of Defense standards, or physical destruction. Documentation proving the destruction must be maintained.
Technical Safeguards: Encryption, Audit Logs, System Hardening
Technical safeguards are the controls that actually protect patient data from unauthorized access. These include access controls using authentication and authorization, encryption of data at rest and in transit, audit logging of access and changes, and system integrity controls.
Access control starts with authentication—verifying that someone is who they claim to be. This means strong passwords or passphrases, but in modern healthcare the requirement effectively means multi-factor authentication. The regulation doesn't explicitly mandate MFA, but "appropriate safeguards" in the context of modern threats means that if you're not using MFA you're taking unreasonable risk. Auditors will question your reasoning if MFA isn't implemented. MFA prevents credential theft from being an automatic win for attackers. If someone steals a password but doesn't have the second factor, access is blocked.
Encryption is required for data both at rest (stored on disk or in databases) and in transit (moving across the network). Data at rest includes databases, file storage, backups, archive systems, and even old hard drives waiting to be destroyed. Encryption in transit includes TLS for web-based systems, VPNs for remote access, and encrypted protocols for any data moving across networks. The regulation is one of the few places where it's actually specific about what's required: unencrypted patient data moving across networks or sitting in storage is not acceptable. This is a hard requirement with little ambiguity.
Audit logging means you're recording access to patient data and security events systematically. Who logged into systems? When? What data did they access? What changes did they make? All of this needs to be logged. But logging alone isn't enough. The logs need to be actively monitored. If you're collecting gigabytes of logs every day but nobody's looking at them, you're not getting the security value. Audit logs need to be reviewed regularly to detect suspicious activity, unauthorized access, or violations of policy. Many organizations maintain logs for compliance purposes but never actually review them for security signals.
System hardening covers a range of practices: disabling unnecessary services on systems, keeping systems patched and current, disabling default credentials, configuring systems to deny access by default and grant access only where needed, managing administrative credentials securely, and using vulnerability scanning to identify missing patches or misconfigurations. A system running outdated software with known vulnerabilities is not compliant with the Security Rule, regardless of other controls in place. Vulnerability management is continuous, not a one-time effort.
Risk Assessment as the Mandatory Foundation
This is the critical starting point that many organizations skip or do superficially: HIPAA requires a documented risk assessment before you can rationally select controls. You can't just implement a checklist of generic controls and declare compliance. You have to understand your specific risks and select controls that address those risks. The regulation requires documentation of your risk assessment so auditors can evaluate whether your control selection makes sense.
A proper risk assessment identifies all systems that process, store, or transmit patient data. For each system, it identifies threats (unauthorized access, data loss, system failure, malicious insiders, ransomware, etc.). For each threat, it evaluates the likelihood that it will occur and the potential impact if it does. Then it evaluates what controls you currently have in place and determines whether the remaining risk is acceptable. If not, it identifies additional controls needed and prioritizes them based on risk.
This process must be documented thoroughly. You can't just claim "we have good controls." You have to show the reasoning: "We identified a threat of unauthorized access to the EHR database. We evaluated the likelihood as medium (insider threats happen, though not frequently) and impact as high (patient data exposure creates significant liability). This makes the overall risk high. Our current controls are role-based access control and standard password authentication. We determined the residual risk is still high because we lack encryption at rest (data could be accessed if someone steals the physical drive) and multi-factor authentication (stolen passwords would grant full access). We're implementing encryption at rest immediately and MFA for all user access within 90 days." That's the level of reasoning auditors expect.
Organizations that skip the risk assessment tend to either over-implement controls—spending money and effort on things they don't actually need—or under-implement controls, leaving gaps that fail audits. Risk assessment isn't busywork. It's the tool that ensures you're spending effort and money on what actually matters for your environment.
Flexibility: HIPAA Doesn't Mandate Specific Technologies
This is important to understand because it sometimes creates confusion. The regulation is intentionally flexible about HOW controls are implemented. It doesn't say you must use Okta for authentication or Splunk for logging or any specific vendor. Different organizations will implement these requirements in completely different ways depending on their size, complexity, and existing infrastructure.
A small clinic with 15 employees might implement MFA through Microsoft Authenticator in Azure AD. A large health system with 50,000 employees might use a dedicated identity and access management platform like PingIdentity or Okta. Both are compliant with the Security Rule even though their solutions are completely different. The regulation requires MFA (effectively), but doesn't mandate how you implement it.
This flexibility is both a blessing and a burden. It's a blessing because you can choose solutions that fit your environment and budget. It's a burden because you can't just follow a checklist. You have to understand your environment and make reasoned decisions about what controls are appropriate for your risks. This is where the risk assessment becomes critical—it justifies your control choices. If an auditor questions your decision not to implement a particular control, your risk assessment should explain why you determined that control wasn't necessary for your risk profile.
Common Ways Organizations Fail HIPAA Audits
Most organizations fail HIPAA audits not because they lack the technology but because they lack the documentation and administration. They have encryption, but no documented policy about what should be encrypted. They have audit logs, but nobody's reviewing them. They have access controls, but they've never done a formal review of who has access to what. They have incident procedures, but nobody's trained on them. They have security policies, but they're three years old and don't match what actually happens in the organization.
The other common failure is missing administrative controls while assuming technical controls alone are sufficient. You can have the best encryption and access controls in the world, but if one employee writes passwords on sticky notes and leaves them on their desk, the controls are useless. If clinicians know they can share login credentials with colleagues, your access controls fail. HIPAA requires both technical controls and the procedures and training to make those controls actually work.
Finally, organizations fail because they don't understand that compliance is an ongoing program, not a project that ends. After an initial audit, some organizations assume they're done and move on. But the Security Rule requires annual risk assessments, regular reviews and updates of policies, regular training (at least annually), regular vulnerability scanning, and continuous monitoring for new threats. Your threat landscape changes, your technology changes, your staffing changes. Your controls need to evolve with all of that. Compliance is a continuous cycle.
Closing
The Security Rule requires starting with a documented risk assessment, then implementing appropriate administrative, physical, and technical controls aligned to your identified risks. You don't need to be perfect. You need to be reasonable and documented. The regulation is flexible on how controls are implemented, which means you can tailor your approach to your specific environment. But that flexibility comes with a burden: you have to understand your risks, make justified control decisions, and document everything. Most organizations fail on documentation and maintenance of controls, not on the initial implementation. They build the machine right but then don't maintain it or prove they've maintained it.
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects information about HIPAA as of its publication date. Regulations, penalties, and requirements evolve—consult a qualified compliance professional for guidance specific to your organization.