HIPAA Security

10 Requirements to Include in Your Business Associate Agreement The HIPAA Privacy, Security, and Breach Notification Rule require Covered Entities and their third-party vendors, referred to by the Department of Health and Human Services as Business Associates (BAs), are required to obtain a signed Business Associate Agreement (BAA) from each vendor, and their subcontractors, to ensure appropriate safeguards are implemented to protect Protected Health Information (PHI) and electronic PHI (ePHI). The BAA serves as a contract to clarify and limit the use or disclosure of PHI only as permitted or required by law. Put it in the Business Associate Agreement Healthcare third-party vendors are required to comply with the HIPAA Privacy and Security Rules to appropriately safeguard protected health information (PHI). One of those requirements is a current and signed contract, referred to as a Business Associate Agreement (BAA), for each third-party vendor. Four things third-party vendor contract do: Serves to clarify and limit the allowable uses and disclosures of PHI by the vendor. Identifies how a third-party vendor may use or disclose PHI only as permitted or required by its contract or as required by law. That a third-party vendor is directly liable under the HIPAA Rules and subject to civil and, in some cases, criminal penalties for making uses and disclosures of PHI that are not allowed in the contract or required by law. A third-party vendor is directly liable and subject to civil penalties for failing to safeguard electronic protected health information in accordance with the HIPAA Security Rule. Something to Ponder … Business Associates can and have been held directly liable and subject to civil and, in some cases, criminal penalties for making uses and disclosures of PHI that were not authorized. 10 Business Associate Agreement Requirements The written contract between a CE and a BA must: Determine when and how the third-party vendor is allowed to use or disclose PHI. Require that the third-party vendor will not use or disclose PHI other than what has been permitted by the contract or required by law. Establish what safeguards will be put in place to prevent unauthorized PHI disclosure. This includes implementing HIPAA requirements surrounding electronic PHI. This effort is intended to help reduce and eliminate Medical Records Snooping!! Require the third-party vendor to report to the provider any use or disclosure of PHI not covered by the contract, including incidents or breaches of unsecured PHI. Ensure the third-party vendor will disclose PHI as specified in the contract to satisfy a provider ‘s obligation with respect to individuals’ requests for copies of their PHI. PHI should be available for amendments as well. To the extent the third-party vendor is to carry out a provider ‘s obligation under HIPAA, require that the third-party vendor comply with the requirement relevant to the obligation. Ensure internal practices, books and records relating to the use and disclosure of PHI by the third-party vendor will be made available to the Department of Health and Human Services to determine the provider ‘s HIPAA compliance. Require that the third-party vendor return or destroy all PHI received from, or created or received by the third-party vendor on the provider ‘s behalf, upon termination of the contract. Require that third-party vendor enter agreements with their subcontractors that may have access to PHI. Allow the provider to terminate the contract if the third-party vendor violates a material term of the contract. HHS provides a sample BAA to help CEs and BAs more easily comply with the BA contract requirements. Helpful Tips for Third-Party Vendor Contract Management Here are four tips to incorporate into your third-party vendor contract management activities:  Keep all contracts/agreements in a centralized location that can be accessed anytime. Know when third-party vendor contracts expire. Ensure all third-party vendor contract are signed. Continually monitor third-party vendor compliance by issuing assessments and include third-party vendors when performing your risk analysis.

