Risk Management

4.0 Risk Management Policy

This policy establishes the scope, objectives, and procedures of iDialogs' information security risk management process. The risk management process is intended to support and protect the organization and its ability to fulfill its mission. It is the policy of the iDialogs Organization and each individual or unit within iDialogs that is a Business Associate of a covered entity (hereafter collectively referred to as “units”) to conduct thorough and timely risk assessments of the potential threats and vulnerabilities to the confidentiality, integrity, and availability of its electronic protected health information (ePHI) (and other confidential and proprietary electronic information) and to develop strategies to efficiently and effectively reduce the risks identified in the assessment process. 

4.1 Applicable Standards

4.1.1 Applicable Standards from the HITRUST Common Security Framework

  • 03.a - Risk Management Program Development
  • 03.b - Performing Risk Assessments
  • 03.c - Risk Mitigation

4.1.2 Applicable Standards from the HIPAA Security Rule

  • CFR §164.302-306 - General Requirements
  • CFR §164.308(a)(1)(i) - Security Management Process
  • CFR §164.308(a)(1)(ii)(A) - Risk Analysis
  • CFR §164.308(a)(1)(ii)(B) - Risk Management
  • CFR §164.308(a)(8) - Evaluation
  • CFR §164.316(a-b) - Documentation

4.2 Risk Management Policies

Risk analysis and risk management are integral components of iDialogs' compliance program and Information Technology (IT) security program in accordance with the Risk Analysis and Risk Management implementation specifications within the Security Management standard and the Evaluation standard set forth in the HIPAA Security Rule, 45 CFR §164.308(a)(1)(ii)(A) Risk Analysis, §164.308(a)(1)(ii)(B) Risk Management, §164.308(a)(1)(i) Security Management Process, and §164.308(a)(8) Evaluation.

  1. Risk assessments are done throughout IT system life cycle:
    1. Before the purchase or integration of new technologies and Changes are made to physical safeguards.
      1. These changes do not include routine updates to existing systems, deployments of new systems created based on previously configured systems, deployments of new Customers, or new code developed for operations and management of the iDialogs Platform.
    2. While integrating technology and making physical security changes.
    3. While sustaining and monitoring appropriate security controls.
  2. Each unit performs periodic technical and non-technical assessments of compliance with the security rule requirements, with additional assessments in response to environment.
  1. iDialogs implements security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to:
    1. Ensure the confidentiality, integrity, and availability of all ePHI iDialogs receives, maintains, processes, and/or transmits for its Customers.
    2. Protect against any reasonably anticipated threats or hazards to the security or integrity of Customer ePHI.
    3. Protect against any reasonably anticipated uses or disclosures of Customer ePHI that are not permitted or required.
    4. Ensure compliance by all workforce members.
  2. Any risk remaining (residual) after other risk controls have been applied, requires sign off by the senior management and iDialogs' Security Officer.
  3. All iDialogs workforce members are expected to fully cooperate with all persons charged with doing risk management work, including contractors and audit personnel. Any workforce member that violates this policy will be subject to disciplinary action based on the severity of the violation, as outlined in the iDialogs Roles Policy.
  4. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of iDialogs' Security Officer (or other designated employee), and the identified Risk Management Team.
  5. All risk management efforts, including decisions made on what controls to put in place as well as those to not put into place, are documented and the documentation is maintained for six years.

4.3 Risk Management procedures

The details of the Risk Management Process, including risk assessment, discovery, and mitigation, are outlined in detail below. The process is tracked, measured, and monitored using the following procedures:

  1. The Security Officer or the Privacy Officer initiates the Risk Management Procedures by creating an Issue in the JIRA Compliance Review Activity (CRA) Project.
  2. The Security Officer or the Privacy Officer is assigned to carry out the Risk Management Procedures.
  3. All findings are documented in approved spreadsheet that is linked to the Issue.
  4. Once the Risk Management Procedures are complete, along with corresponding documentation, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
  5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
    1. The Risk Management Procedure is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.

4.3.1 Risk Assessment

