Search Results for: Security Management Process

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.

HIPAA Audit Controls and Audit Logs Today I am breaking down the one of the Technical Safeguard standards,  Audit Controls, 45 § 164.312(b), into byte-size portions to help you understand how it is significant to your organization. Audit Logs are  The HIPAA Security Rule provision on requires regulated entities to: Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. Audit Controls – What Are They?   The majority of information systems provide some level of audit controls with a reporting method, such as audit logs. These controls are useful for recording and examining information system activity which also includes users and applications activity. Audit controls that produce audit reports work in conjunction with audit logs and audit trails. Audit logs and trails assist regulated entities with reducing risk associated with: reviewing inappropriate access; tracking unauthorized disclosures of ePHI; detecting performance problems and flaws in applications; detecting potential intrusions and other malicious activity; and providing forensic evidence during investigation of security incidents and breaches. As part of this process, regulated entities should consider which audit tools may best help them with reducing non-useful information contained in audit records, as well as with extracting useful information. Audit Logs and Audit Trails – What Are They? According to the National Institute of Standards and Technology (NIST), audit logs are records of events based on applications, users, and systems, and audit trails involve audit logs of  applications, users, and systems. Audit trails’ main purpose is to maintain a record of system activity by application processes and by user activity within systems and applications. Regulated entities should make sure that they appropriately review and secure audit trails, and they use the proper tools to collect, monitor, and review audit trails. Protecting audit logs and audit trails prevent intruders from tampering with the audit records and protecting their integrity. Not safeguarding audit logs and audit trails can allow hackers or malevolent insiders to cover their electronic tracks, making it difficult for regulated entities to not only recover from breaches, but to prevent them before they happen.   The HIPAA Security Rule does not identify what information should be collected from an audit log or trail or how often the audit reports should be reviewed. When determining reasonable and appropriate audit controls for information systems containing or using ePHI, regulated entities must consider their risk analysis results and organizational factors, such as: Technical infrastructure Hardware Software security Audit Trails Examples Different types of audit trails your practice should consider, including: Application audit trails – Normally monitor and log user activities in the application. This includes the application data files opened and closed, and the creating, reading, editing, and deleting of application records associated with ePHI. System-level audit trails – Usually capture successful or unsuccessful log-on attempts, log-on ID/username, date and time of each log-on/off attempt, devices used to log-on, and the application the user successfully or unsuccessfully accessed. User audit trails – Normally monitor and log user activity in a ePHI system or application by recording events initiated by the user, such as all commands directly initiated by the user, log on attempts with identification and authentication, and access to ePHI files and resources. It is important to point out that although the HIPAA Security Rule does not identify data that must be gathered by the audit controls or how often the audit reports should be reviewed.  A regulated entity must consider its risk analysis and organizational factors, such as current technical infrastructure, hardware and software security capabilities, to determine reasonable and appropriate audit controls for information systems that contain or use ePHI. Is Anyone Looking at the Audit Logs? There are several reasons to implement and monitor audit controls. Over the last few weeks I’ve shared several of them, here are two: Doctor accessed medical records without authorization AND gave some of that PHI to an ATTORNEY!! Nurse viewed 13,000 patients’ medical records without authorization for 15 Months!! How do you know if, or who, is snooping in your medical records? . . Audit Logs! . . But it Doesn’t End There!   Regulated entities should review and secure audit logs/trails, and use proper tools to collect, monitor, and review audit logs/trails. But, the HIPAA Security Rule does not identify what information should be collected in an audit log/trail or how often the audit reports should be reviewed. Each regulated entity must consider their complete and thorough risk analysis results and organizational factors, such as their current technical infrastructure, hardware, and software security capabilities. The majority of information systems provide some level of audit controls with a reporting method, such as audit reports. These controls are useful for recording and examining information system activity which also includes users and applications activity. It is important to protect your audit logs and trails to prevent intruders from tampering with the audit records and protecting their integrity. Not safeguarding audit logs and audit trails can allow hackers or insider threats to cover their tracks electronically, making it difficult for regulated entities to not only recover from incidents or breaches, but to prevent them before they happen. Add Your Heading Text Here Understanding the Importance of Audit Controls The HIPAA Security Rule provision on Audit Controls (45 C.F.R. § 164.312(b)) requires regulated entities to apply hardware, software, and/or procedural mechanisms that record and examine activity within information systems that contain or use electronic protected health information (ePHI). Audit controls produce audit reports which work in conjunction with audit logs and audit trails. Audit logs and audit trails assist CEs and BAs in reducing associated risks by: → Tracking inappropriate access → Tracking unauthorized disclosures of ePHI → Detecting performance problems and flaws in applications → Detecting potential intrusions and other malicious activity → Providing forensic evidence during security incidents and breach investigations   It is imperative for regulated entities to review their audit trails regularly, both particularly after security incidents or breaches, and during real-time operations. Regular review of information system activity should promote awareness of any information system activity that could suggest a security incident or breach. Access to audit trails should be strictly restricted, and should be provided only to authorized personnel. Covered Entities

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

Did You Know? The HIPAA Security Rule requires Covered Entities (CEs) and Business Associates (BAs) to “implement a security awareness and training program for ALL members of its workforce (including management)” 45 C.F.R. § 164.308(a)(5)(i). Note: the emphasis on ALL members of the workforce, because ALL workforce members can either be guardians of the entity’s Protected Health Information (PHI) or can, knowingly or unknowingly, be the cause of HIPAA violations or data breaches. In order to implement this standard, the Security Rule requires CEs and BAs to implement periodic security updates, or reasonable equivalents. 45 C.F.R. § 164.308(a)(5)(ii)(A).     An organization’s training program should be an ongoing, evolving process and flexible enough to educate workforce members on new cybersecurity threats and how to respond to them.     As such, CEs and BAs should consider: • How often to train ALL their workforce members on security issues, given the risks and threats to their organization, and how often to send security updates to their workforce members. Many entities have determined that bi-annual training, and monthly security updates are necessary, given their risks analyses. • Using security updates and reminders to quickly communicate new and emerging cybersecurity threats to workforce members such as new social engineering ploys (e.g., fake tech support requests and new phishing scams) and malicious software attacks including new ransomware variants. • What type of training to provide to workforce members on security issues, given the risks and threats to their enterprises. Computer-based training, classroom training, monthly newsletters, posters, email alerts, and team discussions are all tools that different organizations use to fulfill their training requirements. • How to document that training to workforce members was provided, including dates and types of training, training materials, and evidence of workforce participation. Any investigator or auditor will ask for documentation, as required by the HIPAA Rules, to ensure compliance with the requirements of the Rules. See 45 C.F.R. §§ 164.316(b) and 164.530(j). Covered Entities and Business Associates your patients are entrusting YOU with their most private and intimate details, they expect it to remain secure! Besides, it is YOUR practice, YOUR patients, YOUR reputation and YOUR legacy! Why are you leaving yourself wide open to such risks?     Don’t know where or how to start or update your HIPAA security compliance training? Let’s chat – schedule a call with HIPAA alli today!

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 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?