Documentation That’s What It’s All About Today I am breaking down the Documentation standard, 45 §164.316(b)(1), from the HIPAA Security Management Process into byte-size portions to help you understand how they are significant to your organization. Before I can break down today’s topic, I first should set the document stage. When it comes to auditors, lawyers and the Department of Health and Human Services (HHS) it’s all about your documentation. It’s the first thing they will ask for when they come to visit. If you don’t have it – it will be as if it was never done.  That is why the Documentation of your risk analysis and HIPAA-related policies, procedures, reports, and activities is a requirement under the HIPAA Security Rule.  Documentation provides the how (or why) and the decisions and/or actions were made. Some of those actions may include: Performed your security risk analysis Implemented safeguards to mitigate identified risks Provided training Security reminders Over time, your security documentation folder will become a tool that helps your security procedures be more efficient. These records will be essential if you are ever audited for compliance with the HIPAA Rules or an EHR Incentive Program. Breaking Down the Documentation Standard The Documentation standard requires regulated entities to: “(i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) if an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.” The standard has three implementation specifications, they are: Time Limit (Required) Availability (Required) Updates (Required) Time Limit The Time Limit implementation specification requires CEs and BAs to: “Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.” This six-year period must be considered the minimum retention period for required documentation under the Security Rule. Note: Some organizations may choose to keep their documentation longer based on state law, requirements of accreditation organizations, or other business reasons. Availability The Availability, 45 § 164.316(b)(2)(ii), implementation specification requires regulated entities to: “Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.” Organizations often make documentation available in printed manuals and/or on their websites. Updates The Updates, 45 § 164.316(b)(2)(iii), implementation specification requires regulated entities to: “Review documentation periodically, and update as needed, in response to environmental and/or operational changes affecting the security of the electronic protected health information (ePHI).” The need for periodic reviews and updates will vary based on the regulated entity’s documentation review frequency and/or the volume of environmental or operational changes that affect the security of ePHI. Creating a HIPAA Documentation Master File To help you contain all the documents you will generate, I recommend creating a HIPAA Documentation Master File. Some of the documentation should include, but not be limited to: HIPAA Security Risk Analysis Policies and Procedures Reports and activities as it relates to PHI Your documentation should include how you conducted the security risk analysis and implemented safeguards to address the risks identified during your risk analysis. Examples of What to Keep Your HIPAA Documentation Master File should include, and not limited to, the following: • Your policies and procedure• Completed security checklists• Training materials presented to staff and volunteers; any associated certificates of completion• Updated BA agreements• Security risk analysis reports• Electronic Health Record (EHR) audit logs that show both utilization of security features and efforts to monitor users’ actions• Risk management action plans or other documentation (that shows appropriate safeguards are in place throughout your organization), implementation timetables, and implementation notes• Any security incidents and breach information Over time, your security documentation folder is one of the tools in your toolbox to help you become more efficient. These records are essential if you are audited for compliance with the HIPAA Rules. YOUR security risk analysis process is an opportunity for you to learn as much as possible about health information security. Do not ignore YOUR need to be HIPAA compliant! ANY device or media that contains ePHI needs to be properly protected – HIPAA is not system or hardware specific – it applies to all! Regulated entities must periodically review and update its documentation in response to environmental and/or organizational changes that affect the security of ePHI. Healthcare organization and third-party vendors should understand that patients are entrusting them with their most private and intimate details, they do expect it to remain secure.