The intent of completing a risk assessment is to determine potential threats and vulnerabilities, and the likelihood and impact should they occur. The output of this process helps to identify appropriate security controls for reducing or eliminating risk. There are a variety of methods that are suitable for HIPAA risk assessment. The following is one such method. Consistency of risk assessment methods among units and over time is helpful and encouraged.

  1. System Characterization

    1. The first step in assessing risk is to define the scope of the effort. To do this, identify where ePHI is created, received, maintained, processed, or transmitted. Using information gathering techniques, the IT system boundaries are identified, as well as the resources and the information that constitute the system. Take into consideration policies, laws, the remote work force and telecommuters, and removable media and portable computing devices (e.g., laptops, removable media, and backup media).
    2. Output: Characterization of the IT system assessed, a good picture of the IT system environment, and delineation of system boundaries.
  2. Threat Identification

    1. Potential threats (the potential for threat-sources to successfully exercise a particular vulnerability) are identified and documented. Consider all potential threat sources through the review of historical incidents and data from intelligence agencies, the government, etc., to help generate a list of potential threats. The list should be based on the individual organization and its processing environment.
    2. Output: A threat statement containing a list of potential threat sources that could exploit system vulnerabilities.
  3. Vulnerability Identification

    1. Develop a list of technical and non-technical system vulnerabilities that could be exploited or triggered by the potential threat sources. Vulnerabilities can range from incomplete or conflicting policies that govern an organization’s computer usage to insufficient security controls to protect facilities that house computer equipment to any number of software, hardware, or other deficiencies that comprise an organization’s computer network.
    2. Output: A list of the Platform vulnerabilities (observations) that could be exercised by potential threat-sources.
  4. Control Analysis

    1. Document and assess the effectiveness of technical and non-technical security controls that have been or will be implemented by the organization to reduce the likelihood of a threat source exploiting a system vulnerability.
    2. Output: A list of current or planned security controls used for the IT system to reduce the likelihood of a vulnerability being exploited by a threat source and to reduce the impact of such an adverse event.
  5. Likelihood Determination

    1. Determine the overall likelihood rating that indicates the probability that a vulnerability could be exploited by a threat-source given the existing or planned security controls.
    2. Output: Likelihood rating of low (.1), medium (.5), or high (1). Refer to the NIST SP 800-30 definitions of low, medium, and high.
  6. Impact Analysis

    1. Determine the level of adverse impact that would result from a threat source successfully exploiting a vulnerability. Factors of the data and systems to consider should include the importance to the organization’s mission; sensitivity and criticality (value or importance); and associated costs that could result from the loss of confidentiality, integrity, and availability of systems and data.
    2. Output: Magnitude of impact rating of low (10), medium (50), or high (100). Refer to the NIST SP 800-30 definitions of low, medium, and high.
  7. Risk Determination

    1. Establish a risk level. By multiplying the ratings from the likelihood determination and impact analysis, a risk level is determined. This represents the degree or level of risk to which an IT system, facility, or procedure might be exposed if a given vulnerability were exercised. The risk rating also presents actions that senior management must take for each risk level.
    2. Output: Risk level of low (1-10), medium (>10-50) or high (>50-100). Refer to the NIST SP 800-30 definitions of low, medium, and high.
  8. Control Recommendations

    1. Identify security controls that could reduce the identified risks to an acceptable level. Factors to consider when developing security controls may include effectiveness of recommended options, legislation and regulation, organizational policy, operational impact, safety, and reliability. Security control recommendations provide input to the risk mitigation process, during which the recommended technical and non-technical security controls are evaluated, prioritized, and implemented.
    2. Output: Recommendation of control(s) and alternative solutions to mitigate risk.
  9. Results Documentation

    1. Results of the risk assessment are documented in an official report or briefing by the iDialogs Privacy and Security Officers and presented to the iDialogs Executive Board, so they can make decisions on policy, procedure, budget, and system operational and management changes.
    2. Output: A risk assessment report that describes the threats and vulnerabilities, measures the risk, and provides recommendations for security control implementation.

4.3.2 Risk Mitigation

