HIPAA §164.308 Administrative safeguards.
(a) A covered entity or business associate must, in accordance with §164.306:
(1) (i) Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.
(ii) Implementation specifications:
References 164.308 (a)(1)(ii)(A) Risk Analysis: What follows are the steps the NIST recommends for conducting a Risk Assessment under SP 800-30 Rev. 1 All of these have now been automated into Expresso, our SaaS Compliance software.
Description:What follows are the steps the NIST recommends for conducting a Risk Assessment under SP 800-30 Rev. 1 All of these steps have now been automated into Expresso, our SaaS Compliance software.
Step 1 in a Risk Assessment
Process: The data gathering step is essentially an inventorying process pertinent to the Security Objects you are interested in capturing (.e., Operations, Assets, and Individuals). Once a complete set of Security Objects have been identified then, and only then, do you update the TVRs that may apply to them.
Tracking: Capture the Security Objects inventory in a database; once captured this inventory becomes a foundational part of your “As Is” documentation. Scorecards are useful tools to identify your progress completing your Risk Assessments as well as Remediation efforts. Often Senior management is interested in understanding where and how far the compliance effort has progressed. The “As Is” environment should be documented using one or more databases, network diagrams, and other tools that describe the current (first Risk Assessment) or modified (subsequent Risk Assessment) “As Is” Operational Environment. The results of the inventorying process should be stored in your Compliance Repository.
Step 2 Assess Threats & Vulnerabilities
Process: Threats and Vulnerabilities should be gathered using recommended (TBD) Vulnerability scanning tools and alerts from authoritative sources (e.g., vendors, industry, government, etc.). Commercial scanning software should be used for automated Threat/Vulnerability testing of your networks and other information assets. Scanning for new Threats and Vulnerabilities should be done, minimally on a monthly basis, and more frequently at the discretion/recommendation of your CO.
Tracking: New/updated Threats, Vulnerabilities, and impacts on your organization should be captured in your TVRs (“Threats, Vulnerabilities, Impacts and Risks”) database. Your TVRs should be stored in and/or accessed from your Compliance Repository.
Step 3 in an RA is to assess the current Security Controls
Process: You should add or modify Security Controls on an as needed basis in response to a changing TVR landscape. You should develop, implement, and maintain a TVR alert system that gathers data from authoritative sources (e.g., government, industry, etc.). As an evergreen process, you should review all of your existing Security Controls each time we conduct a Risk Assessment.
Tracking: Each time you implement a new Security Control, or modify an existing one, your Security Controls database should be updated, including whether the new or modified Security Control meets a requirement dictated by applicable law. Your Security Controls database is stored in your Compliance Repository.
Step 4 in an RA is to determine the likelihood that a specific Threat should exploit a particular Vulnerability
Process: A Risk Assessment should be conducted each time there are material changes to applicable law or significant changes to your Operational Environment; all your Threat/Vulnerability pairs should be reviewed TVRs should be updated on an ongoing basis (i.e. outside of the scope of an RA) as required. The quickly evolving Threat Landscape may require updates on a monthly basis. Your CO and CIO should use these monthly reports to identify Threat/Vulnerability pairs that require immediate attention. Threat/Vulnerability pairs that result in the determination of a High or Medium level of Risk should be acted upon immediately.
Tracking: TVRs should be tracked via your TVR database.Operations, assets and Individuals should be updated in your TVR database on an as needed basis. All RA tools, reports, and databases should be stored and/or accessible from your Compliance Repository.
Step 5 in an RA is to “calculate” the Impact that an Exploitation should have on your Operational Environment.
Process:An RA should be conducted each time there are material changes to applicable law or significant changes to your Operational Environment; all your Impact calculations should be reviewed at that time. TVRs should be updated on an ongoing basis (i.e. outside of the scope of an RA) as required. The quickly evolving Threat Landscape requires updates on a monthly basis at a minimum. Our CO and CIO should use these monthly reports to identify Threat/Vulnerability pairs that require immediate attention, including calculation (or re-calculation) of the Impact measure to determine the potential Risk. Threat/Vulnerability/Impact pairs that result in the determinations of a High or Medium level of Risk should be acted upon immediately.
Tracking: TVRs should be tracked via your TVRs database. Operations, assets, and Individuals should be updated in your TVR database on an as needed basis. All RA tools, reports, databases should be stored and/or accessible from your Compliance Repository. Don’t forget that you also need a critical application list from which you should prioritize those applications and data that cannot be out of service for long periods of time.
Step 6 in an RA is to determine the level of Risk associated with Threat/Vulnerability pair, taking into consideration the Impact to the Organization.
Process: A Risk Assessment should be conducted any time there are material changes to applicable law or significant changes to your Operational Environment; all known Risks should be reviewed at that time. Each Risk, in addition to being assigned a Risk level of High, Medium, or Low should include a narrative that provides the executive team with the appropriate context for making Risk mitigation decisions. The CO should prepare a report for the executive team following each RA to obtain the budget necessary to address identified Risks, with a focus on Risks identified as High or Medium. TVRs should be updated on an ongoing basis (i.e., outside of the scope of an RA) as required. The quickly evolving Threat Landscape requires updates on a monthly level at a minimum to identify new and/or unanticipated Risks. Your CO should use these monthly reports to identify Risks that require immediate attention.
Tracking: TVRs should be tracked via your TVR database. Operations, Assets and Individuals should be updated in your TVR database on an as needed basis. All RA tools, reports, and databases should be stored and/or accessible from your Compliance Repository.
Step 7 in an RA is to document new/modified Security Controls that should help mitigate Risks to levels that are “reasonable and appropriate” for your Organization.
Process:You should add or modify Security Controls on an as needed basis in response to a changing TVR landscape and document additional Risks in your TVRs database. You should develop, implement, and maintain a TVR alert system that gathers data from authoritative sources (e.g. government, industry, etc.). You should review all Security Controls each time we conduct a Risk Assessment.
Tracking: Your CO should track additional Security Controls as they are applied to their respective Security Objects. Your CO is also responsible for ensuring that these Controls have their desired mitigation effect.
(A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.
References 164.308 (a)(1)(ii)(B) Risk Management: What follows are the steps the NIST Risk Management Framework ("RMF") recommends for maintaining a Risk Management Program.
Description: Step 1 is to conduct a Risk Assessment as discussed above.
Step 2 Simplify
Process: Prioritize the Risk identified during the Risk Assessment step. Select those Security Controls, based on your prioritization scheme, that are likely to have the most Risk Mitigation return on investment (“ROI). Select one or more Security Controls for each prioritized Risk. Capture government, industry and/or other reference materials that support each Security Control selected.
Tracking: Document each Security Control selected for a given Risk.Create a summary “Selected Controls” report and store it in your Compliance Repository.
Step 3 Protect
Process: Implement the Security Controls identified. Test each Security Control implementation to ensure that it functions as anticipated in a production environment and revise as required to meet the objective.
Tracking: Document each Security Control “as implemented” for a given Risk. Create a summary “Implemented Controls” report and store it in your Compliance Repository.
Step 4 Monitor
Process: Develop, deploy and maintain a continuous monitoring methodology and corresponding technologies and resources. On an as needed basis, report on your Operational Environment security status to the executive team.
Tracking: Document the monitoring methodology “as implemented” for your Operational Environment. Create an Operational Environment security status (“Monitoring”) report and store it in your Compliance Repository.
Step 5 Report
Process: Develop, deploy and maintain a Risk Management internal audit methodology using Checklist Items. Conduct an audit “postmortem” after each audit to determine your audit methodology’s effectiveness. Modify your audit methodology according to the results of the postmortem.
Tracking: Document the monitoring methodology “as implemented” for your Operational Environment. Create an internal audit report and store it your Compliance Repository.
Step 6 Repeat
(B) Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).
References 164.308 (a)(1)(ii)(C) Sanction Policy:
Process: Each violation and/or alleged violation (collectively “Violation”) should be documented according to your Documentation Policy. Your CO is charged with conducting a thorough investigation of each Violation. On a yearly basis, or more often at the discretion of your CO, the CO should submit a report to the executive team summarizing the violations for the period in question. Your CO is charged with the responsibility for detecting patterns of Violations that may warrant additional training and/or modifications to your policies and procedures.
Tracking: Violation documentation should be filed in the Workforce member’s personnel folder or the business associate’s electronic folder in your Compliance Repository. Verification that your Violations process is managed according to your Policy should be accomplished by periodic random reviews of Violation documentation. Workforce members determined to have violated the Security Rule should be sanctioned according to your Sanction Policy, with all resulting documentation stored in the member’s personnel folder in your Compliance Repository. CO reports summarizing Violations should be stored in your Compliance Repository.
Sanction Policy: What is this? Your organization must have a process for sanctioning repeated violations of the Security Rule. Without a Sanction Policy you have no effective of standardizing the sanction process which can lead to a multitude of problems. Generally, the Human Resources department should be involved but they have no way of knowing what a Security Rule violation means. The compliance team must draft the Policy and work with Human Resources to implement it. If employees and/or business associates are free to violate without repercussions, then your initiative is toothless and basically worthless.
(C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity or business associate.
References 164.308 (a)(1)(ii)(D) Information System Review:
Process: Specific individuals should be designated with the responsibility of reviewing Information System audit logs at a minimum of once weekly and whenever a System alert warrants it. Individuals so identified should be trained periodically to ensure their awareness of new and/or emerging Threats and Vulnerabilities in your Operational Environment. On a monthly basis, or as warranted by events, these individuals should report to the CO/CIO on your Operational Environment’s security status. On an as needed basis, but no less than once a year, the CO/CIO should report to the executive team on your Operational Environment’s security status. On an as needed basis, your CO/CIO should mandate that an audit of monitoring activities be conducted.
Tracking: System audit logs should be backed up on a nightly basis and maintained as mandated your Documentation Policy. All reports to the CO/CIO and the executive team should be kept in your Compliance Repository. All audit reports should be stored in your Compliance Repository.
System Review: What is this? You must review the logs that are produced by your information systems to detect attempted breaches, exfiltration, and any number of other violations. In practice this becomes a daunting task for the information technology department because today’s applications produce far too many alerts, many of which are innocuous. After business communications, phishing is the second largest vector by which the “bad guys” penetrate your network. The average amount of time (circa 2021) to discover a breach is 127 days.This is a mind-boggling number because it implies that the “bad guys” have had ample time to explore vulnerabilities before launching their respective payloads.In practice you support teams must become adept at discerning those small number of incidents that could lead to a breach, from the thousands of others that won't. It must become adept at separating the signal from the noise.
(D) Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
References 164.308(2) Assigned Security Responsibility:
Process: The executive team should conduct team interviews in order to select a new CO whenever a new CO is to be named. In the case where your current CO is incapacitated, or has decided to leave the Organization, the executive team should name an interim CO until a designated officer has been named. An interim CO may be a trusted business associate (e.g., security consultant) of the Organization. The executive team should ensure that the designated CO has adequate resources to administer your security program as required by applicable law.
Tracking: The performance of your CO should be tracked through various mechanisms, including annual management reviews and outside third-party audits on an as needed basis. The executive team may independently follow-up with staff and other stakeholders to determine the effectiveness of your security program. Yearly management reviews should be documented according to your Documentation Policy.
Assigned Responsibililty: What is this? Someone within your organization must be assigned the primary responsibility for complying with the Rule. This assignment must be formalized in their personnel file. Generally, this should be your CIO, CISO, or some other technical member of the management team. However, for small organizations this role could be assigned to the office administrator. Whomever is the assignee they must have the required budget and training to fulfill their responsibilities for an organization of your size, complexity, sophistication, etc. Small organizations may in fact assign a single individual to become the Privacy and Security Officer. Regardless, functions and procedures must be formalized.
(2) Standard: Assigned security responsibility. Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the covered entity or business associate.
(3) (i) Standard: Workforce security. Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information.
(ii) Implementation specifications:
References 164.308 (3)(ii)(A) Information System Review:
Process: Requirements for protecting ePHI according to your Policy should be included as part of job descriptions for all new hires. New hires should be required to sign an employment letter indicating that they have read your HIPAA Privacy and Security policies and agree to abide by same. Existing Workforce members and new job hires should be provided training specific to their job function as it relates to protecting ePHI. Your CO, together with Human Resources, should periodically review roles and responsibilities and job descriptions to ensure they remain consistent with your Operational Environment. Your CO should develop and maintain a methodology by which ePHI access is granted.
Tracking: Documentation regarding ePHI access, including the manner by which ePHI access is granted, given existing roles and responsibilities and job functions, should be maintained in your Compliance Repository according to your Documentation Policy. Training results for Workforce members required to understand how ePHI access is granted and managed should be stored in your Compliance Repository.
Authorization: What is this? This requirement asks the organization to formalize the processes by which authorization to access, update, and delete PHI is granted (and removed). This formalization requires not only a chain of authority signoff, but also documentation of same. In too many organizations this function is processed informally. Subsequently, when a Workforce member leaves the organization, the organization should be sure what applications, devices, and infrastructure the member had access to. In addition, work they had completed or that was in process should be handed off to their replacement.
(A) Authorization and/or supervision (Addressable). Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
References 164.308 (3)(ii)(B) Workforce Clearance:
Process: Background checks should be conducted by individuals trained to perform them using a methodology to be developed by your CO in collaboration with Human Resources. The individual that conducts the check must “sign off” indicating that the methodology was followed or why a “work around” was required. Your CO must “sign off” on the background check before forwarding the documentation to Human Resources.
Tracking: Background check documentation should be maintained by Human Resources and in your Compliance Repository in secured “need to know” manner. The methodology used to conduct background checks should be stored in your Compliance Repository. Periodically, at the discretion of your CO, your online services should be reviewed to ensure they continue to meet your security objectives.
Workforce Clearance: What is this? This requirement is asking the organization to formalize the clearance of its Workforce members for known potential negative issues (e.g., incarceration). It is not necessarily meant to exclude candidates, but at least the organization needs to be able to make an informed decision as to who they are hiring. More of a nuanced issue is 1099 MISC independent contractors that work on site because they are usually not considered to be Workforce members (there are some exceptions) yet still are often provided the same kinds of access to PHI. It’s up to the organization if they want to perform clearance checks in these instances.
(B) Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
References 164.308 (3)(ii)(C) Termination Procedures
Process: Process: Your CO is responsible for creating and maintaining the ePHI termination process and related documentation.Each time an individual terminates the process should be followed and the appropriate signoff obtained. Yur CO may delegate this responsibility but is still required to sign off on terminations.
Tracking: All ePHI access granted to an individual should be tracked in a single document. This document should also track access control devices such as phones, tablets, laptops, PCs, badges, keys, and cards assigned to the individual. Doing so should create a “single version of the truth” with respect to ePHI, and other access, provided to the individual. Security documentation for individuals should be stored in your Compliance Repository.
Termination Procedures: What is this? This requirement is mandating that the organization protect PHI from potentially disgruntled Workforce members and contractors by removing all access to PHI that has been granted. It should go without saying that if the access was not captured in a formal way, then it should be next to impossible to fulfill this requirement in a timely manner. Time is of the essence. This disgruntled individual is likely to want to extract some sort of retribution sooner rather than later. However, terminating their access to applications is necessary but not sufficient, access to all devices that contain PHI must also be terminated.
(C) Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of, or other arrangement with, a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section.
(4) (i) Standard: Information access management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.
(ii) Implementation specifications:
References §164.308(a)(4)(ii)(A) Isolating HCC functions.
Process: If there is no HCC component that is part of your Organization, then your CO should document that fact. If there is an HCC component, then your CO and CIO are tasked with ensuring that a Chinese wall (“Wall”) is built between the two components such that there is no intermingling of ePHI between the two. The methodology to erect and maintain the Wall should be captured in a separate document and your CO/CIO should present to the executive team the strategy for maintaining the Wall’s impermeability over time.
Tracking: Where applicable, all HCC privacy and security functions should be maintained and tracked separately as if the two components of the Organization were separate business entities. Each component of the Organization should have its own Compliance Repository. Each component should have separate systems for tracking security incidents, audit logs, etc.
(A) Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.
References §164.308(a)(4)(ii)(B) Access Authorization.
Process: Create and maintain an inventory of information assets that facilitates granting access to ePHI. Determine, by information asset (hardware and software) what access control method ("ACM") should be used for each Information System. Where a practical choice is available, your CO/CIO should use their professional judgment, considering industry best practices, to select an appropriate ACM, otherwise the ACM inherent in the COTS offering should be selected. Over time your CO and CIO should investigate two factor authentication and single sign on strategies to reduce access administration while improving your ePHI access strategy.
Tracking: An inventory of information assets should be maintained in your Compliance Repository. Selected ACMs should be reviewed periodically to determine whether or not they remain consistent with your privacy and security objectives. On an as needed basis, your CO and CIO should make recommendation to the executive team regarding the effectiveness of your ePHI access strategy, especially with respect to external stakeholders.
(B) Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
References §164.308(a)(4)(ii)(C) Access establishment and modification.
Process: Process: Your CO should create and maintain an information access request form to be used for both Workforce members and business associates. The information asset for which access is requested must be an asset already contained within your information asset inventory. If the information asset requested is not in your inventory then the CO is responsible for updating your inventory prior to granting access. The CO, or a delegate, must sign off on the information access request form. Workforce members and business associates must also sign off on the information asset request form and provide a short description as to why access is required. A business associate agreement must be in place before access is granted to a business associate.
Tracking: Signed electronic copies of your access request forms must be stored in your Compliance Repository. Access request forms should be reviewed (i.e., sampled) as part of all Risk Assessments.
(C) Access establishment and modification (Addressable). Implement policies and procedures that, based upon the covered entity's or the business associate's access authorization policies, establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process.
(5) (i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).
(ii) Implementation specifications. Implement:
References §164.308(a)(5)(ii)(A) Security reminders.
Process: Process: Your CO should provide privacy and security reminders at least once per month and more often if warranted. In order to overcome “alert fatigue” your CO must develop a taxonomy for identifying the criticality of reminders.
Tracking: At least once per year, or when asked to do so by the executive team, your CO should seek feedback regarding the effectiveness of your Reminder System. All Security Reminders sent should be logged in a special folder and kept for a duration of time consistent with your Documentation Policy.
Security Reminders: What is this? Security reminders are imperative because the Workforce may easily forget, for example, what to look for in an email that appears suspect; who to inform; how to proceed; etc. This is just an illustrative example. As part of Subscription we send out reminders for you once monthly or when anything of significance occurs that requires your immediate attention (e.g., the pending release of the FINAL 2021 Privacy Rule when released).
(A) Security reminders (Addressable). Periodic security updates.
References §164.308(a)(5)(ii)(B) Protection from malicious software.
Process: Process: Your CO/CIO should ensure that you have an update-to-date subscription (including an always current signature file) with your anti-virus provider. Your security training should be updated to include best practices for detecting and preventing malicious software from entering your Operational Environment.
Tracking: Tracking: Security training should be stored in your Compliance Repository. Best practices for detecting and preventing malicious software from entering your Operational Environment should be distributed through your Security Reminder system and stored in your Compliance Repository.
Protection Malicious Software: What is this? What this means should be obvious by now, but the need to protect against malicious software and protect against other software that may harm your operational environment under the Security Rule is an important Security Rule regulation. This type of software ranges from protection against viruses, Phishing, etc. It also may include such things as intrusion detection systems and more elaborate protection software depending on the Security Rule’s “Flexibility Principle.”
(B) Protection from malicious software (Addressable). Procedures for guarding against, detecting, and reporting malicious software.
References §164.308(a)(5)(ii)(C) Log-in monitoring.
Process: Process: Your CO and CIO should ensure that your hardware and software platforms are instrumented with the capability to capture and report on failed login attempts. An individual should be assigned the responsibility of reviewing alerts and audit logs to improve your Organization’s ability to distinguish between routine user error (e.g., forgotten passwords and logins) and attempted intrusions.
Tracking: Tracking: Tracking: Login alerts should be transmitted using your email system and stored in an appropriately name folder. The number and kinds of login alerts should be reported by Information System support staff to your CO/CIO on a weekly basis at a minimum, or as warranted when events dictate (e.g., evidence of apparent malicious conduct shall be reported to the CO immediately), so that the organization can track trends over time. Login alert reports should be stored in your Compliance Repository.
Login Monitoring: What is this? Monitoring login attempts is a must do to prevent unauthorized access to your network, applications, and devices. This is true even though it’s often the case that a user may have simply forgotten their credentials; in which case two-factor authentication that allows the user to reset their own password may reduce the support overhead dramatically.
(C) Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting discrepancies.
References §164.308(a)(5)(ii)(D) Password management.
Process: Process: Your security training should be updated to instruct your Workforce regarding the use of strong passwords. Where possible, your CO/CIO should ensure that enforcement of your strong password Policy should be built into your hardware and software platforms, including mobile devices. Your CO/CIO should periodically conduct “penetration tests” to ensure that your strong password policy is meeting your security objectives.
Tracking: Tracking: Tracking: Tracking: Best practices regarding strong passwords should be periodically sent out through your Security Reminder system. Strong password best practices should be stored in your Compliance Repository. Penetration test results should be stored in your Compliance Repository.
Password Management: What is this? By now the use of “strong passwords” has become a de facto industry standard. What this means is using a combination of letters and symbols that are not easily guessed and providing a password that is long enough to make it difficult for brute force hacking to succeed. Of course, each security measure usually comes at a price. Strong passwords are difficult to remember so your organization should consider using password management software the helps solve this problem. The reality, unlike days past, all of us now use literally dozens of services to perform your jobs and it becomes next to impossible to remember all of your passwords.
(D) Password management (Addressable). Procedures for creating, changing, and safeguarding passwords.
Incident Management: What is this? In organizations thousands of incidents occur each day that have nothing to do with PHI. It is impossible to track each incident. The incidents that we believe should be logged are those that appear suspicious for one reason or another. After that, then IT and the Compliance Officer must determine if this incident is related to PHI; in which case more investigation is required. Expresso® contains a “Breach Notification Wizard” that helps walk you through this process. That is, to determine if the incident in question is a HIPAA Breach. Remember, that whether a Breach occurred is a matter of law and should be left to counsel to make the ultimate decision. The Compliance staff’s job is to gather the facts.
(6) (i) Standard: Security incident procedures. Implement policies and procedures to address security incidents.
References §164.308(a)(6)(ii) Response and reporting.
Process: Process: Process: Log each Security Incident (“Incident”) in your Incident Tracking Database and create an Incident Document for each Incident logged. Decide, based on the initial Incident investigation, which Incidents pertain to Information Systems containing PHI and hence require further review. Notify your CO regarding any Incident that relates to an Information System containing PHI so that your CO may perform a breach notification analysis in order to determine if notification is triggered. If the CO’s initial review indicates that notification may be triggered, then your CO must notify the executive team and your legal counsel immediately. The final decision as to whether to invoke your breach notification process should be made by the executive team in collaboration with your CO and counsel.
Tracking: Tracking: All Incidents should be logged in your Incident Tracking Database. An Incident Document should be created for each Incident logged. Yur breach notification analysis should be captured in the Incident Document with a reference to supporting documentation where applicable. Your Incident Documents and your Incident Tracking Database should be stored in your Compliance Repository. 3LP's Expresso SaaS Compliance Software now automates this process for you, including calculating federal and state notification dates.
(ii) Implementation specification: Response and reporting (Required). Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.
(7) (i) Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.
(ii) Implementation specifications:
References §164.308(a)(7)(ii)(A) Data backup plan.
Process: Your CO and CIO should review your Information System inventory created/updated in your last Risk Assessment and designate which systems are mission critical. Your CIO should select backup software capable of meeting your backup plan objectives, including the ability to backup Information System data to Internet storage, using one of the leading providers of same. Your CO should ensure that a business associate agreement is in place with all storage providers (e.g., Internet and “brick and mortar”). Your CIO should designate an individual, or a team of individuals, to implement your backup plan and to review backup logs on a daily basis, taking appropriate responsive action where required. The individual or team designated by your CIO should conduct quarterly restoration tests to ensure that your backup plan is functioning according to specification.
Tracking: Copies of your backup logs reports should be stored in your Compliance Repository. Quarterly backup restoration reports should be stored in your Compliance Repository. Any anomaly found in your daily backup review should be reported immediately to your CO/CIO.
Data Backup Plan: What is this? Having a backup plan in place is one of the requirements of meeting the Security Rule’s Contingency Standard. Most organizations have backup processes, but they are often not well documented, nor tested on a regular basis. This is true especially for smaller organizations. This poses a serious organizational issue when Workforce members responsible for such tasks leave the organization. In addition, having a backup plan is only one of five Controls necessary to comply with the Contingency Standard.
(A) Data backup plan (Required). Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.
References §164.308(a)(7)(ii)(B) Disaster recovery plan.
Process: Your CO and CIO are responsible for drafting and maintaining your DRP and for requesting the budget necessary to execute on same. In addition to the core elements, your DRP must include requirements specific to your Operational Environment, including but not limited to specifics with respect to your geographic location(s). At a minimum of once a year, or more often as warranted, your CO/CIO shall report to the executive team regarding your DRP’s state of readiness. Your DRP must be updated and “live tested” after significant changes to your Operational Environment, otherwise table-top testing or live testing is a decision to be made by your CO/CIO. A postmortem review of your DRP is required after every disaster in which your DRP is invoked or readied for invocation.
Tracking: Your DRP and all test results related to same should be stored in your Compliance Repository. DRP readiness reports should be stored in your Compliance Repository by year. Contracts with third parties germane to your DRP should be stored in your Compliance Repository and listed as “related information” in your Information Systems inventory as updated during each Risk Assessment.
Disaster Recovery Plan: What is this? A Disaster Recovery Plan (“DRP”), although it a may include a data backup plan within it, is much broader than the latter. A DRP requires you to consider a remote site operations plans should a disaster like Katrina occur, an Applications Criticality List, and Testing and Revision Procedures. In short, a DRP is considerably more comprehensive than a data backup plan and should be, at a minimum, tabletop tested yearly. Some organizations maintain their PHI on cloud-based software, in which case, they must work with their vendor to understand how and when disasters are handled.
(B) Disaster recovery plan (Required). Establish (and implement as needed) procedures to restore any loss of data.
References §164.308(a)(7)(ii)(C) Emergency mode operation plan.
Process: Your CO and CIO are responsible for drafting and maintaining your EM strategies and for incorporating same into your DRP. Your EM strategy will define emergency contingencies for each Information System in your inventory and provide cross Information System contingencies where practical. Your EM strategy will identify the point in the contingency continuum wherein sufficient local failures, or an extended duration, actually trigger your DRP. Your EM strategy will be tested as part of your DRP testing and more often when warranted and/or mandated by the executive team.
Tracking: Your EM plan and all test results related to same will be stored in your Compliance Repository. EM readiness reports should be stored in your Compliance Repository by year. Contracts with third parties germane to your EM should be stored in your Compliance Repository and listed as “related information” in your Information Systems inventory as updated during each Risk Assessment.
Emergency Mode Operations Plan: What is this? What this means is that should an event like Katrina occur you have a plan in place to continue to serve your stakeholders at a different location. Patients are obviously in dire need of healthcare when such events occur and if your current location has been devasted and there is no remote site plan, then patients are left on their own to manage the consequences, which often means going without care.
(C) Emergency mode operation plan (Required). Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.
References §164.308(a)(7)(ii)(D) Testing and revision procedures.
Process: Your CO/CIO should take an iterative approach to DRP testing ensuring that various components of the plan work effectively (e.g., alternative communications channels and emergency mode) before performing comprehensive DRP testing. Information Systems identified as critical should be DRP tested for recovery before testing less critical systems. Once component testing and remediation has occurred, then an end-to-end real time DRP test should be conducted and systemic remediation should occur. Component DRP testing should occur periodically to ensure that no significant changes to your Operational Environment have broken your DRP readiness. A significant enough change to your Operational Environment (e.g., moving the primary site and/or merger and acquisitions) shall trigger the need for another DRP end-to-end real time test. On a yearly basis, or as events warrant, your CO/CIO will report to the executive team regarding your DRP state of readiness.
Tracking: Your DRP component tests and remediation plans should be stored in your Compliance Repository. Your DRP and all real time test results should be stored in your Compliance Repository along with systemic remediation plans. DRP executive team readiness reports should be stored in your Compliance Repository annually.
Testing and Revision Procedures: What is this? Without testing the Controls that are required for your organization to meet the Contingency Standard there is simply very little probability that it should function as required should the need arise. Full scale physical simulation of these Controls is obviously the gold standard. However, for most organization this is not economically or operationally feasible. In this case tabletop testing at least once a year is the recommended alternative.
(D) Testing and revision procedures (Addressable). Implement procedures for periodic testing and revision of contingency plans.
References §164.308(a)(7)(ii)(E) Applications and data criticality analysis.
Process: Key members of your Workforce should collaborate in assigning a criticality indicator to each Information System in your Inventory. Criticality indicators should be assigned and reviewed, whenever practical, during each Risk Assessment or upon deployment. Your CO/CIO should ensure that your DRP correctly reflects which Information Systems should be re-instantiated and in what order, with Information Systems with a criticality indicator of High being “first in line.” On a yearly basis, or as events warrant, our CO/CIO should report to the executive team regarding our DRP state of readiness, including the assignment of criticality indicators.
Tracking: Your Information Systems inventory, along with assigned criticality indicators, should be stored and maintained in your Compliance Repository. Your DRP executive team readiness reports should be stored in your Compliance Repository annually.
Applications & Data Criticality: What is this? This means that your organization should maintain a list of applications that are most critical to restore during an emergency. Obviously, restoring your EHR system is more important that restoring the patient scheduling system. The latter can readily be accomplished on paper if need be; the former denies access to PHI which jeopardizes treatment. Unfortunately, while it appears that this would be an easy Control to implement, most organizations, both large and small, do not do it.
(E) Applications and data criticality analysis (Addressable). Assess the relative criticality of specific applications and data in support of other contingency plan components.
References §164.308(a)(7)(ii)(E) Evaluation.
Process: Your CO should create a report to be reviewed by the executive team each time an internal review or audit of our Security Program is conducted. The results of an audit and the recommendations contained therein should be a topic of discussion at an executive team meeting no later than thirty (30) days after the conclusion of the audit and completion of the accompanying report. At the discretion of the executive team, third party compliance expertise may be tasked with working with your CO to ensure that your strategic compliance objectives are met.
Tracking: The results of your internal reviews and audits should be shared with organizational stakeholders on a need to know basis as required to achieve your strategic security objectives. Internal reviews and audits will be signed off by your CO and stored in your Compliance Repository. Your Workforce should be surveyed from time to time to ensure that your internal audits and reviews are capturing the information necessary to continuously improve your Security Program.
(8) Standard: Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart.
References §164.308(a)(7)(ii)(E) Business associate contracts and other arrangements.
Process: Your due diligence may consist of requiring all BAs to fill out a compliance questionnaire and to provide evidence that the business associate is in compliance with the Security Rule and other applicable law. Your CO should ensure that you have a Contract with each BA that reflects the requirements of the Security Rule and other applicable law. Your CO should conduct, on a yearly basis, a review of each Contract in order to ensure that it remains consistent with applicable law. If your CO suspects that a BA is in material breach of the Contract, or is otherwise not complying with applicable law, then the CO must immediately bring this to the attention of the executive team. The executive team, in collaboration with the CO, should decide how to proceed within the guidance provided by the HIPAA Rules, and the Contract, when a BA is suspected of being in material breach of the Contract.
Tracking: BA Contracts, questionnaires and evidence of compliance should be stored in the BA’s electronic folder in your Compliance Repository, along with documentation of any additional due diligence collected. A BA Review log should be kept by your CO indicating the date and results of yearly BA reviews. On a yearly basis, or more frequently at the discretion of your CO, an internal review of selected BAs should be conducted to ensure that your BA policies, processes and tracking mechanisms are achieving your Security Rule objectives.
(b) (1) Business associate contracts and other arrangements. A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with §164.314(a), that the business associate should appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.
(2) A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances, in accordance with §164.314(a), that the subcontractor should appropriately safeguard the information.
(3) Implementation specifications: Written contract or other arrangement (Required). Document the satisfactory assurances required by paragraph (b)(1) or (b)(2) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of §164.314(a).
Download a FREE copy of the HIPAA Survival Guide 4th Edition.