HIPAA Security Rule Administrative Safeguards Today I am breaking down the Administrative Safeguards of the HIPAA Security Rule, 45 CFR § 164.308, into byte-size portions to help you understand how they are significant to your organization. The HIPAA Security Rule establishes security standards for protecting all electronic protected health information (ePHI).  The Administrative Safeguards comprise over half of the HIPAA Security Rule require healthcare regulated entities to implement measures to meet the security standards. These include things such as, assignment or delegation of security responsibility to an individual and security training requirements. Administrative Safeguards Definition Actions, policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of the CE’s or BA’s workforce in relation to the protection of that information.” As with all the standards in the HIPAA Security Rule, compliance with the Administrative Safeguards requires CEs and BAs perform an evaluation of the security controls already in place, an accurate and comprehensive risk analysis, and a series of documented risk management solutions derived from a number of factors unique to each CE and BA. What are the Administrative Safeguards? An important step in protecting electronic PHI in your organization is to implement reasonable and appropriate Administrative Safeguards intended to set the foundation for your security program. Administrative safeguards are administrative actions, policies, and procedures to prevent, detect, contain, and correct security violations. Administrative safeguards involve the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of workforce members in relation to the protection of that information. A central requirement is that you perform a security risk analysis which identifies and analyzes risks to ePHI and then implement security measures to reduce those identified risks. The Administrative Safeguards and their implementation specifications are:Note: (R) = Required      (A) = Addressable Security Management Process Security Management Process – 45 CFR § 164.308(a)(1) • Risk Analysis (R)• Risk Management (R)• Sanction Policy (R)• Information System Activity Review (R) Assigned Security Responsibility Assigned Security Responsibility – 45 CFR § 164.308(a)(2) Workforce Security Workforce Security – 45 CFR § 164.308(a)(3) • Authorization and/or Supervision (A)• Workforce Clearance Procedure (A)• Termination Procedures (A) Information Access Management Information Access Management – 45 CFR § 164.308(a)(4) • Isolating Healthcare Clearinghouse Functions (R)• Access Authorization (A)• Access Establishment and Modification (A) Security Awareness and Training Security Awareness and Training – 45 CFR § 164.308(a)(5) • Security Reminders (A)• Protection from Malicious Software (A)• Log-in Monitoring (A)• Password Management (A) Security Incident Procedure Security Incident Procedures – 45 CFR § 164.308(a)(6) • Response and Reporting (R) Contingency Plan Contingency Plan – 45 CFR § 164.308(a)(7) • Data Backup Plan (R)• Disaster Recovery Plan (R)• Emergency Mode Operation Plan (R)• Testing and Revision Procedures (A)• Applications and Data Criticality Analysis (A) Evaluation Evaluation – 45 CFR § 164.308(a)(8) Business Associate Contracts and Other Arrangements Business Associate Contracts and Other Arrangements – 45 CFR § 164.308(b)(1) • Written Contract or Other Arrangement (R) Vulnerabilities and Security Mitigation Examples The following table contains a list of possible Security Components, Examples of Vulnerabilities and Examples of Security Mitigation Strategies for the Administrative Safeguards. In general, these are the administrative functions that should be implemented to meet the security standards. These include security management processes, assignment or delegation of security responsibility to an individual, and workforce security training requirements. All of the standards and implementation specifications found in the Administrative Safeguards section refer to administrative functions, such as policy and procedures that must be in place for the management and execution of security measures. These include performance of your security management processes, assignment or delegation of security responsibilities, training requirements and evaluation and documentation of all decisions. Remember: Security is not a one-time project, but rather an on-going, dynamic process that will create new challenges as technologies change. Healthcare organization and third-party vendors should understand patients are entrusting them with their most private and intimate details, they expect it to remain secure.