Risk mitigation involves prioritizing, evaluating, and implementing the appropriate risk-reducing security controls recommended from the risk assessment process to ensure the confidentiality, integrity and availability of ePHI. Determination of appropriate security controls to reduce risk is dependent upon the risk tolerance of the organization consistent with its goals and mission. There are a variety of methods that are suitable for HIPAA risk mitigation. The following is one such method. Consistency of risk mitigation methods among units and over time is helpful and encouraged.

  1. Prioritize Actions

    1. Using results from Step 7 of the Risk Assessment, sort the threat and vulnerability pairs according to their risk-levels in descending order. This establishes a prioritized list of actions needing to be taken, with the pairs at the top of the list getting/requiring the most immediate attention and top priority in allocating resources
    2. Output: Actions ranked from high to low
  2. Evaluate Recommended Control Options

    1. Although possible security controls for each threat source / vulnerability pair are listed in Step 8 of the Risk Assessment, review the recommended security controls and alternative solutions for reasonableness and appropriateness. The feasibility, (e.g. compatibility, user acceptance, etc.,) and the effectiveness, (e.g. degree of protection and level of risk reduction,) of the recommended security controls should be analyzed.
    2. Output: – A list of the "most appropriate" security control option for each threat source / vulnerability pair.
  3. Conduct Cost-Benefit Analysis

    1. Determine the extent to which a control is cost-effective. Compare the benefit (e.g., risk reduction) of applying a control with its subsequent cost of application. Controls that are not cost-effective are also identified during this step. Analyzing each control or set of controls in this manner, and prioritizing across all controls being considered, can greatly aid in the decision-making process.
    2. Output: Documented cost-benefit analysis of either implementing or not implementing each specific control.
  4. Select Control(s)

    1. Taking into account the information and results from previous steps, the organization's mission, and other important criteria, the Risk Management Team determines the best security controls for reducing risks to the information systems and to the confidentiality, integrity, and availability of ePHI. These security controls may consist of a mix of administrative, physical, and/or technical safeguards, and other technical and non-technical controls
    2. Output: Selected security controls, with rationale for selecting the controls and for not selecting other controls that were considered.
  5. Assign Responsibility

    1. Identify the workforce members with the skills necessary to implement each of the specific controls outlined in the previous step, and assign their responsibilities. Also identify the equipment, training and other resources needed for the successful implementation of controls. Resources may include time, money, equipment, etc.
    2. Output: A list of responsible persons, their assignments, and other necessary resources.
  6. Develop Safeguard Implementation Plan

    1. Develop an overall implementation plan and individual project plans needed to implement the identified security controls. The Implementation Plan should contain the following information:
      1. Each risk or vulnerability/threat pair and risk level.
      2. Prioritized actions.
      3. The selected security controls for each identified risk.
      4. Required resources for implementation of selected controls.
      5. Team member(s) responsible for implementation of each control.
      6. Start date for implementation.
      7. Target date for completion of implementation.
      8. Maintenance requirements.
    2. The overall implementation plan provides a broad overview of the implementation of the security controls, identifying important milestones and time-frames, resource requirements, (e.g. staff and other individuals’ time, budget, etc.,) interrelationships between projects, and any other relevant information. Regular status reporting of the plan, along with key metrics and success indicators is reported to the iDialogs Senior Management.
    3. Individual project plans for safeguard implementation may be developed and contain detailed steps that resources assigned carry out to meet implementation timeframes and expectations. Additionally, consider including items in individual project plans such as a project scope, a list deliverables, key assumptions, objectives, task completion dates and project requirements.
    4. Output: Safeguard Implementation Plan
  7. Implement Selected Controls

    1. As controls are implemented, monitor the affected system(s) to verify that the implemented controls continue to meet expectations. Elimination of all risk is not practical. Depending on individual situations, implemented controls may lower a risk level but not completely eliminate the risk.
    2. Continually and consistently communicate expectations to all Risk Management Team members, as well as senior management and other key people throughout the risk mitigation process. Identify when new risks are identified and when controls lower or offset risk rather than eliminate it.
    3. Additional monitoring is especially crucial during times of major environmental changes, organizational or process changes, or major facilities changes.
    4. If risk reduction expectations are not met, then repeat all or a part of the risk management process so that additional controls needed to lower risk to an acceptable level can be identified.
    5. Output: Safeguard Implementation Plan project documentation, and identified residual risk levels.
  8. Residual Risk Acceptance
    1. Any residual risk remaining after other risk controls have been applied requires sign off by the:
      1. iDialogs HIPAA Security Officer
      2. iDialogs HIPAA Privacy Officer
      3. Senior Management Team
    2. Output: Risk acceptance documentation.

4.3.3 Risk Management Schedule

The two principle components of the risk management process - risk assessment and risk mitigation - will be carried out according to the following schedule to ensure the continued adequacy and improvement of the iDialogs information security program:

  1. Scheduled Basis - an overall risk assessment of iDialogs information system infrastructure will be conducted annually. The assessment process should be completed in a timely fashion so that risk mitigation strategies can be determined and included in the corporate budgeting process.
  2. Throughout a System's Development Life Cycle - from the time that a need for a new, untested information system configuration and/or application is identified through the time it is disposed of, ongoing assessments of the potential threats to a system and its vulnerabilities should be undertaken as a part of the maintenance of the system.
  3. As Needed - the Security Officer (or other designated employee) or Risk Management Team may call for a full or partial risk assessment in response to changes in business strategies, information technology, information sensitivity, threats, legal liabilities, or other significant factors that affect iDialogs Platform.

4.4 Documentation Requirements

  1. The iDialogs Security Officer documents or receives a copy of all documents pertaining to risk assessments and risk mitigation activities completed to comply with the Security Rule, and maintains those documents for six years from the date of creation or date it was last in effect, whichever is later.
  2. The iDialogs Privacy Officer documents or receives a copy of all documents pertaining to to risk assessments and risk mitigation activities completed by the unit to comply with the Security rule, and forwards a copy of all of these to the iDialogs Security Officer (in electronic form if available.) The Privacy Officer may optionally maintain convenience copies of those documents for six years from the date of creation or date it was last in effect, whichever is later.