HIPAA Security Risk Assessment
A HIPAA Security Risk Assessment is a documented evaluation of the risks and vulnerabilities that could affect the confidentiality, integrity, and availability of all electronic protected health information created, received, maintained, or transmitted by a Covered Entity or Business Associate.
HIPAA Security Risk Assessment Definition
The HIPAA Security Rule uses the term risk analysis for the process commonly described as a HIPAA Security Risk Assessment. Under 45 CFR § 164.308(a)(1)(ii)(A), a regulated entity must “conduct an accurate and thorough assessment” of risks and vulnerabilities affecting electronic protected health information.
The assessment must address all electronic protected health information within the organization’s control. It is not limited to the electronic health record, the primary server, or systems located at the main office. The scope includes electronic protected health information handled through clinical systems, billing platforms, email, cloud services, portable devices, backup media, remote access tools, network storage, connected medical devices, and systems administered by Business Associates.
The HIPAA Security Rule does not prescribe one assessment method. A regulated entity may select a method suited to its size, structure, technical environment, and use of electronic protected health information. The selected method must produce an accurate and thorough evaluation rather than a checklist limited to whether named safeguards are present.
Organizations Required to Conduct an Assessment
Health plans, healthcare clearinghouses, covered healthcare providers, and Business Associates are subject to the HIPAA Security Rule risk analysis requirement when they create, receive, maintain, or transmit electronic protected health information. A Business Associate remains responsible for assessing its own environment even when a Covered Entity conducts vendor reviews or requires security documentation through a Business Associate Agreement.
A regulated entity may use outside consultants or technical specialists to assist with the assessment. Delegating the work does not transfer responsibility for the accuracy, scope, approval, risk treatment decisions, or supporting documentation.
Required Scope of the Assessment
Electronic Protected Health Information Inventory
The assessment must identify where electronic protected health information enters, moves through, and leaves the organization. The inventory should document systems, applications, databases, devices, media, facilities, network segments, cloud platforms, and external services that create, receive, maintain, process, or transmit electronic protected health information.
The inventory should also address assets that do not store electronic protected health information but provide a route into systems that do. Examples include identity systems, domain controllers, firewalls, routers, remote monitoring tools, software deployment platforms, and administrative workstations. A compromise of one of these assets can expose systems containing electronic protected health information.
Data Flow Documentation
Data flow documentation records how electronic protected health information is collected, used, transmitted, stored, backed up, archived, and disposed of. It should include internal transfers, internet connections, interfaces between applications, remote access, mobile use, electronic prescribing, claims transmission, patient portals, file transfers, and disclosures to Business Associates.
Data flow documentation can take the form of diagrams, system records, written process descriptions, or a combination of formats. The record must be detailed enough to identify exposure points and the safeguards applied at each stage.
Threat and Vulnerability Identification
The assessment must identify reasonably anticipated threats and vulnerabilities that could affect electronic protected health information. Threats may originate from external attackers, malicious insiders, workforce errors, system failures, software defects, unpatched applications, vendor failures, theft, fire, water damage, power loss, or other events that can affect information or system operations.
A threat is a circumstance or event that could cause harm. A vulnerability is a weakness that a threat could exploit. An internet-facing server is not a vulnerability by itself, but unsupported software, weak authentication, or an exposed administrative service may create vulnerabilities affecting that server.
Existing Safeguard Evaluation
The assessment must evaluate administrative, physical, and technical safeguards already in place. The review should determine whether each safeguard is documented, implemented, configured correctly, applied across the intended environment, monitored, and maintained.
A policy that has not been implemented does not establish that risk has been reduced. A technical control that is enabled on one system but absent from comparable systems may leave part of the electronic protected health information environment exposed. The assessment record should distinguish between safeguards that exist, safeguards that operate as intended, and safeguards planned for later implementation.
Likelihood and Impact Analysis
The organization must evaluate the likelihood that identified threats will exploit identified vulnerabilities and the potential impact on the confidentiality, integrity, or availability of electronic protected health information. The method may use qualitative ratings, numerical scoring, or another documented approach.
Impact analysis should address unauthorized access or disclosure, alteration or destruction of data, interruption of clinical and administrative operations, loss of access to records, patient safety consequences, recovery costs, contractual duties, and legal reporting obligations. The assessment method should apply consistent criteria so that comparable risks receive comparable ratings.
Risk Determination
The organization should combine likelihood and impact findings to assign a risk level and treatment priority. The record should identify the affected assets, electronic protected health information, threat, vulnerability, existing safeguards, calculated risk, proposed treatment, responsible owner, target date, and residual risk after treatment.
The HIPAA Security Rule does not require elimination of every risk. It requires regulated entities to reduce risks and vulnerabilities to a reasonable and appropriate level. The organization should document the basis for accepting, reducing, transferring, or avoiding each material risk.
Risk Analysis and Risk Management
Risk analysis identifies and evaluates risks. Risk management converts those findings into documented security measures and treatment decisions. Under 45 CFR § 164.308(a)(1)(ii)(B), a regulated entity must “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.”
A completed assessment without a risk management process does not satisfy the full security management standard. The organization should approve a risk management plan that records corrective actions, responsible personnel, funding decisions, implementation dates, dependencies, validation methods, and remaining exposure.
Risk treatment decisions should reflect the nature of the electronic protected health information, the organization’s technical environment, the probability and impact of harm, the cost and complexity of safeguards, and the requirements of the HIPAA Security Rule. Cost may be considered, but cost alone does not justify leaving a known risk untreated when a reasonable and appropriate safeguard is available.
HIPAA Security Rule Training Requirements
The HIPAA Security Rule requires Covered Entities and Business Associates to maintain a security awareness and training program that applies to every workforce member, including owners, executives, supervisors, employees, volunteers, trainees, and other persons under the organization’s direct control.
45 CFR § 164.308(a)(5)(i) states:
“Implement a security awareness and training program for all members of its workforce (including management).”
The regulation establishes an organization-wide program rather than a one-time course for selected employees. Training should address the security duties assigned to each workforce role and the safeguards used to protect electronic protected health information within the organization’s systems and working environment.
The content should reflect the findings of the organization’s risk analysis. Workforce members should receive instruction on the threats, vulnerabilities, policies, and procedures that apply to their access to electronic protected health information. Personnel with administrative access, remote access, system configuration duties, incident response responsibilities, or access to large volumes of electronic protected health information require instruction matched to those functions.
The HIPAA Security Rule identifies four addressable implementation specifications within the training standard. These concern security reminders, protection against malicious software, monitoring of log-in activity, and password management. Addressable specifications require a documented assessment. The organization must implement each measure when it is reasonable and appropriate or document why an alternative measure is reasonable and appropriate.
The security reminder specification requires “periodic security updates.” The current HIPAA Security Rule does not establish a fixed frequency or require annual training by name. The organization should determine the timing and format of updates from its risks, system changes, incident history, workforce functions, and security procedures.
Training should explain how workforce members identify and report suspected security incidents. Instruction may address phishing messages, malicious links, unexpected multifactor authentication requests, compromised passwords, lost equipment, unauthorized access, unusual system behavior, ransomware indicators, and improper transmission of electronic protected health information.
Malicious software instruction should address the organization’s procedures for identifying suspicious files, reporting alerts, using approved applications, and responding to suspected infection. Workforce members should not disable security software or attempt technical remediation unless their assigned duties authorize those actions.
Log-in monitoring instruction should explain how the organization detects unsuccessful access attempts, unusual account activity, and other authentication events. Workforce members should understand their responsibility to report unexpected account lockouts, unfamiliar log-in notifications, and activity that may indicate misuse of their credentials.
Password management instruction should address the organization’s credential creation, storage, use, reset, and reporting procedures. The training should prohibit password sharing and explain the approved method for storing credentials. Where the organization uses passkeys, authentication tokens, or multifactor authentication, the instruction should cover the correct handling of those methods.
Training should be provided when a workforce member receives access to electronic protected health information or systems that support it. Additional instruction should follow material changes to policies, technology, job responsibilities, authentication procedures, incident reporting processes, or identified risks.
The HIPAA Security Rule training program is separate from the workforce training required by the HIPAA Privacy Rule. An organization may deliver both subjects through the same training program, but the records and course content should show that the applicable privacy and security requirements were addressed.
The organization should document the training date, subject matter, delivery method, instructor or training provider, participating workforce members, completion status, and required follow-up. The assessment should also verify that the training remains consistent with current policies and that personnel can explain how to report a suspected security incident.
Security Incident Procedures
The risk assessment should evaluate whether the organization can identify, respond to, mitigate, report, and document security incidents. 45 CFR § 164.308(a)(6)(ii) requires regulated entities to “identify and respond to suspected or known security incidents” and to document incidents and their outcomes.
The HIPAA Security Rule does not expressly require a document titled Incident Response Plan or a formally named Incident Response Team. A written plan, assigned roles, escalation criteria, communication procedures, evidence handling instructions, and tested response workflows provide a practical method of meeting the incident procedure requirements.
The plan should define how the organization detects incidents, confirms their scope, contains affected systems, preserves evidence, restores operations, communicates with internal and external parties, and records decisions. It should address ransomware, compromised accounts, malicious insiders, lost devices, vendor incidents, unauthorized disclosures, system outages, and attacks affecting remote or cloud services.
Workforce Sanctions
The assessment should verify that the organization has a documented sanction policy and a consistent process for addressing workforce noncompliance. The sanction requirement applies when workforce members fail to comply with security policies and procedures. It is not limited to workers who intentionally or negligently caused an incident.
Incident procedures should direct suspected workforce noncompliance to the appropriate management, compliance, legal, or human resources process. The organization should document the investigation, findings, sanction decision, and any corrective measures while applying employment policies and applicable law.
Post-Incident Assessment Updates
Security incidents can reveal new threats, unrecognized vulnerabilities, ineffective safeguards, or inaccurate assumptions in an earlier assessment. The organization should determine whether incident findings require changes to the risk analysis, risk management plan, policies, technical safeguards, training, vendor oversight, or contingency procedures.
The HIPAA Security Rule does not state that every incident requires a complete enterprise-wide reassessment. The organization should document the incident and its outcome and update the assessment when the findings change the identified risks or the reasonable and appropriate measures needed to manage them.
Technical Safeguards and Evidence
Audit Controls and Activity Review
The assessment should examine whether systems containing or using electronic protected health information generate records that permit the organization to examine system activity. It should also evaluate whether the organization reviews audit logs, access reports, security incident reports, and related records at a frequency suited to the identified risks.
The HIPAA Security Rule requires audit controls and information system activity review. It does not expressly require a security information and event management platform, write-once-read-many storage, centralized network telemetry, or immutable logs. An organization may adopt these measures when its risk analysis supports their use.
Log protection should address unauthorized alteration, deletion, access, and premature disposal. The assessment should document which logs exist, where they are stored, who can access them, how they are reviewed, and how long they are retained under the organization’s documented needs and legal obligations.
Access Control and Emergency Access
The assessment should evaluate unique user identification, authorization, access changes, termination procedures, authentication, privileged access, remote access, and emergency access to electronic protected health information. Emergency access procedures must allow authorized personnel to obtain necessary electronic protected health information during an emergency.
Alternative administrator accounts or break-glass access to infrastructure may support recovery when an identity platform is unavailable. Those mechanisms do not replace procedures that allow authorized clinical and operational personnel to obtain necessary electronic protected health information during emergency operations.
Contingency Planning
The assessment should evaluate whether the organization can maintain or restore access to electronic protected health information during an emergency or system failure. The current HIPAA Security Rule requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan under 45 CFR § 164.308(a)(7).
The data backup plan should create and maintain retrievable exact copies of electronic protected health information. The disaster recovery plan should establish procedures to restore lost data. The emergency mode operation plan should establish procedures for continuing business processes needed to protect electronic protected health information while operating under emergency conditions.
The assessment should address backup scope, backup frequency, encryption, segregation, offline or isolated copies, restoration testing, recovery dependencies, alternate communications, manual clinical workflows, and access to records during downtime. Paper workflows and network shutdown criteria are operational measures rather than expressly named HIPAA Security Rule requirements.
Testing and revision procedures and the assessment of application and data recovery priorities are addressable implementation specifications under the current HIPAA Security Rule. Addressable does not mean optional. The organization must assess whether each specification is reasonable and appropriate and must implement it or document why an equivalent measure or another documented approach is reasonable and appropriate.
HIPAA Breach Notification Rule Assessment
A security incident does not automatically constitute a reportable breach. The organization must determine whether an impermissible acquisition, access, use, or disclosure of unsecured protected health information occurred and whether an exception applies. When no exception applies, the organization must document the applicable breach risk assessment unless it proceeds directly with notification.
The breach risk assessment examines the nature and extent of the protected health information, the unauthorized person who used or received it, whether the information was acquired or viewed, and the extent to which the risk was mitigated. This assessment is separate from the enterprise security risk analysis required by the HIPAA Security Rule.
Under the HIPAA Breach Notification Rule, affected individuals must receive notice without unreasonable delay and no later than 60 calendar days after discovery. A breach affecting 500 or more individuals must be reported to HHS within the applicable 60-day period. Breaches affecting fewer than 500 individuals may be reported to HHS annually within 60 days after the end of the calendar year.
Media notice applies when a breach affects more than 500 residents of a single state or jurisdiction. The notice must be provided to prominent media outlets serving that area. A Business Associate must notify the Covered Entity of a breach without unreasonable delay and no later than 60 calendar days after discovery unless a contract requires a shorter period.
Third-Party and Vendor Risk
The assessment must include electronic protected health information created, received, maintained, or transmitted through Business Associates and subcontractors. The organization should identify vendor services, data locations, access methods, subcontracting arrangements, incident reporting duties, backup responsibilities, return or destruction terms, and dependencies that could affect availability or recovery.
A Business Associate Agreement is required when a vendor performs functions or services involving protected health information on behalf of a Covered Entity or another Business Associate and no regulatory exception applies. The agreement does not replace the need to evaluate risks arising from the service.
Pre-negotiated agreements with breach counsel, forensic firms, restoration providers, and other incident response specialists can reduce procurement delays. The current HIPAA Security Rule does not expressly require advance retainers or master service agreements. These arrangements are preparedness measures that an organization may adopt based on its assessment.
Documentation and Retention
The organization should retain the completed assessment, supporting inventories, data flow records, evidence reviewed, scoring method, findings, approvals, risk management plan, treatment records, exceptions, and validation results. Documentation should identify the assessment period, scope, participants, assumptions, limitations, and systems excluded from review.
HIPAA Security Rule documentation must be retained for six years from the date of creation or the date when it last remained in effect, whichever is later. This retention requirement applies to documentation required by the HIPAA Security Rule. It does not impose a blanket six-year retention period on every technical log, packet capture, or item of network telemetry.
Technical record retention periods should be based on the organization’s risk analysis, operational needs, investigation needs, contractual duties, and applicable legal requirements. The organization should document the selected periods and protect retained records against unauthorized access, alteration, and destruction.
Assessment Review Frequency
The current HIPAA Security Rule does not prescribe a fixed annual interval for completing a risk analysis. A regulated entity must maintain an accurate assessment and conduct periodic technical and nontechnical evaluation in response to environmental or operational changes that affect the security of electronic protected health information.
An organization may adopt an annual review cycle as part of its compliance program. A scheduled review does not replace reassessment after events such as a merger, relocation, new electronic health record, cloud migration, network redesign, acquisition of a medical practice, new Business Associate service, material software change, security incident, or discovery of a previously undocumented data flow.
Risk Assessment and Gap Analysis
A HIPAA gap analysis compares existing practices with specified regulatory requirements or control criteria. A HIPAA Security Risk Assessment identifies electronic protected health information, threats, vulnerabilities, existing safeguards, likelihood, impact, and risk levels across the regulated environment.
A gap analysis may support the assessment, but it does not replace the required risk analysis. A completed checklist showing that policies or controls exist does not establish that the organization evaluated the risks to all electronic protected health information or determined whether the controls reduce those risks to a reasonable and appropriate level.
Common Assessment Deficiencies
Incomplete Scope
An assessment is incomplete when it omits facilities, applications, devices, cloud services, remote users, backup environments, acquired practices, or Business Associate systems that create, receive, maintain, or transmit electronic protected health information.
Control Checklist Substitution
A control checklist does not establish compliance when it records safeguards without identifying the threats and vulnerabilities they address, evaluating their operation, or assigning risk ratings.
Unsupported Risk Ratings
Risk scores should be supported by documented likelihood and impact criteria. Labels such as low, medium, and high provide limited value when the organization cannot show how each rating was determined.
No Risk Management Record
An assessment does not complete the security management process when findings remain unassigned, untreated, or unsupported by documented acceptance decisions. Each material finding should have an owner, treatment decision, target date, and validation record.
Outdated Assessment
An assessment can become inaccurate when the organization changes its systems, services, locations, workforce arrangements, or data flows. A document should not be treated as current solely because management reviews or signs the same findings each year.
HIPAA Security Risk Assessment Record
| Record Element | Expected Content |
|---|---|
| Scope | The record identifies the legal entities, facilities, systems, applications, devices, services, and electronic protected health information included in the assessment. |
| Data Inventory | The record identifies where electronic protected health information is created, received, maintained, transmitted, backed up, archived, and disposed of. |
| Threats and Vulnerabilities | The record connects identified threats and vulnerabilities to affected assets, processes, and electronic protected health information. |
| Safeguards | The record evaluates whether administrative, physical, and technical safeguards are documented, implemented, configured, monitored, and maintained. |
| Risk Ratings | The record applies documented likelihood and impact criteria to determine treatment priorities. |
| Risk Management | The record assigns treatment decisions, owners, target dates, validation methods, and residual risk. |
| Approval | The record identifies the responsible reviewers, approval date, assessment period, assumptions, limitations, and excluded systems. |
| Updates | The record documents reassessment following material operational, technical, legal, or security changes. |
Proposed HIPAA Security Rule Changes
The current HIPAA Security Rule remains in effect. The HIPAA Security Rule Notice of Proposed Rulemaking published in January 2025 has not replaced the current regulation.
The proposal would add more prescriptive requirements for written documentation, asset inventories, network maps, risk analysis content, risk management planning, incident response, contingency planning, testing, and other safeguards. It would also remove the current distinction between required and addressable implementation specifications, subject to stated exceptions.
Regulated entities should base present compliance decisions on the current HIPAA Security Rule while tracking the rulemaking process. Existing assessments, risk management records, incident procedures, backup plans, recovery procedures, and documentation can be structured so that later revisions can be made without rebuilding the compliance program.
HIPAA Risk Assessment FAQs
What are the most important risks to look out for in a HIPAA risk assessment?
While you should be looking at all risks to the confidentiality, integrity, and availability of PHI, the top issues investigated by the HHS Office of Civil Rights include impermissible uses and disclosures, access controls, the failure to implement the administrative safeguards of the Security Rule, and disclosures of PHI beyond the minimum necessary.
Who is responsible for conducting HIPAA risk assessments?
Covered Entities and Business Associates are required to appoint (or designate the role of) a HIPAA Security Officer. Covered Entities are also required to appoint (or designate the role of) a HIPAA Privacy Officer. It will be the responsibility of these Officers to ensure risk assessments are conducted – even if they don´t conduct them personally.
What are “technical and non-technical vulnerabilities”?
Technical vulnerabilities relate to information systems, their design, configuration, implementation, and use. Non-technical vulnerabilities may include ineffective or non-existent policies and procedures, the failure to train employees on policies and procedures, or the failure of employees to comply with policies and procedures.
Should the content of HIPAA training courses be analyzed in a risk assessment?
The Administrative Requirements of the Privacy Rule state that Covered Entities must train workforces on policies and procedures “as necessary and appropriate” for members of the workforce to carry out their functions. Consequently, the content of HIPAA training courses should be relevant to workforce functions.
How does a HIPAA privacy risk assessment differ from a HIPAA security risk assessment?
Whereas a HIPAA security risk assessment should focus on the administrative, physical, and technical safeguards of the Security Rule, a HIPAA privacy risk assessment should focus on ensuring that uses and disclosures of non-electronic PHI comply with the requirements of 45 CFR Subpart E – the Privacy of Individually Identifiable Health Information.
What is “unsecured PHI” in HIPAA privacy assessment following a breach of PHI?
Unsecured PHI is Protected Health Information that has not been rendered unusable, unreadable, or indecipherable by encryption. If data taken by an unauthorized individual is encrypted – and the decryption key is secured separately – there is a low probability that PHI has been compromised and, while the breach should still be documented, there is no need to report it to HHS.
How should a Covered Entity determine risk levels in a risk analysis?
One of the simplest ways to determine risk levels in a risk analysis is to assign the likelihood of a risk occurring a number between 1 and 5 and the impact the event would have on the Covered Entity a number between 1 and 5. Then multiply the two numbers together to determine whether the risk level is low, medium, high, or critical.
What should be included in a risk assessment for all elements of HIPAA compliance?
A risk assessment for all elements of HIPAA compliance should include the Privacy, Security, and Breach Notification Rules – inasmuch as members of the workforce need to know who to report a breach to. Depending on the nature of the organization’s activities, it may also be necessary to include the Administrative Requirements (Part 162 of the Administrative Simplification Regulations).
What risks are associated with the Administrative Requirements?
The risks associated with the Administrative Requirements are purely compliance risks. While non-compliance with the Administrative Requirements will not result in an impermissible disclosure or data breach, if a complaint about non-compliance with this Part is received by the Centers for Medicare and Medicaid Services, the agency has the authority to enforce a Corrective Action Plan and/or issue a civil monetary penalty.
How can you identify risks associated with Privacy Rule compliance?
Risks associated with Privacy Rule compliance generally fall into two categories – those relating to individuals´ rights (i.e., access requests, requests for an accounting of disclosures, etc.) and those relating to impermissible uses and disclosures of PHI. It is important that policies and procedures are put in place to ensure compliance with the Privacy Rule and that members of the workforce are trained on the policies and procedures.
Is Privacy Rule compliance necessary for Business Associates?
Privacy Rule compliance is necessary for Business Associates “with respect to the Protected Health Information of a Covered Entity” (§164.500(c)). Therefore, before a Covered Entity shares PHI with a Business Associate, the Covered Entity must conduct due diligence to ensure the Business Associate has the necessary safeguards in place to protect the privacy of Protected Health Information.
Do Business Associates have to comply with the Administrative Requirements?
Business Associates only have to comply with the Administrative Requirements if they are performing a service for a Covered Entity covered by 45 CFR Part 162. These services are usually related to eligibility checks, authorizations for treatment, and billing, and compliance with this part is only necessary if an organization conducts these transactions electronically.
How does the Department for Health and Human Services define “reasonable and appropriate”?
The Department for Health and Human Services does not define “reasonable and appropriate” in the context of HIPAA risk assessments. However, “reasonable” is generally interpreted to mean “diligent”, while “appropriate” is relevant to an organization´s “size, capabilities, and complexities, it´s existing technical, hardware, and software infrastructure, and the likelihood and possible impact of potential risks to Protected health Information”.
What sanctions would a Covered Entity apply to a workforce member for a HIPAA violation?
The sanctions a Covered Entity would apply to a workforce member for a HIPAA violation depend on the nature of the violation, the contents of the Covered Entity´s sanctions policy, and the workforce member´s previous conduct. Generally, a minor HIPAA violation will result in a verbal warning and/or re-training, while a more serious – or repeated – violation could result in termination of contract.
How often should an organization review records of information system activity?
The frequency that an organization should review records of information system activity will be determined by a risk assessment, the technologies already in place to identify anomalies, and the complexity of the organization’s information systems. For example, larger organizations will probably have SIEM systems deployed to automatically detect irregular activity, while a smaller organization might have to outsource reviews to a third-party IT consultant.
How do you calculate the impact of a vulnerability being exploited?
The way to calculate the impact of a vulnerability being exploited is to consider what the consequences would be of a specific event. For example, if the organization´s Electronic Health Records were disabled in a ransomware attack due to a vulnerability in password management procedures, the consequences would be the non-availability of PHI.
This would have a significant impact on a healthcare organization’s ability to treat patients; and, even if back-ups of the PHI are available, the organization would have to consider the impact on operations of restoring systems from the back-ups. Therefore, it would be better to address the vulnerability rather than prepare for the consequences.
How often should you review HIPAA risk assessments?
HIPAA risk assessments should be reviewed at least annually and – as recommended by HHS – before new technologies are implemented or business operations are revised. Additionally, although the responsibility for reviewing risk assessments lies with the privacy or Security Officer who originally conducted the risk assessment, it can be useful to periodically engage a third-party compliance expert to review assessments and analyses to ensure nothing is missed.
How can Covered Entities “reasonably safeguard PHI” in compliance with the Privacy Rule?
Covered Entities can reasonably safeguard PHI in compliance with the Privacy Rule by ensuring all members of the workforce are aware what uses and disclosures of PHI are permitted by the Privacy Rule. Additionally, they should be told via training what uses and disclosures are not permitted by the Privacy Rule without a written authorization from the subject of the PHI.
What is a HIPAA risk management plan?
A HIPAA risk management plan is a plan detailing how an organization identifies risks, assesses the risks, and decides what measures to implement to reduce risks to a reasonable and appropriate level. Thereafter, the plan identifies individual responsibilities for reviewing the HIPAA risk management plan to ensure it is kept up to date and in line with other regulatory requirements (i.e., CMS´ Emergency Preparedness Plan).
What is the difference between a HIPAA risk assessment and a CMS Emergency Plan risk assessment?
The difference between a HIPAA risk assessment and a CMS Emergency Plan risk assessment is that the purpose of HIPAA is to protect the privacy of PHI and ensure the confidentiality, integrity, and availability of ePHI at all times, whereas the purpose of CMS´ Emergency Plan is to safeguard human resources, maintain business continuity, and protect physical resources in an emergency or natural disaster.
What are the five principles of a HIPAA risk assessment?
The five principles of a HIPAA risk assessment are the same as any other type of risk assessment. 1. Identify risks and vulnerabilities. 2. Assess the risks and vulnerabilities. 3. Control the risks and vulnerabilities (to a reasonable and appropriate level). 4. Document the findings and the actions taken. 5. Review the risk assessment.
What is the “flexibility of approach” in the Security Rule?
The flexibility of approach in the Security Rule is a standard in the General Rules (§164.306) which allows Covered Entities and Business Associates to decide what security measures to implement to comply with the Administrative, Physical, and Technical Safeguards. The reason it exists is because HIPAA is technology neutral and does not favor one type of security measure over another.
In the Security Rule, What does termination procedures mean?
In the Security Rule, termination procedures relate to removing an individual’s access to ePHI when they leave the organization or move to another role within the organization which does not have the same access requirements. For example, if a healthcare professional leaves to work in another hospital, their login credentials have to be deleted from systems to prevent the healthcare professional logging in remotely or another employee using their credentials fraudulently.
If an employee violates HIPAA and no risk assessment has been conducted, who is at fault?
If an employee violates HIPAA and no risk assessment has been conducted, it does not necessarily mean the Covered Entity or Business Associate is at fault. Covered Entities and Business Associates would only be expected to assess risks associated with reasonably foreseeable events; and, if the HIPAA violation was not reasonably foreseeable, the employee will likely be held accountable.
However, if the event that led to the HIPAA violation was reasonably foreseeable – and either it was omitted from the risk assessment or the decision was made not to safeguard against it happening – accountability will be determined by the nature of the event and whether the actions of the employee were unreasonable and inappropriate in the circumstances.
