HIPAA Security Rule: Technical Requirements

Reviewed by Dr. Sarah Chen, HCISPP, CISA

The HIPAA Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect electronic PHI. The rule is technology-neutral — it mandates outcomes, not specific products. A documented risk assessment is the mandatory starting point that justifies every control selection. Administrative safeguards (workforce security, access management, training) account for the majority of audit failures. Technical safeguards require access controls, encryption, audit logging, and integrity verification. HHS OCR consistently finds that organizations fail not on technology implementation but on documentation and ongoing maintenance of controls.

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 most often. HHS enforcement data shows that administrative safeguard deficiencies, particularly inadequate risk analysis and insufficient access management, appear in the majority of resolution agreements. Administrative safeguards are the policies, procedures, and governance that support a secure environment.

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? Many organizations fail here because they treat access control as purely a technical problem — grant access in the system — without the administrative foundation of documenting what access is appropriate for each role. The regulation requires both.

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. 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 ongoing administrative discipline is what makes the physical safeguards meaningful rather than cosmetic.

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. 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 should automatically lock after inactivity. Desktops in open clinic areas should have privacy screens. Shared workstations should require re-authentication between users. 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, 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 appropriate standards, or physical destruction. Documentation proving the destruction must be maintained. Physical safeguards create the environmental conditions in which technical safeguards operate effectively.

Technical Safeguards: Encryption, Audit Logs, System Hardening

Technical safeguards are the controls that protect patient data from unauthorized access at the system level. 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. The regulation doesn't explicitly mandate multi-factor authentication, but "appropriate safeguards" in the context of modern threats effectively requires it. Single-factor authentication using passwords alone fails HIPAA audits routinely because the risk profile has changed dramatically. The Verizon 2023 DBIR found that stolen credentials were involved in approximately 50% of breaches across all industries, and healthcare is no exception. Auditors will question your reasoning if MFA isn't implemented.

Encryption is required for data both at rest and in transit. 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: 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. Many organizations maintain logs for compliance purposes but never actually review them for security signals — a common audit finding.

System hardening covers disabling unnecessary services, keeping systems patched and current, disabling default credentials, configuring systems to deny access by default, 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. These technical controls all trace back to the risk assessment that justifies their selection.

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. HHS resolution agreements cite inadequate or absent risk analysis more frequently than any other single deficiency — it appears in the majority of published enforcement actions.

A proper risk assessment identifies all systems that process, store, or transmit patient data. For each system, it identifies threats. For each threat, it evaluates likelihood and impact. Then it evaluates what controls you currently have in place and determines whether the remaining risk is acceptable. If not, it identifies additional controls 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 and impact as 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 and multi-factor authentication. 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 or under-implement them. The risk assessment ensures you're spending effort and money on what actually matters for your environment, but the regulation's flexibility means you have latitude in how you get there.

Flexibility: HIPAA Doesn't Mandate Specific Technologies

The regulation is intentionally flexible about how controls are implemented. It doesn't mandate any specific vendor or product. Different organizations will implement requirements in completely different ways depending on their size, complexity, and existing infrastructure. A small clinic with 15 employees might implement MFA through a cloud identity provider. A large health system with 50,000 employees might use a dedicated identity and access management platform. Both are compliant even though their solutions are completely different.

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. 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. Understanding this flexibility also illuminates why organizations fail audits despite having technology in place.

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 work.

Organizations also fail because they don't understand that compliance is an ongoing program, not a project that ends. 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.

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.

Frequently Asked Questions

Does HIPAA require multi-factor authentication?
The Security Rule does not explicitly mandate MFA. It requires "appropriate" authentication safeguards based on risk. In practice, given the current threat landscape, single-factor authentication for systems containing ePHI fails audits routinely. HHS guidance and enforcement actions treat MFA as the expected baseline for any system accessible from external networks. Implementing MFA is the defensible position.

What encryption standard does HIPAA require?
HIPAA does not specify an encryption algorithm. HHS guidance references NIST Special Publications 800-111 (storage) and 800-52 (TLS). AES-128 or AES-256 for data at rest and TLS 1.2 or higher for data in transit are the de facto standards that satisfy auditors. Using encryption that meets these NIST standards also qualifies for Safe Harbor under the Breach Notification Rule.

How often must audit logs be reviewed?
The Security Rule requires "regular review" of audit logs but does not specify a frequency. HHS enforcement actions have cited organizations that collected logs but never reviewed them. Best practice is daily or weekly automated alerting on anomalies with monthly manual review of access patterns. The frequency should be justified by your risk assessment and documented in your security policies.

What's the difference between required and addressable implementation specifications?
The Security Rule categorizes specifications as "required" (must implement) or "addressable" (must implement, implement an equivalent alternative, or document why neither is reasonable). Addressable does not mean optional. If you determine an addressable specification is not reasonable for your environment, you must document the rationale and implement a compensating control. HHS auditors scrutinize addressable specification decisions closely.

How long must we retain Security Rule documentation?
HIPAA requires retention of security policies, procedures, risk assessments, and related documentation for six years. This includes all versions of policies, evidence of control implementation, training records, incident response records, and risk assessment updates. Six-year retention applies regardless of whether the policy or procedure is still in effect.

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.