Breaking Down the HIPAA Security Standards Today I am breaking down the HIPAA Security Rule, 45 CFR § 164.308, into byte-size portions to help you understand how they are significant to your organization. The HIPAA Security Rule establishes security standards for protecting all electronic protected health information (ePHI), 45 CFR Part 160 and Part 164, Subparts A and C. The HIPAA Security Standards provide a structure for healthcare regulated entities (health plans, clearinghouses, or covered health care providers) to develop and implement policies and procedures to guard against and react to security incidents. All healthcare regulated entities must comply with the applicable standards, implementation specifications, and requirements of the Security Rule with respect to electronic PHI, 45 C.F.R § 164.302. The Security Rule allows regulated entities of all sizes to implement reasonable and appropriate measures that enable them to comply with the Rule. The standards were designed to be scalable, flexible and technology neutral to allow regulated entities to comply in a manner consistent with the complexity of their organization. The rule does not specify any specific technology. This is intentional so the healthcare community will is not be bound by specific systems and/or software that may become obsolete. HIPAA Security Rule Basic Concepts First let me set the ground work to help you with the basic concepts that make up the security standards and implementation specifications. Each HIPAA Security Rule standard is a requirement: a regulated entity must comply with all of the standards of the Security Rule with respect to the electronic PHI it creates, receives, maintains, or transmits. Many of the standards contain implementation specifications. An implementation specification is a more detailed description of the method or approach regulated entities can use to meet a particular standard. Regardless of whether a standard includes one or more implementation specifications, regulated entities must comply with each standard. Implementation specifications are either required or addressable. Here is a breakdown of each: Required is similar to a standard, in that a regulated entity must comply with it. For example, all regulated entities including small providers must conduct a complete and thorough “Risk Analysis,”  45 CFR § 164.308(a)(1). Addressable requires regulated entities to perform an assessment to determine if the specification is a reasonable and appropriate safeguard in their environment. After performing the assessment, a regulated entity decides if: It will implement the addressable implementation specification. Implement an equivalent alternative measure that allows the entity to comply with the standard. Or not implement the addressable specification or any alternative measures, if equivalent measures are not reasonable and appropriate within their environment. Regulated entities are required to document assessments and all decisions. For example, all regulated entities including small providers must determine whether “Encryption and Decryption” is reasonable and appropriate for their environment, 45 CFR §  164.312(a)(1). Factors that determine what is “reasonable” and “appropriate” include cost, size, technical infrastructure and resources. While cost is one factor entities must consider in determining whether to implement a particular security measure, some appropriate measure must be implemented. An addressable implementation specification is not optional, and the potential cost of implementing a particular security measure does not free covered entities from meeting the requirements identified in the rule. HIPAA Security Rule Main Sections The HIPAA Security Rule is divided into six main sections – each representing a set of standards and implementation specifications that must be addressed by all regulated entities.  The Security Rule is divided into six main sections – each representing a set of standards and implementation specifications that must be addressed by all regulated entities. They are: Administrative Safeguards Physical Safeguards Technical Safeguards Organizational Requirements Policies and Procedures  Documentation  Each Security Rule standard is a requirement: all regulated entities must comply with all of the standards of the Security Rule with respect to the ePHI it create, receive, maintain, and/or transmit. Many of the standards contain implementation specifications. An implementation specification is a more detailed description of the method or approach regulated entities can use to meet a particular standard. Implementation specifications are either required or addressable. Regardless of whether a standard includes one or more implementation specifications, all CEs and BAs must comply with each standard. Administrative Safeguards The Administrative Safeguards comprise over half of the HIPAA Security Rule. It establishes a national set of minimum security standards for protecting all ePHI that regulated entities create, receive, maintain, and/or transmit. The HIPAA Security Rule defines Administrative Safeguards as: “Administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of the regulated entities workforce in relation to the protection of that information.” The Security Rule contains several types of safeguards and requirements which regulated entities must put in place to secure ePHI. When reviewing the Administrative Safeguards, they are generally identified as: administrative actions, policies, and procedures to prevent, detect, contain, and correct security violations. Administrative Safeguards also involve the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of workforce members in relation to the protection of that information. In general, these are the administrative functions that should be implemented to meet the security standards. These include security management processes, assignment or delegation of security responsibilities to an individual, and workforce security training requirements. Physical Safeguards As with all the standards in the HIPAA Security Rule, compliance with the Physical Safeguards standards requires regulated entities to perform an evaluation of their security controls already in place, an accurate and thorough risk analysis, and a series of documented solutions derived from a number of factors unique to each organization. The HIPAA Security Rule defines Physical Safeguards as: “Physical measures, policies, and procedures to protect a regulated entities electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.” When evaluating and implementing these standards, regulated entities must consider all physical access to ePHI. This may extend outside of the actual office(s), and could include workforce members’ homes or other physical locations where they are able to access ePHI (i.e., mobile devices). In general, these are the mechanisms required to protect electronic systems, equipment and the data they hold, from threats, environmental hazards and unauthorized intrusion. They also include restricting access to ePHI and

