HIPAA and the Security Rule
The Health Insurance Portability and Accountability Act (HIPAA) was enacted in 1996. Its Security Rule, codified at 45 CFR Part 164, establishes the national standards for protecting electronic protected health information (ePHI). The rule applies to covered entities — healthcare providers, health plans, and healthcare clearinghouses — and to business associates: any organisation that creates, receives, maintains, or transmits ePHI on behalf of a covered entity. This includes cloud service providers, EHR vendors, billing companies, and analytics firms that process health data.
The Security Rule organises its requirements into three safeguard categories: Administrative, Physical, and Technical. Technical safeguards — defined at §164.312 — are the controls that IT and security teams are directly responsible for. Access control is the first technical safeguard listed and the most frequently cited in enforcement actions.
The Department of Health and Human Services Office for Civil Rights (OCR) enforces HIPAA. It investigates complaints and conducts audit programmes. In enforcement actions, OCR has imposed significant financial settlements specifically for access control failures, including organisations that could not demonstrate who had access to ePHI systems or that access was reviewed regularly.
§164.312 Technical Safeguards: Access Control Requirements
| Section | Requirement | Status |
|---|---|---|
| §164.312(a)(1) | Access Control (Required): Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to authorised persons or software programs. | Required |
| §164.312(a)(2)(i) | Unique User Identification (Required): Assign a unique name and/or number for identifying and tracking user identity. No shared accounts for ePHI access. | Required |
| §164.312(a)(2)(ii) | Emergency Access Procedure (Required): Establish and implement procedures for obtaining necessary ePHI during an emergency. | Required |
| §164.312(a)(2)(iii) | Automatic Logoff (Addressable): Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. | Addressable |
| §164.312(b) | Audit Controls (Required): Implement hardware, software, and/or procedural mechanisms to record and examine activity in information systems containing or using ePHI. | Required |
| §164.312(c)(1) | Integrity (Required): Implement policies and procedures to protect ePHI from improper alteration or destruction. | Required |
Required vs Addressable does not mean optional
"Addressable" implementation specifications must be either implemented as written, implemented with an equivalent alternative, or documented as not applicable with justification. OCR investigators treat unexplained non-implementation of an addressable specification as a violation, not a choice. The distinction matters only in how you document your approach, not in whether you address the requirement.
Why this matters for leadership and compliance officers
HIPAA enforcement has intensified significantly in recent years, with OCR resolving numerous investigations through resolution agreements — access control failures are consistently among the leading causes. The financial exposure is real: civil monetary penalties range from $100 to $50,000 per violation, per year, up to a maximum of $1.9 million per violation category. Criminal penalties for wilful neglect can reach $250,000 with imprisonment. Beyond direct penalties, a reportable breach triggers mandatory notification to affected individuals, HHS, and — if over 500 individuals — prominent media coverage. The reputational damage to a healthcare provider or business associate following a breach traced to inadequate access controls is often more costly than the fine itself. Leadership cannot treat §164.312 as an IT concern — it is a board-level risk.
What OCR investigators and HIPAA auditors examine
Whether triggered by a complaint, a breach notification, or a proactive audit, OCR investigators will specifically request:
- Access authorisation records (§164.312(a)(1)): For each ePHI system, who is authorised to access it, what level of access do they have, and when was that access formally granted? The authorisation must predate the access, not be reconstructed after the fact.
- Unique user identification (§164.312(a)(2)(i)): Provide the user list for each system with ePHI access. Investigators actively look for shared accounts, generic IDs (admin, nurse_station, lab_user), or any credential not assigned to a specific individual.
- Workforce changes: Cross-reference active system accounts against HR records of terminations and role changes in the past 12–24 months. Residual access after termination is a consistent enforcement finding.
- Audit trail completeness (§164.312(b)): Demonstrate that access activity is logged and that logs are reviewed. Investigators ask: what was logged, who reviewed it, what anomalies were identified, and what action was taken?
The Workforce Access Challenge in Healthcare
Healthcare organisations face access management challenges that are structurally more difficult than most other industries. High staff turnover — particularly among nursing and allied health — means provisioning and deprovisioning must happen quickly and reliably. Contract staff, agency workers, travelling clinicians, and medical students rotate through systems on irregular schedules. Merged organisations inherit inconsistent access models. Night shifts and emergency situations create pressure to bypass controls.
The result is that ePHI system access lists tend to accumulate stale entries — accounts for staff who have moved on, broader access than a current role requires, or access to systems that are no longer clinically relevant for a given user. Without a systematic review process, this accumulation is invisible until a breach or an OCR investigation makes it visible at the worst possible moment.
Finding: Shared credentials in ePHI systems (§164.312(a)(2)(i))
Nursing station logins, shared departmental accounts, or admin credentials used by multiple staff members are a direct violation of the unique user identification requirement. OCR has cited this in enforcement actions against hospitals of all sizes.
Finding: No formal access authorisation process (§164.312(a)(1))
Access was granted informally or the request-approval process was not documented. OCR requires that the authorisation exist as a record, not merely that it happened.
Finding: Former employees retained ePHI access (§164.312(a)(1))
The most common breach scenario in healthcare is insider access — whether malicious or accidental — by a former employee. OCR will hold the covered entity responsible if the access was not removed promptly upon termination.
How AllowNow Addresses §164.312
| Section | AllowNow evidence |
|---|---|
| §164.312(a)(1) | Complete ePHI system access inventory with formal grant records — every access assignment has an authorising user (granted_by), grant timestamp (granted_at), and current review status. |
| §164.312(a)(2)(i) | Employee ID field maps every access record to a unique individual. The HIPAA report flags any user with a missing employee ID — direct evidence of unique user identification compliance. |
| §164.312(b) | Every access grant, review decision (with reviewer identity), revocation, and implementation event is timestamped and attributed. The complete activity log is exportable on demand for OCR investigation response. |
| Workforce changes | Access revocations flow through a tracked implementor queue — the full chain from 'access revoked' to 'access removed in external system' is recorded. No orphaned access after termination. |
| HIPAA PDF | Compliance findings: unique ID coverage, unreviewed access count, stale reviews, audit trail completeness — the exact evidence OCR and HIPAA auditors request. |
The AllowNow HIPAA Access Control Evidence Report references §164.312 directly and includes an observations section covering the specific gaps OCR investigators look for: missing employee IDs, unreviewed access records, stale reviews, and gaps in the provisioning and deprovisioning audit trail. It is designed to be produced on demand — whether for an OCR investigation, an internal audit, or a business associate agreement review.
Built for small healthcare organisations and business associates
AllowNow is designed for small covered entities and business associates — clinics, dental practices, therapy providers, SaaS vendors processing health data — that need §164.312 compliance evidence without a dedicated privacy officer or compliance team. If your organisation handles ePHI and needs a formal, documented access control process before an audit or OCR investigation, AllowNow provides it with minimal setup.
For healthcare organisations, the goal is not just to pass an audit — it is to ensure that access to ePHI is genuinely controlled and demonstrably appropriate. AllowNow makes that evidence continuous, not assembled under crisis conditions when OCR comes knocking.