A HIPAA Security Rule assessment determines whether a Covered Entity or Business Associate has established, implemented, documented, and maintained reasonable and appropriate safeguards for electronic protected health information and the information systems that support it.
The assessment should examine more than the presence of written policies. It should establish whether security procedures operate as documented, whether assigned personnel understand their responsibilities, whether technical safeguards cover the full environment, and whether the organization can continue operating during a security incident or system failure.
The HIPAA Security Rule does not define one document called a HIPAA Security Rule assessment. The assessment process draws on several regulatory duties, including risk analysis, risk management, security incident procedures, contingency planning, access control, audit controls, workforce sanctions, evaluation, and documentation.
A risk analysis forms part of the assessment but does not cover every subject that should be reviewed. Risk analysis identifies potential risks and vulnerabilities affecting electronic protected health information. A broader HIPAA Security Rule assessment examines how the organization manages those risks through policies, procedures, safeguards, assigned responsibilities, testing, and corrective action.
Assessment Scope and Preparation
The assessment should cover all electronic protected health information created, received, maintained, or transmitted by the regulated entity. The scope should include systems operated directly by the organization and systems operated on its behalf by Business Associates.
The assessment team should identify the legal entities, facilities, workforce groups, systems, applications, devices, networks, cloud platforms, backup services, and vendors included in the review. Any exclusion should be documented with the reason for the exclusion.
The review should include electronic health record systems, billing applications, email platforms, document repositories, patient portals, mobile devices, medical devices, remote access services, identity management platforms, file transfer systems, backup environments, and administrative workstations. Systems that do not store electronic protected health information may still fall within scope when they control access to systems that do.
Assessment evidence may include policies, procedures, risk records, system inventories, network diagrams, configuration reports, audit logs, access lists, incident records, training records, contracts, Business Associate Agreements, backup reports, test results, meeting records, and interviews with responsible personnel.
The assessment record should distinguish between a written requirement, an implemented procedure, and an operating safeguard. A policy alone does not establish that the required process has been applied. A configured control alone does not establish that the control is monitored or maintained.
Incident Response Plan
Plan Development and Maintenance
The organization should maintain documented procedures for identifying and responding to suspected or known security incidents. The procedures should address containment, investigation, mitigation, recovery, internal reporting, external communication, evidence preservation, and documentation of the incident outcome.
The current HIPAA Security Rule does not require a document with the specific title Incident Response Plan. It requires policies and procedures that enable the organization to identify security incidents, respond to them, limit known harmful effects where practicable, and document the incidents and their outcomes.
A formal plan provides a structured method for meeting these requirements. The plan should identify who has authority to activate the response process, who directs technical actions, who evaluates legal and regulatory duties, and who communicates with management, affected individuals, vendors, insurers, law enforcement, and government agencies when applicable.
The plan should cover attempted and successful events. An attempted intrusion, blocked malware execution, unsuccessful account takeover, or failed effort to interfere with system operations may qualify as a security incident even when no electronic protected health information is accessed.
Incident classifications should reflect the organization’s systems and risks. The procedures may address compromised credentials, malware, ransomware, unauthorized access, loss of devices, improper disclosures, malicious workforce conduct, vendor incidents, denial-of-service attacks, alteration of records, backup failures, and extended system outages.
The organization should assign named positions or functions rather than relying solely on individual employees. Role-based assignments support continuity when personnel change or when a designated employee is unavailable during an incident.
The plan should be reviewed after changes to systems, vendors, facilities, staffing, services, or legal obligations. Review should also follow an incident when the response identifies unclear responsibilities, missing procedures, ineffective controls, or communication failures.
Incident Response Team Responsibilities
A regulated entity may establish an Incident Response Team to coordinate its response activities. The current HIPAA Security Rule does not expressly require a formally named team, but defined responsibilities can support an organized response.
The team may include personnel from information technology, information security, privacy, compliance, legal services, human resources, clinical operations, communications, facilities management, and executive management. The required participants depend on the organization’s structure and the nature of the incident.
The assessment should determine whether each assigned function understands its authority and responsibilities. It should also establish whether replacement personnel are designated when the assigned person is absent.
Contact details should be accessible when normal systems are unavailable. An incident plan stored only on an affected network may be inaccessible during ransomware, identity system failure, or a loss of network connectivity.
Workforce Sanction Policy
The assessment should verify that the organization applies appropriate sanctions when workforce members fail to comply with HIPAA Security Rule policies and procedures. The sanction process should cover intentional misconduct, negligent conduct, repeated noncompliance, unauthorized access, credential sharing, failure to report an incident, and other violations of documented requirements.
Sanctions are not limited to workforce members who directly cause a breach or cyberattack. A sanction may apply when an employee, volunteer, trainee, contractor, or other workforce member violates a security policy even when the violation does not produce a reportable breach.
The incident response process should direct suspected workforce violations to the designated compliance, legal, management, or human resources process. The investigation should establish the relevant facts before a sanction decision is made.
The organization should apply its sanction policy consistently. The assessment should examine whether comparable violations receive comparable treatment and whether management personnel are subject to the same documented requirements as other workforce members.
Sanction records should identify the conduct reviewed, the applicable policy, the findings, the action taken, and any related corrective measures. Employment law, contractual obligations, collective agreements, and internal procedures may affect the form of the sanction.
Post-Incident Risk Review
Incident findings should be evaluated against the organization’s existing risk analysis and risk management plan. An incident may disclose an unidentified vulnerability, an inaccurate system inventory, a missing safeguard, an ineffective procedure, or a risk rating that no longer reflects the operating environment.
The current HIPAA Security Rule does not state that every security incident requires a complete organization-wide risk analysis. The organization should determine whether the event changes its understanding of the risks and vulnerabilities affecting electronic protected health information.
The review should consider the initial cause, contributing conditions, systems affected, information involved, safeguards that failed, safeguards that limited harm, response delays, recovery problems, and changes needed to prevent recurrence.
Corrective action may include changes to system configuration, access controls, monitoring, policies, training, vendor requirements, backup processes, physical safeguards, or incident response assignments. The organization should document the selected action, responsible owner, completion date, and validation method.
A lessons-learned meeting can support the review. The regulatory focus remains on documented incident outcomes, risk management, evaluation, and revision of policies and procedures when changes affect the security of electronic protected health information.
HIPAA Breach Notification Rule Coordination
The incident response process should include a separate procedure for determining whether an incident involves an impermissible acquisition, access, use, or disclosure of protected health information under the HIPAA Breach Notification Rule.
A security incident does not automatically constitute a reportable breach. The organization must examine the facts and determine whether protected health information was involved, whether the information was unsecured, whether an exception applies, and whether the required breach risk assessment supports a low probability that the information was compromised.
The breach risk assessment examines the nature and extent of the protected health information, the unauthorized person who used or received the information, whether the information was acquired or viewed, and the extent to which the risk was mitigated.
This breach assessment is different from the enterprise risk analysis required by the HIPAA Security Rule. The enterprise risk analysis examines potential risks and vulnerabilities across the electronic protected health information environment. The breach assessment examines the circumstances of a particular impermissible use or disclosure.
Affected individuals must receive notice without unreasonable delay and no later than 60 calendar days after discovery of a reportable breach. Discovery occurs when the breach is known or would have been known through reasonable diligence.
A breach affecting 500 or more individuals must be reported to HHS within the applicable notification period. A breach affecting fewer than 500 individuals may be recorded and reported to HHS within 60 days after the end of the calendar year in which it was discovered.
Media notice applies when a breach affects more than 500 residents of a single state or jurisdiction. The notice is provided to prominent media outlets serving that state or jurisdiction. The threshold is not based solely on the total number of individuals affected across all locations.
A Business Associate must notify the Covered Entity after discovering a breach of unsecured protected health information. The notice must be provided without unreasonable delay and no later than 60 calendar days after discovery unless the Business Associate Agreement requires a shorter period.
HIPAA Security Rule Training
The HIPAA Security Rule requires Covered Entities and Business Associates to implement a security awareness and training program for all workforce members, including management.
The training program should reflect the organization’s risk analysis, information systems, security policies, and workforce responsibilities. Training content should address the safeguards employees need to apply when accessing, using, transmitting, storing, or disposing of electronic protected health information.
The security awareness and training standard includes addressable implementation specifications for security reminders, protection from malicious software, log-in monitoring, and password management. An organization must assess whether each specification is reasonable and appropriate in its environment. It must implement the specification or document its decision and apply an equivalent measure when reasonable and appropriate.
Training should explain how workforce members recognize and report suspected security incidents. Topics may include phishing, malicious attachments, compromised credentials, unauthorized access, lost devices, unusual system activity, ransomware, and failures affecting the availability of electronic protected health information.
The current HIPAA Security Rule does not prescribe a fixed training interval. The program should provide instruction when workforce members require it to perform their assigned functions and should deliver periodic security updates. Additional instruction should follow material changes to systems, risks, policies, procedures, job duties, or incident reporting processes.
The organization should document the training content, delivery date, participants, completion status, and any required follow-up. Training records should be retained with the organization’s HIPAA Security Rule documentation for six years from the date of creation or the date when the record last remained in effect, whichever is later.
The assessment should verify that training covers the entire workforce, matches current security procedures, addresses identified risks, and produces records that demonstrate implementation of the program.
Technical and Evidence Safeguards
Audit Controls
The assessment should determine whether information systems containing or using electronic protected health information generate records that allow the organization to examine access and other system activity.
Audit records may include successful and failed logins, user activity, privileged actions, access to patient records, changes to permissions, creation or deletion of accounts, exports of information, changes to system settings, malware alerts, remote access events, and administrative commands.
The assessment should verify that logging covers the systems identified in the electronic protected health information inventory. Logging that applies only to the electronic health record may leave email, cloud storage, billing systems, connected devices, file servers, and identity platforms outside the review process.
The organization should identify which events are recorded, where records are stored, who can access them, how they are protected, how frequently they are reviewed, and what conditions generate an investigation or alert.
The current HIPAA Security Rule requires mechanisms for recording and examining system activity. It does not prescribe a particular logging product or architecture.
Audit Log Protection
Audit records should be protected against unauthorized access, alteration, deletion, and premature disposal. Access to logging systems should be limited to personnel whose assigned duties require it.
Separating audit records from the systems that generate them can reduce the risk that an attacker will delete local evidence after compromising a device or server. Centralized logging, restricted administrative rights, isolated storage, and write-protected retention may support this objective.
The current HIPAA Security Rule does not expressly require immutable logs, a security information and event management platform, or write-once-read-many storage. These measures may be selected when the organization determines that they are reasonable and appropriate for its risks and technical environment.
The assessment should test whether recorded events can be retrieved and interpreted during an investigation. Logging that is enabled but incomplete, inaccessible, overwritten too quickly, or recorded with inaccurate timestamps may not provide usable evidence.
Information System Activity Review
Generating audit records does not satisfy the separate duty to review information system activity. The organization should maintain procedures for reviewing audit logs, access reports, security incident tracking records, and related information.
The review frequency should reflect the sensitivity of the system, the type of activity recorded, the potential impact of misuse, and the organization’s identified risks. The current HIPAA Security Rule does not prescribe one review interval for every system.
Automated alerts may support the process, but they do not replace documented review procedures. The assessment should establish who receives alerts, how alerts are evaluated, how false positives are resolved, and when an event is escalated as a suspected security incident.
The organization should retain evidence that reviews occurred. Review records may identify the reviewer, date, systems examined, exceptions found, investigation opened, and corrective action assigned.
External Incident Response Providers
The organization should determine whether internal personnel have the skills, authority, tools, and availability required to investigate and recover from a security incident. External support may be needed for forensic analysis, malware investigation, data recovery, legal review, breach notification, public communication, or restoration of damaged systems.
Advance contracts with forensic firms, legal counsel, restoration providers, notification vendors, and other specialists can define availability, rates, response times, confidentiality duties, evidence handling, and communication channels before an incident occurs.
The current HIPAA Security Rule does not expressly require advance retainers or pre-negotiated master service agreements. These arrangements are risk management measures rather than named regulatory implementation specifications.
A service provider that creates, receives, maintains, or transmits protected health information on behalf of a Covered Entity or Business Associate may require a Business Associate Agreement. The assessment should determine the provider’s role before information is disclosed or access is granted.
The organization should also review cyber insurance conditions, panel provider requirements, consent requirements, and notice procedures. Contracting with a provider outside the insurer’s approved process may affect coverage.
Business Continuity and Disaster Recovery
Contingency Plan
The assessment should determine whether the organization has established and implemented procedures for responding to emergencies or other events that damage systems containing electronic protected health information.
The contingency plan should cover events such as fire, water damage, power failure, hardware failure, ransomware, destructive malware, loss of network services, cloud service interruption, facility inaccessibility, and failure of a Business Associate service.
The plan should identify activation authority, communication methods, workforce responsibilities, alternate procedures, recovery resources, vendor contacts, and the conditions for returning to normal operations.
The organization may integrate its HIPAA contingency procedures into a broader business continuity and disaster recovery program. The assessment should still identify the procedures that protect the confidentiality, integrity, and availability of electronic protected health information during emergency operations.
Data Backup Plan
The organization must establish and implement procedures for creating and maintaining retrievable exact copies of electronic protected health information.
The assessment should establish which systems and data are included in backups, how frequently copies are created, where they are stored, how they are encrypted, who can access them, how failures are reported, and how the organization confirms that the copies can be restored.
A completed backup job does not establish recoverability. The organization should test whether backup data can be restored within the time needed to support its operations.
Backup architecture should account for ransomware and other attacks that target connected backup repositories. Segregated, offline, isolated, or otherwise protected copies may reduce the risk that production systems and backups will be damaged during the same event.
The assessment should also address electronic protected health information stored outside the main data center. Information held in cloud applications, mobile devices, departmental systems, connected medical equipment, or vendor platforms may be excluded from the primary backup process unless specifically identified.
Disaster Recovery Plan
The disaster recovery plan should establish procedures for restoring lost electronic protected health information and the systems needed to access it.
The plan should identify recovery dependencies, required hardware, software installation sources, license information, encryption keys, service accounts, administrator credentials, network configurations, vendor assistance, and alternate hosting arrangements.
Recovery procedures should specify the order in which systems will be restored. The order should reflect patient care, access to electronic protected health information, security dependencies, operational needs, and the relationship between systems.
A clinical application may depend on identity services, network connectivity, database servers, storage systems, interfaces, and security tools. A recovery sequence that does not account for these dependencies may delay restoration even when application backups are available.
Emergency Mode Operation Plan
The emergency mode operation plan should enable the organization to continue the business processes needed to protect electronic protected health information while normal systems or facilities are unavailable.
The plan should address access to patient information, authentication, authorization, secure communications, record creation, record reconciliation, medication processes, order management, billing information, and protection of temporary records.
Paper downtime procedures may support patient care during an electronic health record outage. The procedures should define how paper records are secured, who may access them, how they are tracked, and how the information is entered into the electronic system after service is restored.
The HIPAA Security Rule does not specifically require paper downtime procedures or predefined network shutdown thresholds. An organization may adopt these measures when they support safe operations and protection of electronic protected health information.
The assessment should determine who can authorize isolation or shutdown of systems during an attack. Delayed authority can permit further compromise, while an uncoordinated shutdown can interfere with patient care and destroy evidence needed for investigation.
Applications and Data Criticality Analysis
The organization should assess the relative importance of applications and data when developing its contingency plan. This implementation specification is addressable under the current HIPAA Security Rule.
Addressable does not mean that the organization may disregard the specification without review. The organization must determine whether the measure is reasonable and appropriate in its environment. When it is not implemented as written, the organization should document its reasoning and implement an equivalent measure when reasonable and appropriate.
The analysis should identify systems containing electronic protected health information and the technical services needed to operate them. It should record recovery dependencies, acceptable outage periods, data loss tolerances, required personnel, vendor support, and restoration priorities.
Recovery priorities should not be based solely on the amount of information stored in a system. A small identity service, network component, or interface may be required before a larger clinical system can operate.
The assessment should compare the stated recovery priorities with the actual backup and restoration capabilities. A recovery objective has limited value when the organization lacks the personnel, equipment, data copies, or procedures needed to meet it.
Emergency Access Procedures
The organization must maintain procedures that allow authorized personnel to obtain necessary electronic protected health information during an emergency.
Emergency access may be required when the normal authentication service, network connection, application, facility, or access approval process is unavailable. The procedures should identify who may use emergency access, how access is authorized, how credentials are protected, and how activity is recorded and reviewed.
Break-glass access within a clinical application can permit access to restricted information during patient care. Emergency administrator accounts can permit technical personnel to restore infrastructure when the primary identity platform is unavailable.
These controls serve different functions. Administrator access to servers does not by itself provide clinicians with necessary electronic protected health information. Clinical break-glass access does not by itself permit technical recovery of damaged infrastructure.
The assessment should test both operational and technical emergency access. It should also verify that emergency credentials remain available when normal password vaults, identity platforms, or network services cannot be reached.
Testing and Validation
Contingency Plan Testing
The organization should periodically test and revise its contingency procedures. Testing and revision procedures are addressable under the current HIPAA Security Rule.
The assessment should determine whether the organization has evaluated this specification, documented its decision, and established a testing method suited to its environment. Testing may involve discussion-based exercises, technical restoration tests, communication tests, facility exercises, or controlled simulations.
A plan review that confirms only the presence of written procedures does not establish that personnel can perform the assigned tasks or that systems can be restored.
Tabletop Exercises
A tabletop exercise presents participants with a simulated incident and requires them to work through decisions, responsibilities, communications, and recovery actions.
Scenarios may address ransomware, loss of the electronic health record, compromise of a cloud provider, unauthorized access by a workforce member, destruction of a data center, failure of identity services, or an incident affecting a Business Associate.
The current HIPAA Security Rule does not expressly require tabletop exercises or participation by a specified list of departments. The organization may use tabletop exercises as one method of evaluating its incident response and contingency procedures.
The exercise should test more than technical containment. Participants should address executive authority, privacy analysis, legal review, breach notification, workforce communication, patient care, media inquiries, vendor coordination, insurance notice, evidence preservation, and restoration priorities when these functions apply.
The assessment should determine whether participants receive only the information they would have at that stage of a real incident. Providing the full scenario in advance may prevent the exercise from testing escalation, investigation, and decision-making processes.
Technical Recovery Testing
Technical recovery testing should establish whether the organization can retrieve backup data, rebuild systems, restore configurations, reconnect interfaces, validate data integrity, and return services to operation.
The test should record the time required for each step, failures encountered, dependencies discovered, data lost, manual intervention required, and differences between the documented procedure and the actual process.
Testing should protect production systems and patient information. The organization should define the test environment, access controls, data handling procedures, and authority for any activity that could affect live operations.
A successful restoration should include validation that authorized users can access the required information and that security safeguards operate after recovery. Restoring a server without confirming access controls, logging, encryption, interfaces, and data integrity leaves the test incomplete.
Test Findings and Plan Revision
Each exercise or recovery test should produce a written record of the scenario, participants, systems involved, actions performed, results, deficiencies, assigned corrective actions, and completion dates.
The organization should revise procedures when testing identifies inaccurate instructions, unavailable contacts, missing credentials, unsupported recovery assumptions, inadequate staffing, or systems omitted from backup and restoration plans.
Corrective actions should be validated after implementation. Closing a finding based only on a statement that work was completed does not establish that the revised control or procedure operates as intended.
Assessment Documentation
The assessment record should identify the scope, methodology, participants, evidence reviewed, interviews conducted, systems examined, findings, regulatory requirements evaluated, and limitations of the work.
Each finding should describe the condition observed, the affected systems or processes, the associated risk, the required or selected corrective action, the responsible owner, the target completion date, and the method used to confirm completion.
The organization should separate regulatory noncompliance from recommended security improvements. A finding based on an express HIPAA Security Rule requirement should not be presented in the same manner as a recommendation for a security measure that the regulation does not specifically prescribe.
The assessment should also identify addressable implementation specifications. The record should show whether each specification was implemented, replaced with an equivalent measure, or not implemented after a documented determination that the measure was not reasonable and appropriate.
HIPAA Security Rule documentation must be retained for six years from its date of creation or the date when it last remained in effect, whichever is later. This rule applies to required HIPAA Security Rule documentation. It does not establish a six-year retention period for every technical log or item of network data.
Corrective Action Management
An assessment does not complete the compliance process when identified deficiencies remain unassigned or untreated. Management should approve a corrective action process that tracks each finding through resolution.
Corrective action records should identify interim safeguards when the permanent measure cannot be implemented promptly. Interim measures may include tighter access restrictions, additional monitoring, temporary network isolation, manual review, or suspension of a vulnerable service.
Management should document risk acceptance decisions. The record should identify the risk accepted, the person with authority to accept it, the reasons for the decision, existing safeguards, the period of acceptance, and the date for reconsideration.
Risk acceptance should not be used to avoid an express regulatory requirement. It applies to residual risk and to treatment choices within the flexibility permitted by the HIPAA Security Rule.
Assessment Frequency
The current HIPAA Security Rule does not establish one fixed interval for completing a full HIPAA Security Rule assessment. The organization must maintain policies and procedures that remain reasonable and appropriate and must conduct evaluations in response to environmental or operational changes affecting the security of electronic protected health information.
An organization may adopt an annual assessment schedule as an internal compliance practice. Scheduled review should not delay reassessment after a material change.
Events that may require additional review include the implementation of a new electronic health record, migration to a cloud platform, acquisition of another practice, introduction of remote access, relocation of a facility, replacement of a network, deployment of connected medical devices, engagement of a new Business Associate, discovery of an unrecorded data repository, or completion of a security incident investigation.
The scope of the follow-up assessment should reflect the change. A limited system change may require a focused review. A merger, cloud migration, or restructuring of information systems may require a broader assessment.
Current and Proposed HIPAA Security Rule Requirements
The HIPAA Security Rule currently in effect remains the governing federal standard for safeguarding electronic protected health information. Covered Entities and Business Associates should base present compliance decisions on the existing requirements.
HHS issued proposed changes to the HIPAA Security Rule in January 2025. The proposal would create more specific requirements for risk analysis, asset inventories, network maps, incident response, contingency planning, testing, documentation, and technical safeguards.
The proposal would also revise the current treatment of addressable implementation specifications. These changes do not apply unless HHS publishes a final rule and the applicable compliance period begins.
Many practices reviewed during a current assessment would remain relevant under the proposed framework. An organization should not describe a proposed provision as a current legal obligation.
The assessment report should identify the regulatory version used for the review. When an organization also evaluates readiness for proposed requirements, the report should separate current compliance findings from future planning observations.