The HIPAA Security Rule establishes a national set of standards for protecting electronic protected health information (ePHI). Published by the U.S. Department of Health and Human Services (HHS) under the Health Insurance Portability and Accountability Act of 1996, the Security Rule defines the administrative, physical, and technical safeguards that covered entities and business associates must implement to ensure the confidentiality, integrity, and availability of ePHI.
Unlike many compliance frameworks that prescribe specific technologies, the Security Rule is deliberately scalable and technology-neutral. It recognises that a two-person medical practice and a multinational health system face fundamentally different risk profiles, and it allows organisations to adopt protections proportionate to their size, complexity, and the nature of the ePHI they handle. This flexibility, however, does not reduce the obligation — every covered entity and business associate must meet the rule’s requirements, regardless of scale.
Scope: electronic protected health information
A critical distinction separates the Security Rule from the broader HIPAA Privacy Rule. The Privacy Rule governs the use and disclosure of all protected health information (PHI) in any form — paper records, verbal communications, and electronic data. The Security Rule applies exclusively to ePHI: individually identifiable health information that is created, received, stored, or transmitted in electronic form.
This scope has expanded significantly since the rule’s original publication in 2003. The shift from paper-based records to electronic health record (EHR) systems, cloud-hosted applications, and mobile health platforms means that the vast majority of PHI now falls under the Security Rule’s jurisdiction. For technology companies building healthcare applications, virtually all patient data they handle qualifies as ePHI.
ePHI includes any of the 18 HIPAA identifiers (name, date of birth, address, Social Security number, medical record numbers, and others) when combined with health information and stored or transmitted electronically. It encompasses data at rest (stored on servers, databases, or devices), data in transit (transmitted over networks), and data in use (actively being processed by applications).
Relationship to the Privacy Rule
The Security Rule and Privacy Rule are complementary but distinct. The Privacy Rule establishes the rights of individuals regarding their health information and sets boundaries on how covered entities may use and disclose PHI. The Security Rule operationalises those protections for electronic data by specifying the safeguards necessary to enforce them.
Where the Privacy Rule says “limit access to PHI to authorised individuals,” the Security Rule specifies that this requires unique user identification, role-based access controls, automatic logoff, and encryption. Where the Privacy Rule requires accounting for disclosures, the Security Rule mandates audit controls that log access to ePHI.
Organisations cannot comply with the Security Rule in isolation. Security controls must align with the organisation’s Privacy Rule policies, and vice versa. A security programme that technically restricts access but does not align with the minimum necessary standard, for example, fails to satisfy either rule.
The three safeguard categories
The Security Rule organises its requirements into three categories of safeguards: administrative, physical, and technical. Each category contains standards, and each standard contains implementation specifications that are designated as either required or addressable.
Administrative safeguards
Administrative safeguards account for more than half of the Security Rule’s requirements and address the policies, procedures, and workforce management practices necessary to protect ePHI. They are frequently the area where organisations — particularly technology companies new to healthcare — have the most significant gaps.
| Standard | Key implementation specifications | Type |
|---|---|---|
| Security management process | Risk analysis, risk management, sanction policy, information system activity review | Required |
| Assigned security responsibility | Designation of a security official | Required |
| Workforce security | Authorisation and supervision procedures, workforce clearance, termination procedures | Addressable |
| Information access management | Access authorisation, access establishment and modification | Addressable |
| Security awareness and training | Security reminders, protection from malicious software, log-in monitoring, password management | Addressable |
| Security incident procedures | Response and reporting procedures | Required |
| Contingency planning | Data backup plan, disaster recovery plan, emergency mode operation plan, testing and revision | Required (backup, recovery, emergency mode); Addressable (testing, applications and data criticality analysis) |
| Evaluation | Periodic technical and non-technical evaluation | Required |
| Business associate contracts | Written contracts or arrangements with business associates | Required |
Risk analysis is the foundation of every HIPAA security programme. The Security Rule requires organisations to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. This is not a one-time exercise — it must be reviewed and updated as the organisation’s environment changes. Common failures include conducting only a checklist-based assessment rather than a genuine analysis of threats and vulnerabilities, or limiting the scope to certain systems whilst ignoring others that store or transmit ePHI.
Workforce security requires organisations to implement procedures for authorising access to ePHI and ensuring that workforce members who should not have access do not obtain it. This includes background checks where appropriate, role-based access provisioning, and — critically — timely termination of access when employees leave or change roles. The termination procedures specification is addressable, but organisations that fail to revoke access promptly face significant enforcement risk.
Security awareness and training must be provided to all workforce members, including management. Training should cover recognising phishing and social engineering attacks, proper handling of ePHI, password management, and the organisation’s security policies. Training must be documented and refreshed periodically — annual training is standard practice, with additional training when policies change or incidents occur.
Contingency planning requires organisations to establish and implement procedures for responding to emergencies and disasters that damage systems containing ePHI. This includes maintaining retrievable exact copies of ePHI (data backup), procedures for restoring lost data (disaster recovery), and procedures for operating critical business processes during and immediately after a crisis (emergency mode operation). Contingency plans must be tested regularly — an untested plan provides false assurance.
Evaluation requires organisations to perform periodic assessments of their security policies and procedures to determine whether they continue to meet the requirements of the Security Rule. This includes both technical evaluation (vulnerability scanning, penetration testing, configuration review) and non-technical evaluation (policy review, process assessment, gap analysis).
Physical safeguards
Physical safeguards protect the physical systems, buildings, and equipment that store, process, or transmit ePHI. For organisations operating primarily in the cloud, physical safeguards still apply — they shift to cover workstations, mobile devices, and the physical security of any on-premises infrastructure.
| Standard | Key implementation specifications | Type |
|---|---|---|
| Facility access controls | Contingency operations, facility security plan, access control and validation procedures, maintenance records | Addressable |
| Workstation use | Policies for proper workstation use | Required |
| Workstation security | Physical safeguards for workstation access | Required |
| Device and media controls | Disposal, media re-use, accountability, data backup and storage | Required (disposal, media re-use); Addressable (accountability, data backup and storage) |
Facility access controls govern who may physically access locations where ePHI is stored or processed. For technology companies, this extends beyond traditional server rooms to securing office spaces where development occurs on systems containing ePHI, and ensuring that co-working or remote work environments do not expose ePHI to unauthorised observation.
Workstation use and security require organisations to define appropriate use policies for all devices used to access ePHI and to implement physical safeguards restricting access to authorised users — including requirements for private workspaces, screen locks, and restrictions on shared devices in remote environments.
Device and media controls address the lifecycle management of hardware and electronic media containing ePHI. Disposal procedures must render ePHI unrecoverable before devices are discarded or repurposed. Organisations must maintain records of hardware and media movements throughout their lifecycle.
Technical safeguards
Technical safeguards are the technology-based controls that protect ePHI and manage access to it. For technology companies building healthcare applications, this category maps most directly to engineering and infrastructure practices.
| Standard | Key implementation specifications | Type |
|---|---|---|
| Access control | Unique user identification, emergency access procedure, automatic logoff, encryption and decryption | Required (unique user ID, emergency access); Addressable (automatic logoff, encryption) |
| Audit controls | Hardware, software, and procedural mechanisms to record and examine access to ePHI | Required |
| Integrity | Mechanism to authenticate ePHI, protect against improper alteration or destruction | Addressable |
| Person or entity authentication | Procedures to verify identity before granting access | Required |
| Transmission security | Integrity controls, encryption for data in transit | Addressable |
Access control requires that each user accessing ePHI have a unique identifier — shared accounts are not permitted. Organisations must implement role-based access controls that enforce the minimum necessary standard, ensuring users can only access the ePHI required for their job function. Emergency access procedures must provide a mechanism for obtaining necessary ePHI during emergencies, even when normal access controls might be disrupted. Whilst encryption at rest is technically an addressable specification, the Office for Civil Rights (OCR) has made clear through enforcement actions that encryption is the expected standard — organisations that choose not to encrypt ePHI at rest must document a compelling justification and implement an equivalent alternative measure.
Audit controls require organisations to implement mechanisms that record and examine activity in information systems that contain or use ePHI. This includes logging user access, modifications to ePHI, authentication attempts, and administrative actions. Logs must be reviewed regularly — generating logs without reviewing them does not satisfy the requirement. Effective audit control programmes define what is logged, how long logs are retained, who reviews them, and what constitutes a reviewable event.
Integrity controls require mechanisms to protect ePHI from improper alteration or destruction. This includes checksums, digital signatures, or other methods to verify that ePHI has not been modified without authorisation. In practice, this means implementing version control for clinical data, database integrity checks, and tamper-detection mechanisms for stored records.
Transmission security requires organisations to protect ePHI when it is transmitted over electronic communications networks. The encryption specification is addressable, but — as with encryption at rest — TLS/SSL for data in transit is the de facto standard. Organisations transmitting ePHI over the open internet without encryption face near-certain enforcement action in the event of a breach. Integrity controls for transmission (such as message authentication codes) ensure that ePHI is not improperly modified during transit.
Required versus addressable specifications
The distinction between required and addressable implementation specifications is one of the most commonly misunderstood aspects of the Security Rule. Addressable does not mean optional.
When a specification is designated as addressable, the organisation must complete a three-step analysis:
- Assess whether the specification is a reasonable and appropriate safeguard in the organisation’s environment, considering its risk analysis, current security measures, and the cost of implementation.
- Implement the specification if the assessment determines it is reasonable and appropriate.
- Document the decision. If the specification is not implemented, the organisation must document why it is not reasonable and appropriate and what equivalent alternative measure has been implemented to achieve the same protection objective.
Organisations that simply skip addressable specifications without conducting this documented analysis are in violation of the Security Rule. The OCR has consistently enforced this position in settlement agreements and corrective action plans.
Implementation guidance by category
Administrative safeguard implementation
Begin with a comprehensive risk analysis that identifies every system, application, and data flow involving ePHI. Map threats and vulnerabilities, assess likelihood and impact, and use the results to prioritise remediation and inform policy development.
Designate a HIPAA Security Officer with clear authority over the security programme. Develop written policies covering access management, incident response, contingency planning, and workforce security. Establish a sanction policy and apply it consistently. Implement and regularly test a security incident response plan with defined reporting channels, response roles, and breach notification procedures.
Physical safeguard implementation
Conduct a physical security assessment of all locations where ePHI is accessed or stored. Implement appropriate access controls for each location, from badge readers for data centres to privacy screens for shared workspaces. Develop a workstation use policy specifying approved devices, required configurations (screen locks, full-disk encryption, endpoint protection), and remote work requirements. Deploy mobile device management (MDM) to enforce encryption and remote wipe capability.
Establish media disposal procedures requiring cryptographic erasure or physical destruction before disposal, and maintain an inventory of all devices and media containing ePHI throughout their lifecycle.
Technical safeguard implementation
Implement identity and access management (IAM) controls enforcing unique user identification, multi-factor authentication, and role-based access with least privilege. Automate provisioning and deprovisioning to prevent orphaned accounts.
Deploy comprehensive logging and monitoring across all ePHI systems, centralised in a SIEM platform with defined alerting rules and a regular review cadence. Retain logs for a minimum of six years to align with HIPAA retention requirements.
Encrypt ePHI at rest using AES-256 or equivalent, and in transit using TLS 1.2 or higher. Manage encryption keys through a dedicated key management service with rotation policies and separation of duties.
Common Security Rule violations
Enforcement actions by the OCR reveal consistent patterns of non-compliance. The following violations appear repeatedly in settlement agreements and corrective action plans:
- Failure to conduct a risk analysis. This is the single most common violation cited in OCR enforcement actions. Organisations either fail to perform a risk analysis entirely, conduct an incomplete analysis that omits systems or data flows, or fail to update the analysis as their environment changes.
- Lack of encryption. Whilst encryption at rest is technically addressable, the OCR has imposed significant penalties on organisations that failed to encrypt ePHI on portable devices and servers without documenting a valid alternative safeguard.
- Insufficient access controls. Failing to implement role-based access, permitting shared user accounts, and not revoking access for terminated employees are recurrent findings.
- Missing or inadequate business associate agreements. Covered entities that share ePHI with vendors without executing compliant business associate agreements face enforcement action, regardless of whether a breach occurs.
- Failure to implement audit controls or review audit logs. Generating logs without establishing procedures for regular review is a common deficiency, as is failing to log access to ePHI at a granular level.
- Inadequate contingency planning. Organisations that lack tested backup and disaster recovery procedures — or that have plans but have never tested them — are consistently cited in enforcement actions.
How technology companies meet Security Rule requirements
Technology companies building healthcare applications or providing services to covered entities face distinct challenges in meeting the Security Rule. Unlike traditional healthcare organisations, their ePHI exposure is often embedded within complex, multi-tenant cloud architectures.
Shared responsibility models require technology companies to clearly delineate which Security Rule obligations are met by their infrastructure provider (AWS, Azure, GCP) and which remain their responsibility. Infrastructure providers typically address physical safeguards for data centres, but the application layer — access controls, audit logging, encryption key management, and data integrity — remains the technology company’s obligation.
DevSecOps integration is essential. Security controls must be embedded in the software development lifecycle through automated security testing in CI/CD pipelines, infrastructure-as-code with security baselines, container scanning, and dependency vulnerability management.
Business associate agreements must be executed with every subprocessor that handles ePHI, with a current inventory maintained and Security Rule requirements flowed down through each agreement.
Multi-tenant architecture requires strict data isolation between tenants through logical separation, tenant-specific encryption keys, and access controls that prevent cross-tenant data access. Audit controls must support tenant-specific access logs for covered entities’ own compliance needs.
Continuous compliance monitoring replaces the traditional point-in-time assessment model. Automated control monitoring that continuously validates encryption status, access control configurations, logging coverage, and vulnerability posture provides real-time evidence for auditors and customer due diligence requests.
The Security Rule’s technology-neutral, risk-based approach adapts well to modern cloud architectures, but that adaptability carries a responsibility to document decisions, maintain evidence, and demonstrate that chosen safeguards genuinely protect ePHI in the organisation’s specific environment.