Organise safeguards around the service they protect
The HIPAA Security Rule requires regulated entities to protect electronic protected health information (ePHI) through administrative, physical and technical safeguards, together with organisational and documentation requirements. The practical task is to make these measures work together across people, systems, locations and suppliers. A hospital application can have strong encryption while retaining abandoned accounts; a service provider can have careful access approvals while lacking a recoverable backup. Assess the combined protection of the service. Summary of the HIPAA Security Rule
Use the healthcare workflow as the organising unit. Identify the information it creates or receives, the people who act on it, the systems that maintain it and the dependencies needed to keep it available. Then connect each safeguard to a specific failure it should prevent, detect or help recover from. This produces a clearer implementation plan than distributing a list of regulatory headings to departments and asking each to mark them complete.
The current baseline matters. On 12 October 2026, the eCFR page checked for this article retained required and addressable implementation specifications. HHS’s current-rule summary was reviewed in August 2026. The December 2024 proposal, published in January 2025, is treated here as a proposal, not as an effective replacement. Particular proposed testing intervals and technology mandates should not be represented as current universal requirements. 45 CFR Part 164, Subpart C HIPAA Security Rule NPRM fact sheet
Understand required and addressable specifications
An applicable Security Rule standard is not optional. A required implementation specification must be implemented. An addressable specification requires assessment of whether it is reasonable and appropriate in the entity’s environment. Where it is, it must be implemented; where it is not, the entity documents the reason and implements an equivalent alternative where reasonable and appropriate. This process is more demanding than checking not applicable without explanation. 45 CFR Part 164, Subpart C
Create a decision record for addressable specifications that need particular analysis. Describe the system and workflow, the safeguard considered, the relevant risks, available options, the decision and the evidence supporting it. Include the person responsible for implementation and the trigger for reconsideration. If a legacy system cannot support a preferred measure, examine surrounding controls and the replacement plan rather than turning technical inconvenience into a permanent exemption.
Keep three statements distinct. The rule may require an outcome or process; your risk analysis may support a particular technical measure; and a customer contract may impose a more specific condition. All can matter, but they have different sources. When leadership understands why a measure is needed, it can make better decisions about funding, sequencing and exceptions.
A well-written control description should state what the organisation does, where it applies and how it is checked. For example, an account process should explain the approved source of workforce changes, application ownership, removal steps and evidence of completion. Describing a product as capable of deactivating accounts does not establish that the organisation has implemented a reliable termination process.
Administrative safeguards make decisions repeatable
Administrative safeguards include risk analysis and management, assigned security responsibility, workforce security, information access management, security awareness and training, incident procedures, contingency planning, evaluation and relevant business associate arrangements. Their purpose is operational: the organisation should know who makes decisions, who carries them out and how ineffective practices are corrected. The governing requirements are in 45 CFR 164.308. 45 CFR Part 164, Subpart C
Begin with authority and accountability. The security official needs access to information about systems and changes, a way to escalate unresolved risks and support from service owners. Clinical operations should help define recovery priorities. Human resources should provide reliable workforce events. Procurement should identify suppliers before they receive ePHI. Application owners should understand their permissions and logging responsibilities. These responsibilities remain meaningful even where several roles are held by the same person.
Make recurring work visible. Use a queue or register for risk actions, access reviews, supplier issues and incident lessons. Specify a completion condition for each item. A training task closes when the intended workforce has received relevant instruction and the organisation can demonstrate it, not when a slide deck has been purchased. A recovery task closes when the service can be restored under the agreed conditions, not when a backup subscription is active.
Evaluation should examine whether the programme works after environmental or operational changes. A new location, acquired practice, major application release or altered support model may change the safeguards needed. Build a security impact question into those decisions. Waiting for the next calendar review can leave the organisation operating with an assessment that no longer describes its environment.
Our HIPAA workforce-training guide helps translate administrative responsibilities into practical decisions, escalation routes and evidence of understanding.
Physical safeguards cover ordinary places of work
Physical safeguards address facilities, workstations and devices or media that hold or access ePHI. The details differ across a clinical site, a data centre, an administrative office and a remote support environment. A risk-based design should account for who can enter, what they can see or take and how equipment is maintained, moved, reused and disposed of. These responsibilities appear in 45 CFR 164.310. 45 CFR Part 164, Subpart C
Perform walkthroughs with the people who work in the space. A desk positioned for efficient patient interaction may expose a monitor to visitors. A multifunction printer may retain documents or leave output unattended. A maintenance contractor may need supervised access to equipment. A temporary clinic may lack the storage arrangements used at the main site. The review should identify practical adjustments that preserve service delivery.
For portable devices, connect inventory with management and incident processes. Record the assigned custodian, approved configuration and return arrangements. Determine what happens when a device is lost, damaged or replaced while staff are travelling. Ensure the team can identify whether the device held local ePHI and what protections were active. A generic asset number alone will not answer those questions during an incident.
Remote work procedures should explain approved equipment, screen privacy, local storage, printing and disposal. Staff need an alternative when their environment cannot meet the conditions. The organisation should verify relevant technical restrictions and provide usable guidance. A signed acknowledgement may be evidence of communication, but it does not demonstrate that a shared home computer has become a suitable place for unrestricted patient-record access.
Technical safeguards need coverage and operation
The technical safeguard categories are access control, audit controls, integrity, person or entity authentication and transmission security. Each should be implemented for the relevant information systems, not only the newest platform. Legacy applications, interfaces, diagnostic tools, backup consoles and customer portals can create significant exposure outside the main identity dashboard. 45 CFR Part 164, Subpart C
Build an access inventory that includes individual users, privileged accounts, service accounts and integration credentials. For each, identify its purpose, owner, approved scope and removal process. Review whether access restrictions apply consistently across screens, reports, APIs and exports. A user prevented from viewing another customer’s record in the interface should not be able to retrieve it through a different function.
Logging should capture events that support investigation and routine review. Check whether the organisation can identify the actor, action, affected resource and time with adequate reliability. Define who examines the records and what happens when a concern is found. Protect log access and consider whether logs themselves contain protected health information (PHI). More collection is not automatically better if the resulting archive is insecure, unreviewed or impossible to search.
Transmission and encryption designs should include key management, support processes and failure handling. A secure connection that silently falls back to an insecure route undermines the intended protection. An encrypted backup that cannot be decrypted during recovery may undermine availability. Test the complete process with controlled data, including the circumstances in which the main control fails or an emergency route is used.
For hosted systems, connect these safeguards to customer-owned configuration and supplier responsibilities using our HIPAA cloud guide.
Hypothetical example: a hospital brings a legacy interface into scope
A fictional hospital discovers that a legacy laboratory interface uses a shared administrative account and stores troubleshooting files in a broadly accessible folder. The main electronic health record has modern controls, but the interface was treated as background infrastructure and omitted from recent review. The security team first identifies what ePHI passes through it, which services depend on it and who can change its configuration.
Administrative work establishes an accountable application owner and a controlled support process. Physical review checks where the interface server and console are located and who can access them. Technical review examines authentication, file permissions, logging and backup coverage. The team does not assume that buying one tool will resolve every issue, because some weaknesses arise from ownership and process rather than missing software.
The supplier confirms that a planned upgrade can support individual administration, but the change needs clinical testing. Meanwhile, the hospital restricts the support path, records authorised use and limits the diagnostic folder. The interim arrangement is documented with its limitations and replacement dependency. Clinical operations helps schedule the change to avoid interrupting results delivery.
Validation checks that test results reach the correct destination, unauthorised users cannot retrieve diagnostic files and support actions can be attributed. Recovery testing includes the interface configuration and dependencies. The resulting record explains the original risk, temporary protection, implemented change and remaining uncertainty. It is stronger evidence than a declaration that the hospital already uses a compliant electronic health record.
Hypothetical example: a BPO separates customer access
A fictional healthcare BPO serves three customers through different claims systems. Staff move between accounts during peak periods, and supervisors use a shared spreadsheet to request access. A review finds that some workers keep permissions after rotating away from a customer. The issue is not simply a password problem; it involves role design, workforce change notifications, customer approvals and verification.
The organisation redesigns assignment changes as access events. Operations supplies the approved customer assignment, customer contacts approve the relevant scope and technical owners implement the change. Staff receive instructions specific to the new workflow. The BPO records completion across each customer platform, including any application outside its central identity service. It verifies that a removed user cannot continue through an existing session.
Physical and technical measures support the new process. Workstations and remote environments are reviewed for local copies and cross-customer exports. Customer-specific queues reduce accidental mixing. Logs and supervisory checks look for activity inconsistent with current assignments. The review distinguishes justified temporary overlap from access that has simply been forgotten.
A pilot rotation demonstrates the full sequence: approval, provisioning, instruction, work, removal and verification. The team measures failed handoffs and corrects them before expanding the process. The example shows how administrative, physical and technical safeguards reinforce one another. A control becomes reliable when the handoffs work under ordinary workload and staff movement, not only during an assessment demonstration.
Define evidence before declaring a safeguard complete
For every major safeguard, record the requirement or decision it supports, the implementation owner, the evidence source and the validation method. Separate design evidence from operating evidence. A policy describes the intended process; a completed access request and its resulting configuration show a particular operation. A sample of completed requests can reveal whether the process is being followed consistently across the service.
Use proportionate tests. A low-risk document correction may need a review and approval, while a material access or recovery change may need a controlled technical exercise. Avoid collecting patient records merely to prove that a control exists. Synthetic examples, redacted outputs and carefully restricted reports can often demonstrate the necessary point while reducing additional exposure.
Maintain a visible list of residual issues. Leadership should know which systems remain outside monitoring, which supplier dependency is unresolved and which recovery capability has not been demonstrated. Do not hide those limits inside a high overall completion percentage. HHS does not recognise private Security Rule certifications as relief from legal obligations, so a programme should be judged by its actual scope and evidence. Are we required to certify compliance with the Security Rule?
Finally, make the controls maintainable. Assign review triggers for workforce changes, new systems, incidents and significant supplier changes. Preserve the rationale for addressable decisions so future reviewers understand them. The organisation should be able to explain both why it selected a safeguard and how it knows the safeguard is still doing the intended work.
Reference basis
HHS: Summary of the HIPAA Security Rule; eCFR: 45 CFR Part 164, Subpart C; HHS: HIPAA Security Rule NPRM fact sheet; HHS: Security Rule certification FAQ.
Frequently asked questions
Are administrative safeguards less important than technical controls?
No. Administrative processes establish ownership, risk decisions, workforce actions and response. Technical controls often depend on those processes for correct configuration and continued operation.
Can we omit an addressable specification?
Only after the required assessment and documentation process, with an equivalent alternative where reasonable and appropriate. Addressable is not a general permission to skip a difficult safeguard.
How do we show a control is working?
Use evidence tied to the specific workflow and period. Combine the approved design with operating records and appropriate validation, and disclose any coverage limits or unresolved failures.
Discuss the next practical step
To organise safeguard implementation, identify the healthcare service, its critical systems and the controls whose ownership or effectiveness is uncertain. Ask for a responsibility map and a validation plan that connects administrative, physical and technical work.
Explore CyberVantage360 HIPAA assessment and implementation services, or contact CyberVantage360 to discuss your priorities.