HIPAA Security Management Process in 6 Steps Today I am breaking down the HIPAA Security Management Process, 45 § 164.308(a)(1), into byte-size portions to help you understand how they are significant to your organization. Before I can break down today’s topic, I first should set the stage.  The HIPAA Security Rule, Administrative Safeguards provisions that requires regulated entities to perform a accurate and thorough risk analysis as part of their security management processes. Risk analysis and risk management serve as tools to assist in the development of a regulated entity’s strategy to protect the confidentiality, integrity, and availability of electronic protected health information (PHI).  HIPAA Security Management Process Standards The first standard under Administrative Safeguards section is the Security Management Process. This standard requires regulated entities to: Implement policies and procedures to prevent, detect, contain and correct security violations. The HIPAA Security Management standard has four required implementation specifications. They are:  Risk Analysis (Required) Risk Management (Required) Sanction Policy (Required) Information System Activity Review (Required)  Risk analysis and risk management processes are critical to a regulated entity’s compliance efforts. The results from the risk analysis and risk management processes will become the baseline for security processes within regulated entity’s organization. Risk Analysis The Risk Analysis implementation specification, 45 § 164.308(a)(1)(ii)(A), requires regulated entities to: 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 regulated entities. The scope of a risk analysis requirement in the HIPAA Security Rule is much more expansive. It requires you to assess the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all the ePHI that an organization creates, receives, maintains, or transmits. This includes ePHI in other electronic systems and all forms of electronic media, such as: Cell phones Hard drives Compact discs (CDs) Digital video discs (DVDs) Smart cards or other storage devices Transmission media Portable electronic media Any connected Internet of Things (IoT) devices Your risk analysis process is an opportunity to learn as much as possible about the health of your information security. Don’t ignore your need to be HIPAA compliant! Any device or media that contains PHI needs to be properly protected – HIPAA is not system or hardware specific – it applies to all! Risk Management Risk Management is a required implementation specification, 45 CFR § 164.308(a)(1)(ii)(B). It requires an organization to make decisions about how to address security risks and vulnerabilities. The Risk Management implementation specification states that regulated entities must: Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 45 §164.306(a). Risk management is the process used to identify and implement security measures to reduce risks to a reasonable and appropriate level. Regulated entities will want to make sure their risk management strategy takes into account the characteristics of their environment includes these four factors: The size, complexity, and capabilities of the regulated entity. The regulated entity’s technical infrastructure, hardware, and software security capabilities. The costs of security measures. The probability and criticality of potential risks to electronic protected health information. These four factors will help them determine what potential security measures are reasonable and appropriate for the environment. NOTE: Regulated entities must ensure their risk analysis and risk management activities are on-going and dynamic processes that change as the environment or operations change. Sanction Policy Another implementation specification in the HIPAA Security Management Process is the Sanction Policy, 45 § 164.308(a)(1)(ii)(C). It requires regulated entities to: Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the regulated entity. Appropriate sanctions must be in place so that workforce members understand the consequences of failing to comply with security policies and procedures, to deter non-compliance. Information System Activity Review The HIPAA Security Management Process standard also includes the Information System Activity Review implementation specification, 45 CFR § 164.308(a)(1)(ii)(D). This required implementation specification states that regulated entity must: Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. The information system activity review enables regulated entities to determine if any ePHI is used or disclosed in an inappropriate manner. Information system activity review procedures may be different for each regulated entity. The procedure should be customized to meet the organizations risk management strategy and take into account the capabilities of all information systems with ePHI. 6 Steps to HIPAA Security Management Process Now for the moment you’ve all be waiting for …  Below are six steps to help you start: Lead your culture, select your team, and learn Document your process, findings, and actions Review existing security of ePHI (perform a Security Risk Analysis) Develop an Action Plan Manage and mitigate risks Monitor, audit, and update security on an ongoing basis Note: Performing the risk analysis in-house may require an upfront investment of your time and a staff member’s time to understand and address your security issues with respect to the HIPAA Security Rule.

Breaking Down the HIPAA Security Officer Requirement Today I am breaking down the HIPAA Security Officer requirement, Assigned Security Responsibility 45 § 164.308(a)(2), into byte-size portions to help you understand how they are significant to your organization. Since 2005, the Health Insurance Portability and Accountability Act (HIPAA) Security Rule has required regulated entities to identify who will be operationally responsible for assuring that the regulated entity complies with the Security Rule. This is similar to the Privacy Rule standard, 45 §164.530(a)(1), which requires all regulated entities designate a Privacy Officer. The HIPAA regulations state you must formally select a Privacy Officer and a Security Officer. In small organizations this can be the same person. The HIPAA Security Officer responsibilities are often assigned to an IT Manager due. This is due to the perception that integrity of ePHI is an IT issue.  The HIPAA Security Rule is made of of three safeguards, they are:  Administrative Safeguards Physical Safeguards Technical Safeguards Only 30% of the safeguards require technical expertise. That means smaller regulated entities could reduce their information systems costs by splitting the HIPAA Security Officer responsibilities. Just be sure to document your selection by department not who the activities is assigned to. This will allow authorized representatives of the department to perform the activity. HIPAA Security Officer Responsibilities The HIPAA Security Officer’s job description needs to outline the Officer’s responsibilities with regard to establishing and maintaining HIPAA compliant mechanisms for ensuring the confidentiality, integrity and accessibility of the CE´s or BA’s healthcare information systems and any PHI. These responsibilities will vary according to the nature and size of the organization, but should include: Performing an enterprise wide risk analysis of the company’s information systems. Developing and implementing policies and procedures to prevent, detect, contain and correct security violations. Regularly reviews audit logs, access reports, and security incident tracking reports. Developing and implementing policies and procedures to ensure only appropriate company workforce members have access to PHI. Implements a security awareness and training program for ALL workforce personnel, volunteers, management including doctors. Regularly monitor attempts by unauthorized persons to log on to the company’s information systems. Implements procedures to guard against and detect viruses, worms, and other malicious code. Develop and implement policies and procedures to respond to security incidents. Develops contingency plans to respond to emergencies. Performs periodic technical and nontechnical reviews of the company’s information security program. Evaluates reported incidents as potential breaches of unsecured ePHI. Something to Ponder … When designating the HIPAA Security Officer regulated entities should consider some of the following sample questions: Does it serve the organization’s needs to designate the same individual as both the Privacy and Security Officer (for example, in a small provider’s office)? How are the roles and responsibilities of the Security Officer crafted to reflect the size, complexity and technical capabilities of the organization?

Breaking Down Threats, Vulnerabilities, and Risks Today I am breaking down threats, vulnerabilities, and risks into byte-size portions to help you understand how they are significant to your organization. Before I can break down today’s topic, I first should set the stage.  Setting the Stage for Threats, Vulnerabilities, and Risks The Security Management Process, 45 § 164.308, requires regulated entities to evaluate threats, vulnerabilities and risks in their environments and to implement policies and procedures to prevent, detect, contain, and correct security violations. Regulated entities should be familiar with these three terms and the relationship between them: Vulnerability Threat Risk Note: These terms are not specifically defined in the HIPAA Security Rule. The definitions in this paper are provided to put the Risk Analysis and Risk Management discussion in context. Threat, Vulnerability, and Risk Definitions Threats The Guidance for Conducting Risk Assessment by the National Institute of Science and Technology (NIST), NIST 800-30, defines a threat as: Any circumstance or event with the potential to adversely impact organizational operations and assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. Threat events are caused by threat sources. A threat source is characterized as: (i) the intent and method targeted at the exploitation of a vulnerability; or (ii) a situation and method that may accidentally exploit a vulnerability. In general, types of threat sources include: Hostile cyber or physical attacks Human errors of omission or commission; Structural failures of organization-controlled resources (e.g., hardware, software, environmental controls); and Natural and man-made disasters, accidents, and failures beyond the control of the organization. Vulnerability The Guidance for Conducting Risk Assessment by the National Institute of Science and Technology (NIST), NIST 800-30, defines a vulnerability as: A vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a security incident, such as an inappropriate use or disclosure of electronic protected health information (ePHI). Vulnerabilities may be grouped into two general categories, technical and non-technical. Non-technical vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines. Technical vulnerabilities may include: holes, flaws or weaknesses in the development of information systems; or incorrectly implemented and/or configured information systems. Remember: A vulnerability triggered or exploited by a threat equals a risk. Vulnerabilities can also be found in external relationships such as:  Dependencies on particular energy sources Supply chains Information technologies Telecommunications providers  Poorly defined mission/business processes Poor enterprise/information security architecture decisions Risks The Guidance for Conducting Risk Assessment by the National Institute of Science and Technology (NIST), NIST 800-30, defines a risk as: A measure of the extent to an entity is threatened by a potential circumstance or event, and typically a function of: The adverse impacts that would arise if the circumstance or event occurs; and The likelihood of occurrence. This means that risk is not a single factor or event, but rather it is a combination of factors or events (threats and vulnerabilities) that, if they occur, may have an adverse impact on the organization. Remember: A vulnerability triggered or exploited by a threat equals a risk. Something to Ponder … Here are four questions for you to ponder. Does your organization addresses the following:   Does your organization have a resource dedicated Compliance Officer responsible for enforcing and maintaining HIPAA Privacy and Security policies? What are your policies for data segregation and encryption? Have you applied all applicable security patches? Does your employees and third-party vendors training include security best practices?