1. Introduction

Meru Health, Inc (“Meru Health”) is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its Patients and Customers. Meru Health strives to maintain compliance, proactively address information security and mitigate risk for its Customers. The following documents address core policies used by Meru Health to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for Meru Health Customers.

Meru Health is a technology and service company that is built using HIPAA compliant cloud-platforms to enable licensed therapist and medical personnel to treat people with depression, burnout or anxiety symptoms.

1.1 Meru Health Platform

Meru Health offers a 12-week treatment program that is accessed by getting a referral from a healthcare provider. Once the referral is received, a Meru Health licensed therapist processes the referral and initiates a treatment relationship with the patient using the Meru Health Platform.

Meru Health Platform is used via the following interfaces:

1. Patient-facing Smartphone Application allows patients to chat with a Meru Health licensed therapist, progress through the program contents and complete lesson practices.
2. Clinician Dashboard that is a therapist facing web application and is used by Meru Health therapists to monitor and interact with patients as part of treatment.

Meru Health Platform is supported by backend systems for data storage, processing and analytics, including systems handling Protected Health Information (PHI).

1.2 Meru Health Organizational Concepts

All PHI on Meru Health Platform is stored and processed on Google Cloud Platform. GCP (Google Cloud Platform) is a HIPAA-compliant cloud provider that is HITRUST and SOC2 certified. Meru Health uses tools and services provided by Google to achieve HIPAA-compliance, such as but not limited to HIPAA-compliant network infrastructure, audit logging, and encrypted storage at rest and in transit. As all system level procedures are managed by GCP, Meru Health inherits several GCP’s security policies and safeguards to respond to many requirements of HIPAA.

Meru Health also uses other platforms and providers, such as Google Firebase and FormStack platforms for storage and processing of user data. Examples of such data can be application state, user progress in the program, registration,completed practices and anonymous profile information.

Within the Meru Health Platform all data transmission is encrypted and all hard drives are encrypted so data at rest is also encrypted.

All changes to Meru Health Platform are tested end-to-end for usability, security, and impact prior to deployment to production.

1.3 Requesting Audit and Compliance Reports

Meru Health shares audit reports with customers on a case by case basis. All audit reports are shared between Meru Health and the party to receive materials with a NDA (Non Disclosure Agreement). Audit reports can be requested by Meru Health workforce members for Customers or directly by Meru Health Customers.

The following process is used to request audit reports:

1. Email is sent to security@meruhealth.com. In the email, please specify the type of report being requested and any required timelines for the report.
2. Meru Health staff will log an issue with the details of the request into the Meru Health Quality Management System. The Meru Health Quality Management System is used to track requests’ status and outcomes.
3. Meru Health will confirm if a current NDA is in place with the party requesting the audit report. If there is no NDA in place, Meru Health will send one for execution.
4. Once it has been confirmed that an NDA is executed, Meru Health staff will move the issue to “Under Review”.
5. The Meru Health Security Officer or Privacy Officer must Approve or Reject the Issue. If the Issue is rejected, Meru Health will notify the requesting party that we cannot share the requested report.
6. If the issue has been Approved, Meru Health will send the customer the requested audit report and complete the Quality Management System issue for the request.

1.4 Version Control

Refer to the GitHub repository at https://github.com/meruhealth/meru-policies/ for the full version history of these policies.

2. HIPAA Inheritance

Meru Health partners with GCP (Google Cloud Platform) to achieve HIPAA compliance in combination with efforts from Meru staff and other third party providers. GCP has audited policies and safeguards in place, which Meru Health inherits as part of their offering.

Safeguards, controls and policies inherited from GCP are listed below.

2.1 HIPAA Inheritance for Customers

2.2 HIPAA Inheritance for Platform Add-on Customers

3. Policy Management Policy

Meru Health implements policies and procedures to maintain compliance and integrity of data. The Security Officer and Privacy Officer are responsible for maintaining policies and procedures and assuring all Meru Health workforce members, business associates, customers, and partners are adherent to all applicable policies. Previous versions of policies are retained to assure ease of finding policies at specific historic dates in time.

3.1 Applicable Standards

3.1.1 Applicable Standards from the HITRUST Common Security Framework

• 12.c - Developing and Implementing Continuity Plans Including Information Security

3.1.2 Applicable Standards from the HIPAA Security Rule

• 164.316(a) - Policies and Procedures
• 164.316(b)(1)(i) - Documentation

3.2 Maintenance of Policies

1. All policies are stored and updated to maintain Meru Health compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control are managed through source code control.
2. Policy update requests can be made by any workforce member at any time. Furthermore, all policies are reviewed annually by both the Security and Privacy Officer to assure they are accurate and up-to-date.
3. Meru Health employees may request changes to policies using the following process:
   1. The Meru Health employee initiates a policy change request by creating an Issue in the Meru Health Quality Management System. The change request may optionally include a GitHub pull request from a separate branch or repository containing the desired changes.
   2. The Security Officer or the Privacy Officer is assigned to review the policy change request.
   3. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
   4. If the review is approved, the Security Officer or Privacy Officer then marks the Issue as Done, adding any pertinent notes required.
   5. If the policy change requires technical modifications to production systems, those changes are carried out by authorized personnel using Meru Health’s change management process (§9.4).
4. All policies are made accessible to all Meru Health workforce members and new employees are required to go through policy training as part of their employee onboarding procedure. The current master policies are published at https://policy.meruhealth.com.
   • Changes are automatically communicated to all Meru Health team members through integrations between GitHub and Slack that log all GitHub policy channels to a dedicated Meru Health Slack Channel.
   • The Security Officer also communicates policy changes to all employees via email. These emails include a high-level description of the policy change using terminology appropriate for the target audience.
5. All policies, and associated documentation, are retained for 6 years from the date of its creation or the date when it last was in effect, whichever is later
   1. Version history of all Meru Health policies is done via GitHub.
   2. Backup storage of all policies is done with Google Drive.
6. The policies and information security policies are reviewed and audited annually, or after significant changes occur to Meru Health’s organizational environment. Issues that come up as part of this process are reviewed by Meru Health management to assure all risks and potential gaps are mitigated and/or fully addressed. The process for reviewing polices is outlined below:
   1. The Security Officer initiates the policy review by creating an Issue in the Meru Health Quality Management System.
   2. The Security Officer or the Privacy Officer is assigned to review the current Meru Health policies (https://policy.meruhealth.com/).
   3. If changes are made, the above process is used. All changes are documented in the Issue.
   4. Once the review is completed, the Security Officer or Privacy 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 or Privacy Officer then marks the Issue as Done, adding any pertinent notes required.
   6. Policy review is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.
7. Meru Health tracks compliance with HITRUST CSF framework on annual basis. In order to track and measure adherence, Meru Health uses the following process to track HITRUST audits, both full and interim:
   1. The Security Officer initiates the HITRUST audit activity by creating an Issue in the Meru Health Quality Management System.
   2. The Security Officer or the Privacy Officer is assigned to own and manage the HITRUST activity.
   3. Once the HITRUST activity is completed, the Security Officer approves or rejects the Issue.
   4. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
   5. Compliance with annual compliance assessments, utilizing the HITRUST CSF as a framework, is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.

Additional documentation related to maintenance of policies is outlined in §5.3.1.

4. Risk Management Policy

This policy establishes the scope, objectives, and procedures of Meru Health’s information security risk management process. The risk management process is intended to support and protect the organization and its ability to fulfill its mission.

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

• 164.308(a)(1)(ii)(A) - HIPAA Security Rule Risk Analysis
• 164.308(a)(1)(ii)(B) - HIPAA Security Rule Risk Management
• 164.308(a)(8) - HIPAA Security Rule Evaluation

4.2 Risk Management Policies

1. It is the policy of Meru Health to conduct thorough and timely risk assessments of the potential threats and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) (and other confidential and proprietary electronic information) it stores, transmits, and/or processes and to develop strategies to efficiently and effectively mitigate the risks identified in the assessment process as an integral part of the Meru Health’s information security program.
2. Risk analysis and risk management are recognized as important components of Meru Health’s corporate compliance program and information security program in accordance with the Risk Analysis and Risk Management implementation specifications within the Security Management standard and the evaluation standards set forth in the HIPAA Security Rule, 45 CFR 164.308(a)(1)(ii)(A), 164.308(a)(1)(ii)(B), 164.308(a)(1)(i), and 164.308(a)(8).
   1. Risk assessments are done throughout product life cycles:
      • Before the integration of new system technologies and before changes are made to Meru Health physical safeguards; and
      • 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 Meru Health Platform.
      • While making changes to Meru Health physical equipment and facilities that introduce new, untested configurations.
      • Meru Health performs periodic technical and non-technical assessments of the security rule requirements as well as in response to environmental or operational changes affecting the security of ePHI.
3. Meru Health 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 Meru Health 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; and
   4. Ensure compliance by all workforce members.
4. Any risk remaining (residual) after other risk controls have been applied, requires sign off by the senior management and Meru Health’s Security Officer.
5. All Meru Health 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 Meru Health Roles Policy.
6. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of Meru Health’s Security Officer (or other designated employee), and the identified Risk Management Team.
7. 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.
8. 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 Meru Health Quality Management System.
   2. The Security Officer or the Privacy Officer is assigned to carry out the Risk Management Procedures.
   3. All findings are documented in an 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.
9. The Risk Management Procedure is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.

4.3 Risk Management Procedures

4.3.1 Risk Assessment

Meru Health performs regular risk assessments. These risk assessments are to determine potential threats and vulnerabilities and the likelihood and impact should they occur. The output of this process helps to identify appropriate controls for reducing or eliminating risk.

• Step 1. System Characterization

  • Effort scoping: Meru staff identify where ePHI is received, maintained, processed, or transmitted. Using information-gathering techniques, the Meru Health Platform boundaries are identified.
  • Output - Characterization of the Meru Health Platform system, including a picture of the Platform environment, and delineation of Platform boundaries.

• Step 2. Threat Identification

  • Potential threats (the potential for threat-sources to successfully exercise a particular vulnerability) are identified and documented. All potential threat-sources from historical incidents and data from intelligence agencies, the government, etc., are reviewed to help generate a list of potential threats.
  • Output - A threat list containing a list of threat-sources that could exploit Platform vulnerabilities.

• Step 3. Vulnerability Identification

  • A list of technical and non-technical Platform vulnerabilities that could be exploited or triggered by potential threat-sources is generated. Vulnerabilities can range from incomplete or conflicting policies that govern an organization’s computer usage to insufficient safeguards to protect facilities that house computer equipment to any number of software, hardware, or other deficiencies that comprise an organization’s computer network.
  • Output - A list of the Platform vulnerabilities (observations) that could be exercised by potential threat-sources.

• Step 4. Control Analysis

  • Document and assess the effectiveness of technical and non-technical controls that have been or will be implemented by Meru Health to minimize or eliminate the likelihood / probability of a threat-source exploiting a Platform vulnerability.
  • Output - List of current or planned controls (policies, procedures, training, technical mechanisms, insurance, etc.) used for the Platform to mitigate the likelihood of a vulnerability being exercised and reduce the impact of such an adverse event.

• Step 5. Likelihood Determination

  • 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.
  • Output - Likelihood rating of low (.1), medium (.5), or high (1). Refer to the NIST SP 800-30 definitions of low, medium, and high.

• Step 6. Impact Analysis

  • Determine the level of adverse impact that would result from a threat successfully exploiting a vulnerability. Factors of the data and systems to consider should include the importance to Meru Health’s mission; sensitivity and criticality (value or importance); costs associated; loss of confidentiality, integrity, and availability of systems and data.
  • 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.

• Step 7. Risk Determination

  • 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 Meru senior management must take for each risk level.
  • 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.

• Step 8. Control Recommendations

  • Identify controls that could reduce or eliminate the identified risks, as appropriate to the Meru Health operations to an acceptable level. Factors considered when developing these controls include effectiveness of recommended options (i.e., system compatibility), legislation and regulation, organizational policy, operational impact, and safety and reliability. Control recommendations provide input to the risk mitigation process, during which the recommended procedural and technical security controls are evaluated, prioritized, and implemented.
  • Output - Recommendation of control(s) and alternative solutions to mitigate risk.

• Step 9. Results Documentation

  • Results of the risk assessment are documented in an official report, spreadsheet, or briefing and provided to Meru senior management to make decisions on policy, procedure, budget, and Platform operational and management changes.
  • Output - A risk assessment report that describes the threats and vulnerabilities, measures the risk, and provides recommendations for control implementation.

4.3.2 Risk Mitigation

Risk mitigation involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the Risk Assessment process to ensure the confidentiality, integrity and availability of Meru Health Platform ePHI.

• Step 1. Prioritize Actions

  • Using results from Step 7 of the Risk Assessment, the threat and vulnerability pairs are sorted 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.
  • Output - Actions ranked from high to low

• Step 2. Evaluate Recommended Control Options

  • The possible controls for each threat and vulnerability pair that are arrived at in Step 8 of the Risk Assessment are reviewed for reasonableness and appropriateness and alternative solutions will be compared. The feasibility (e.g., compatibility, user acceptance, etc.) and effectiveness (e.g., degree of protection and level of risk mitigation) of the recommended controls are analyzed. In the end, a “most appropriate” control option for each threat and vulnerability pair is selected.
  • Output - list of feasible controls

• Step 3. Conduct Cost-Benefit Analysis

  • The extent to which a control is cost-effective is determined. The benefit (e.g., risk reduction) of applying a control with its subsequent cost of application is considered. Controls that are not cost-effective are also identified during this step.
  • Output - Documented cost-benefit analysis of either implementing or not implementing each specific control

• Step 4. Select Control(s)

  • Taking into account the information and results from previous steps, Meru Health’s mission, and other important criteria, the Risk Management Team determines the best control(s) for reducing risks to the information systems and to the confidentiality, integrity, and availability of ePHI. These controls may consist of a mix of administrative, physical, and/or technical safeguards.
  • Output - Selected control(s)

• Step 5. Assign Responsibility

  • The workforce members with the skills necessary to implement each of the specific controls outlined in the previous step are identified and assigned responsibilities. The equipment, training and other resources needed for the successful implementation of controls are identified. Resources may include time, money, equipment, etc.
  • Output - List of resources, responsible persons and their assignments

• Step 6. Develop Safeguard Implementation Plan

  • An overall implementation or action plan and individual project plans needed to implement the safeguards and controls identified are developed. The Implementation Plan contains the following information:
  • Each risk or vulnerability/threat pair and risk level;
  • Prioritized actions;
  • The recommended feasible control(s) for each identified risk;
  • Required resources for implementation of selected controls;
  • Team member responsible for implementation of each control;
  • Start date for implementation
  • Target date for completion of implementation;
  • Maintenance requirements.
  • The overall implementation plan provides a broad overview of the safeguard implementation, identifying important milestones and timeframes, resource requirements (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 Meru Health Senior Management.
  • Individual project plans for safeguard implementation are developed and contain detailed steps that resources assigned carry out to meet implementation timeframes and expectations.
  • Output - Safeguard Implementation Plans

• Step 7. Implement Selected Controls

  • Controls are implemented and the affected system(s) are monitored to verify that the implemented controls continue to meet expectations.
  • Meru Health staff continually and consistently communicate status and expectations to all Risk Management Team members, as well as senior management and other key people throughout the risk mitigation process. New risks are identified and evaluated for when controls lower or offset risk rather than eliminate it.
  • Additional monitoring is implemented during times of major environmental changes, organizational or process changes, or major facilities changes.
  • Output - Residual Risk documentation

4.3.3 Risk Management Schedule

The two principal 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 continuous improvement of Meru Health’s information security program:

• Scheduled Basis - an overall risk assessment of Meru Health’s information system infrastructure will be conducted annually. The assessment process will be completed in a timely fashion so that risk mitigation strategies can be determined and included in the corporate budgeting process.
• Throughout the 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 will be undertaken as a part of the maintenance of the system.
• 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 Meru Health’s Platform.

4.4 Process Documentation

Documentation of all risk assessment, risk management, and risk mitigation efforts is maintained for a minimum of six years.

5. Roles Policy

Meru Health has a Security Officer [164.308(a)(2)] and Privacy Officer [164.308(a)(2)] appointed to assist in maintaining and enforcing safeguards towards compliance. The responsibilities associated with these roles are outlined below.

5.1 Applicable Standards

5.1.1 Applicable Standards from the HITRUST Common Security Framework

• 02.f - Disciplinary Process
• 06.d - Data Protection and Privacy of Covered Information
• 06.f - Prevention of Misuse of Information Assets
• 06.g - Compliance with Security Policies and Standards

5.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(2) - Assigned Security Responsibility
• 164.308(a)(5)(i) - Security Awareness and Training

5.2 Privacy Officer

The Privacy Officer is responsible for assisting with compliance and security training for workforce members, assuring the organization remains in compliance with evolving compliance rules, and helping the Security Officer in his responsibilities.

1. Provides annual training to all workforce members of established policies and procedures as necessary and appropriate to carry out their job functions, and documents the training provided.
2. Assists in the administration and oversight of business associate agreements.
3. Manage relationships with customers and partners as those relationships affect security and compliance of ePHI.
4. Assist Security Officer as needed.

The current Meru Health Privacy Officer is Ryan Cummings (ryan@meruhealth.com).

5.2.1 Workforce Training Responsibilities

1. The Privacy Officer facilitates the training of all workforce members as follows:
   1. New workforce members within their first 30 days of employment;
   2. Existing workforce members annually;
   3. Existing workforce members whose functions are affected by a material change in the policies and procedures, within a month after the material change becomes effective;
   4. Existing workforce members as needed due to changes in security and risk posture of Meru Health.
2. The Security Officer or designee maintains documentation of the training session materials and attendees for a minimum of six years.
3. The training session focuses on, but is not limited to, the following subjects defined in Meru Health’s security policies and procedures:
   1. HIPAA Privacy, Security, and Breach notification rules;
   2. Risk Management procedures and documentation;
   3. Auditing. Meru Health may monitor access and activities of all users;
   4. Users may not download software onto Meru Health’s workstations and/or systems without prior approval from the Security Officer;
   5. Users are required to report malicious software to the Security Officer immediately;
   6. Users are required to report unauthorized attempts, uses of, and theft of Meru Health’s systems and/or workstations;
   7. Users are required to report unauthorized access to facilities
   8. Users are required to report noted log-in discrepancies (i.e. application states users last log-in was on a date user was on vacation);
   9. Users may not alter ePHI maintained in a database, unless requested to do so by a Patient’s care team member to correct an error in the data;
   10. Users are required to understand their role in Meru Health’s contingency plan;
   11. Users may not share their user names nor passwords with anyone;
   12. Requirements for users to create and change passwords;
   13. Users must set all applications that contain or transmit ePHI to automatically log off after 15 minutes of inactivity;
   14. Supervisors are required to report terminations of workforce members and other outside users;
   15. Supervisors are required to report a change in a users title, role, department, and/or location;
   16. Procedures to backup ePHI;
   17. Procedures to move and record movement of hardware and electronic media containing ePHI;
   18. Procedures to dispose of discs, CDs, hard drives, and other media containing ePHI;
   19. Procedures to re-use electronic media containing ePHI;
   20. SSH key and sensitive document encryption procedures.

5.3 Security Officer

The Security Officer is responsible for facilitating the training and supervision of all workforce members [164.308(a)(3)(ii)(A) and 164.308(a)(5)(ii)(A)], investigation and sanctioning of any workforce member that is in violation of Meru Health security policies and non-compliance with the security regulations [164.308(a)(1)(ii)(c)], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)].

The current Meru Health Security Officer is Ryan Cummings (ryan@meruhealth.com).

5.3.1 Organizational Responsibilities

The Security Officer, in collaboration with the Privacy Officer, is responsible for facilitating the development, testing, implementation, training, and oversight of all activities pertaining to Meru Health’s efforts to be compliant with the HIPAA Security Regulations, HITRUST CSF, and any other security and compliance frameworks. The intent of the Security Officer Responsibilities is to maintain the confidentiality, integrity, and availability of ePHI. The Security Officer is appointed by and reports to the Board of Directors and the CEO.

These organizational responsibilities include, but are not limited to the following:

1. Oversees and enforces all activities necessary to maintain compliance and verifies the activities are in alignment with the requirements.
2. Helps to establish and maintain written policies and procedures to comply with the Security rule and maintains them for six years from the date of creation or date it was last in effect, whichever is later.
3. Reviews and updates policies and procedures as necessary and appropriate to maintain compliance and maintains changes made for six years from the date of creation or date it was last in effect, whichever is later.
4. Facilitates audits to validate compliance efforts throughout the organization.
5. Documents all activities and assessments completed to maintain compliance and maintains documentation for six years from the date of creation or date it was last in effect, whichever is later.
6. Provides copies of the policies and procedures to management, customers, and partners, and has them available to review by all other workforce members to which they apply.
7. Annually, and as necessary, reviews and updates documentation to respond to environmental or operational changes affecting the security and risk posture of ePHI stored, transmitted, or processed within Meru Health infrastructure.
8. Develops and provides periodic security updates and reminder communications for all workforce members.
9. Implements procedures for the authorization and/or supervision of workforce members who work with ePHI or in locations where it may be accessed.
10. Maintains a program promoting workforce members to report non-compliance with policies and procedures.
    • Promptly, properly, and consistently investigates and addresses reported violations and takes steps to prevent recurrence.
    • Applies consistent and appropriate sanctions against workforce members who fail to comply with the security policies and procedures of Meru Health.
    • Mitigates, to the extent practicable, any harmful effect known to Meru Health of a use or disclosure of ePHI in violation of Meru Health’s policies and procedures, even if effect is the result of actions of Meru Health business associates, customers, and/or partners.
11. Reports security efforts and incidents to administration immediately upon discovery. Responsibilities in the case of a known ePHI breach are documented in the Meru Health Breach Policy.
12. The Security Officer facilitates the communication of security updates and reminders to all workforce members to which it pertains. Examples of security updates and reminders include, but are not limited to:
    • Latest malicious software or virus alerts;
    • Meru Health’s requirement to report unauthorized attempts to access ePHI;
    • Changes in creating or changing passwords;
    • Additional security-focused training is provided to all workforce members by the Security Officer. This training includes, but is not limited to:
    • Data backup plans;
    • System auditing procedures;
    • Redundancy procedures;
    • Contingency plans;
    • Virus protection;
    • Patch management;
    • Media Disposal and/or Re-use;
    • Documentation requirements.
13. The Security Officer works with the CFO to ensure that any security objectives have appropriate consideration during the budgeting process.
    • In general, security and compliance are core to Meru Health’s technology and service offerings; in most cases this means security-related objectives cannot be split out to separate budget line items.
    • For cases that can be split out into discrete items, such as licenses for commercial tooling, the Security Officer follows Meru Health’s standard corporate budgeting process.
      • At the beginning of every fiscal year, the CFO contacts the Security Officer to plan for the upcoming year’s expenses.
      • The Security Officer works with the CFO to forecast spending needs based on the previous year’s level, along with changes for the upcoming year such as additional staff hires.
      • During the year, if an unforeseen security-related expense arises that was not in the budget forecast, the Security Officer works with the CFO to reallocate any resources as necessary to cover this expense.

5.3.2 Supervision of Workforce Responsibilities

Although the Security Officer is responsible for implementing and overseeing all activities related to maintaining compliance, it is the responsibility of all workforce members (i.e. team leaders, supervisors, managers, directors, co-workers, etc.) to supervise all workforce members and any other user of Meru Health’s systems, applications, servers, workstations, etc. that contain ePHI.

1. Monitor workstations and applications for unauthorized use, tampering, and theft and report non-compliance according to the Security Incident Response policy.
2. Assist the Security and Privacy Officers to ensure appropriate role-based access is provided to all users.
3. Take all reasonable steps to hire, retain, and promote workforce members and provide access to users who comply with the Security regulation and Meru Health’s security policies and procedures.

5.3.3 Sanctions of Workforce Responsibilities

All workforce members report non-compliance of Meru Health’s policies and procedures to the Security Officer or other individual as assigned by the Security Officer. Individuals that report violations in good faith may not be subjected to intimidation, threats, coercion, discrimination against, or any other retaliatory action as a consequence.

1. The Security Officer promptly facilitates a thorough investigation of all reported violations of Meru Health’s security policies and procedures. The Security Officer may request assistance from others.
   • Complete an audit trail/log to identify and verify the violation and sequence of events.
   • Interview any individual that may be aware of or involved in the incident.
   • All individuals are required to cooperate with the investigation process and provide factual information to those conducting the investigation.
   • Provide individuals suspected of non-compliance of the Security rule and/or Meru Health’s policies and procedures the opportunity to explain their actions.
   • The investigator thoroughly documents the investigation as the investigation occurs. This documentation must include a list of all employees involved in the violation.
2. Violation of any security policy or procedure by workforce members may result in corrective disciplinary action, up to and including termination of employment. Violation of this policy and procedures by others, including business associates, customers, and partners may result in termination of the relationship and/or associated privileges. Violation may also result in civil and criminal penalties as determined by federal and state laws and regulations.
3. The Security Officer facilitates taking appropriate steps to prevent recurrence of the violation (when possible and feasible).
4. In the case of an insider threat, the Security Officer and Privacy Officer are to set up a team to investigate and mitigate the risk of insider malicious activity. Meru Health workforce members are encouraged to come forward with information about insider threats, and can do so anonymously.
5. The Security Officer maintains all documentation of the investigation, sanctions provided, and actions taken to prevent reoccurrence for a minimum of six years after the conclusion of the investigation.

6. Data Management Policy

Meru Health has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI) stored on Meru Health Platform. The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by Meru Health.

Data backup is an important part of the day-to-day operations of Meru Health. To protect the confidentiality, integrity, and availability of ePHI, both for Meru Health and its patients, complete backups are done daily to assure that data remains available when it needed and in case of a disaster.

Violation of this policy and its procedures by workforce members may result in corrective disciplinary action, up to and including termination of employment.

6.1 Applicable Standards

6.1.1 Applicable Standards from the HITRUST Common Security Framework

• 01.v - Information Access Restriction

6.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(7)(ii)(A) - Data Backup Plan
• 164.310(d)(2)(iii) - Accountability
• 164.310(d)(2)(iv) - Data Backup and Storage

6.2 Backup Policy and Procedures

All ePHI on Meru Health Platform is hosted using PHI PaaS provider GCP. GCP Backup Service is used for performing daily backups and managing the restoration process in case of a failure, in accordance with HIPAA Security Rule and HITRUST CSF.

For any data on other platforms, Security Officer makes sure that adequate backup policies and procedures are in place. If these do not satisfy Meru Health’s requirements, the following process is used for creating additional supplemental backups:

1. Perform daily snapshot backups.
2. The Meru Health DevOps Team is designated to be in charge of backups.
3. DevOps Team members are trained and assigned to complete backups and manage the backup media.
4. Document backups
   • Name of the system
   • Date & time of backup
   • Where backup stored (or to whom it was provided)
5. Securely encrypt stored backups in a manner that protects them from loss or environmental damage.
6. Test backups and document that files have been completely and accurately restored from the backup media.

7. System Access Policy

Access to Meru Health systems and applications is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization’s information systems. These safeguards have been established to address the HIPAA Security regulations including the following:

7.1 Applicable Standards

7.1.1 Applicable Standards from the HITRUST Common Security Framework

• 01.d - User Password Management
• 01.f - Password Use
• 01.r - Password Management System
• 01.a - Access Control Policy
• 01.b - User Registration
• 01.h - Clear Desk and Clear Screen Policy
• 01.j - User Authentication for External Connections
• 01.q - User Identification and Authentication
• 01.v - Information Access Restriction
• 02.i - Removal of Access Rights
• 06.e - Prevention of Misuse of Information Assets

7.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308a4iiC Access Establishment and Modification
• 164.308a3iiB Workforce Clearance Procedures
• 164.308a4iiB Access Authorization
• 164.312d Person or Entity Authentication
• 164.312a2i Unique User Identification
• 164.308a5iiD Password Management
• 164.312a2iii Automatic Logoff
• 164.310b Workstation Use
• 164.310c Workstation Security
• 164.308a3iiC Termination Procedures

7.2 Access Establishment and Modification

1. RBAC (Role Based Access Control) is utilized for all employees at Meru Health and established by management role assignment.

Exceptions to RBAC follow the below process

1. Requests for access to Meru Health Platform systems and applications is made formally using the following process:
   1. A Meru Health workforce member initiates the access request by creating an Issue in the Meru Health Quality Management System.
      • User identities must be verified prior to granting access to new accounts.
      • Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
      • For new accounts, the method used to verify the user’s identity must be recorded on the Issue.
   2. The Security Officer or Privacy Officer will grant access to systems as dictated by the employee’s job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
   3. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
   4. If the review is approved, the Security Officer or Privacy Officer then marks the Issue as Done, adding any pertinent notes required. The Security Officer or Privacy Officer then grants requested access.
      • New accounts will be created with a temporary secure password that meets all requirements from §7.12, which must be changed on the initial login.
      • All password exchanges must occur over an authenticated channel.
      • Access grants are accomplished by leveraging the access control mechanisms built into the systems in question. Account management for non-production systems may be delegated to a Meru Health employee at the discretion of the Security Officer or Privacy Officer .
2. Access is not granted until receipt, review, and approval by the Meru Health Security Officer or Privacy Officer ;
3. The request for access is retained for future reference.
4. All access to Meru Health systems and services is reviewed and updated on a bi-annual basis to ensure proper authorizations are in place commensurate with job functions. The process for conducting reviews is outlined below:
   1. The Security Officer initiates the review of user access by creating an Issue in the Meru Health Quality Management System.
   2. The Security Officer is assigned to review levels of access for each Meru Health workforce member.
   3. If user access is found during review that is not in line with the least privilege principle, the process below is used to modify user access and notify the user of access changes. Once those steps are completed, the Issue is then reviewed again.
   4. Once the review is completed, 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.
   6. Review of user access is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.
5. Any Meru Health workforce member can request change of access using the process outlined in §7.2 paragraph 1.
6. Temporary accounts are not used unless absolutely necessary for business purposes.
   • Accounts are reviewed every 90 days to ensure temporary accounts are not left unnecessarily.
   • Accounts that are inactive for over 90 days are removed.
7. In the case of non-personal information, such as generic educational content, identification and authentication may not be required.
8. All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.
9. Generic accounts are not allowed on Meru Health systems.
10. In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security and Privacy Officer to limit access and reduce risk of unauthorized access.
11. Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.

7.3 Workforce Clearance

1. The level of security assigned to a user to the organization’s information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user’s job classification and/or to a user needing access to carry out treatment, payment, or healthcare operations.
2. All access requests are treated on a “least-access principle.”
3. Meru Health maintains a minimum necessary approach to access to Patient data. As such, only limited members of the organization have access to ePHI and only to the extent necessary for performing their function. Meru Health’s careteam members have access only to data concerning patients assigned to their careteams.

7.4 Access Authorization

1. Role based access categories for each Meru Health system and application are pre-approved by the Security Officer, or an authorized delegate of the Security Officer.
2. Meru Health utilizes hardware and software firewalls provided as part of GCP PaaS service offering to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.

7.5 Person or Entity Authentication

1. Each workforce member has and uses a unique user ID and password that identifies him/her as the user of the information system.
2. Each Patient has a unique user ID and uses an authentication mechanism, such as password, email or phone verification, that identifies him/her as the user of the information system.
3. All User support desk interactions must be verified before Meru Health support personnel will satisfy any request having information security implications.
   • Support issues submitted by email and touching PHI must be verified by Meru Health personnel using a phone number that has been registered with the corresponding account.

7.6 Unique User Identification

1. Access to the Meru Health Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
2. Passwords requirements mandate strong password controls (see below).
3. Passwords are not displayed at any time and are not transmitted or stored in plain text.
4. Default accounts on all production systems, including root, are disabled.
5. Shared accounts are not allowed within Meru Health systems or networks.
6. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with Meru Health workstations or production systems.

7.7 Automatic Logoff

1. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
2. Information systems automatically log users off the systems after 15 minutes of inactivity.
3. The Security Officer pre-approves exceptions to automatic log off requirements.

7.8 Workstation Use

7.8.1 Company Equipment

The following requirements apply to all workstations used by Meru Health employees. If a workstation is employee owned, such as with part time employees, the same requirements apply as for the company owned workstations. Employee owned devices are allowed with approval from the Security Officer. The Security Officer assists users in setting up necessary configurations to comply with the requirements.

1. Workstations may not be used to engage in any activity that is illegal or is in violation of organization’s policies.
2. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through organization’s system.
3. Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
4. Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
5. Transmitted messages may not contain material that criticizes the organization, its providers, its employees, or others.
6. Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
7. Workstation hard drives will be encrypted using FileVault 2.0 or equivalent.
8. All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.
9. All workstations automatically empty their trash every 30 days.
10. All workstations must have a company mobile device manage profile installed.
11. All workstations must have updated and company managed antivirus software installed.

7.8.2 BYOD (Bring your own Device) Policy

Meru Health employees may use their own personal device for work purposes with Security Officer approval. Personally owned devices shall only be used following the below conditions.

1. BYOD device shall not store company information
2. BYOD device must not have access to sensitive information.
3. All BYOD devices must have a company mobile device manage profile installed.
4. All BYOD workstations must have a company mobile device manage profile installed.
5. All BYOD workstations must have updated and company managed antivirus software installed.
6. The BYOD may be remotely wiped if 1) the device is lost, 2) the employee terminates his or her employment, 3) IT detects a data or policy breach, a virus or similar threat to the security of the company’s data and technology infrastructure

7.9 Wireless Access Use

1. Meru Health production systems are not accessible directly over wireless channels.
2. Wireless access is disabled on all production systems.
3. When accessing production systems via remote wireless connections, the same system access policies and procedures apply to wireless as all other connections, including wired.
4. Wireless networks managed within Meru Health non-production facilities (offices, etc.) are secured with the following configurations:
   • All data in transit over wireless is encrypted using WPA2 encryption;
   • Passwords are rotated on a regular basis, presently yearly. This process is managed by the Meru Health Security Officer.

7.10 Employee Termination Procedures

1. The Human Resources Department (or other designated department), users, and their supervisors are required to notify the Security Officer upon completion and/or termination of access needs and facilitating completion of the “Termination Checklist”.
2. The Human Resources Department, users, and supervisors are required to notify the Security Officer to terminate a user’s access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):
   • The user has been using their access rights inappropriately;
   • A user’s password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
   • An unauthorized individual is utilizing a user’s User Login ID and password (a new password may be provided to the user if the user is not identified as providing the unauthorized individual with the User Login ID and password).
3. The Security Officer will terminate users’ access rights immediately upon notification, and will coordinate with the appropriate Meru Health employees to terminate access to any non-production systems managed by those employees.
4. The Security Officer audits and may terminate access of users that have not logged into organization’s information systems/applications for an extended period of time.

7.11 Paper Records

Meru Health does not use paper records for any sensitive information. Use of paper for recording and storing sensitive data is against Meru Health policies.

7.12 Password Management

1. User IDs and passwords are used to control access to Meru Health systems and may not be disclosed to anyone for any reason.
2. Users may not allow anyone, for any reason, to have access to any information system using another user’s unique user ID and password.
3. On all production systems and applications in the Meru Health environment, password configurations are set to require:
   • a minimum length of 16 characters
   • using two factor authentication in all online systems containing PHI
4. All system and application passwords must be stored and transmitted securely.
   • Where possible, passwords should be stored in a hashed format using a salted cryptographic hash function (SHA-256 or equivalent).
   • Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in §17.8.
   • Transmitted passwords must be encrypted in flight pursuant to the requirements in §17.9.
5. Passwords are inactivated immediately upon an employee’s termination (refer to the Employee Termination Procedures in §7.10).
6. Upon initial login, users must change any passwords that were automatically generated for them.
7. Password change methods must use a confirmation method to correct for user input errors.
8. All passwords used in configuration scripts are secured and encrypted.
9. If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Office.
10. In cases where a user has forgotten their password, the following procedure is used to reset the password.
    • The user submits a password reset request to password-reset@meruhealth.com. The request should include the system to which the user has lost access and needs the password reset.
    • An administrator with password reset privileges is notified and connects directly with the user requesting the password reset.
    • The administrator verifies the identity of the user either in-person or through a separate communication channel such as phone or Slack.
    • Once verified, the administrator resets the password.

The password-reset email inbox is used to track and store password reset requests. The Security Officer is the owner of this group and modifies membership as needed.

7.13 Employee and Care Team Access to ePHI

1. Employees may not download ePHI to any workstations used to connect to production systems.
2. Server administrators utilize GCP Secure Connect for connecting to ePHI servers if necessary. Any download of the data is prevented via technical means.
3. Patient Dashboard does not support download of any PHI except for limited and specific situations. These may be for but not limited to billing, or reporting to the referring physician.

7.14 Patient Access to ePHI

Meru Health patient don’t have direct access to any PHI except that they have themselves entered in the patient application, such as messages exchanged with the careteam.

8. Auditing Policy

Meru Health shall audit access and activity of electronic protected health information (ePHI) applications and systems in order to ensure compliance. The Security Rule requires healthcare organizations to implement reasonable hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. Meru Health shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

It is the policy of Meru Health to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, Meru Health shall audit access and activity to detect, report, and guard against:

• Network vulnerabilities and intrusions;
• Breaches in confidentiality and security of patient protected health information;
• Performance problems and flaws in applications;
• Improper alteration or destruction of ePHI;
• Out of date software and/or software known to have vulnerabilities.

This policy applies to all Meru Health Add-on systems, that store, transmit, or process ePHI.

8.1 Applicable Standards

8.1.1 Applicable Standards from the HITRUST Common Security Framework

• 0.a Information Security Management Program
• 01.a Access Control Policy
• 01.b User Registration
• 01.c Privilege Management
• 09.aa Audit Logging
• 09.ac Protection of Log Information
• 09.ab - Monitoring System Use
• 06.e - Prevention of Misuse of Information

8.1.2 Applicable Standards from the HIPAA Security Rule

• 45 CFR §164.308(a)(1)(ii)(D) - Information System Activity Review
• 45 CFR §164.308(a)(5)(ii)(B) & (C) - Protection from Malicious Software & Log-in Monitoring
• 45 CFR §164.308(a)(2) - HIPAA Security Rule Periodic Evaluation
• 45 CFR §164.312(b) - Audit Controls
• 45 CFR §164.312(c)(2) - Mechanism to Authenticate ePHI
• 45 CFR §164.312(e)(2)(i) - Integrity Controls

8.2 Auditing Policies

1. Responsibility for auditing information system access and activity is assigned to Meru Health’s Security Officer. The Security Officer shall:
   • Assign the task of generating reports for audit activities to the workforce member responsible for the application, system, or network;
   • Assign the task of reviewing the audit reports to the workforce member responsible for the application, system, or network, the Privacy Officer, or any other individual determined to be appropriate for the task;
   • Organize and provide oversight to a team structure charged with audit compliance activities (e.g., parameters, frequency, sample sizes, report formats, evaluation, follow-up, etc.).
   • All connections to Meru Health are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
2. Meru Health’s auditing processes shall address access and activity at the following levels listed below. Auditing processes may address date and time of each log-on attempt, date and time of each log-off attempt, devices used, functions performed, etc.
   • User: User level audit trails are implemented to monitor and log commands directly initiated by the user including all identification and authentication attempts.
   • Application: Application level audit trails are implemented to monitor and log all application requests, including data accessed and modified and specific actions including any access of PHI.
   • System: System level audit trails are implemented to monitor and log system activities, applications accessed, and other system defined specific actions including deployment of new code or other software changes.
   • Network: Network level audit trails are implemented to monitor information on network activity, detected penetrations and vulnerabilities.
3. User level logging is used to monitor any access to the ePHI by Meru Health medical personnel or employees. Logging trail includes information on what data was accessed, what patient does the data belong to, what action was taken, such as read or write, as well as date and time of the access.
4. Application level logging includes any events associated with the application. These may be system level actions taken, such as configuration changes, application update deploys or application restarts, and any errors occurred within the application. Error logs are implemented so they do not contain any ePHI in them.
5. The process for review of audit logs, trails, and reports shall include:
   • Description of the activity as well as rationale for performing the audit.
   • Identification of which Meru Health workforce members will be responsible for review (workforce members shall not review audit logs that pertain to their own system activity).
   • Frequency of the auditing process.
   • Determination of significant events requiring further review and follow-up.
   • Identification of appropriate reporting channels for audit results and required follow-up.
6. Meru Health shall identify “trigger events” or criteria that raise awareness of questionable conditions of viewing of confidential information.
7. Logs are reviewed weekly by the Security Officer.
8. Software patches and updates will be applied to all systems in a timely manner.

8.3 Audit Requests

1. A request may be made for an audit for a specific cause. The request may come from a variety of sources including, but not limited to, Privacy Officer, Security Officer, Customer, Patient, Partner, or an Application owner or application user.
2. A request for an audit for specific cause must include time frame, frequency, and nature of the request. The request must be reviewed and approved by Meru Health’s Privacy or Security Officer.
3. A request for an audit must be approved by Meru Health’s Privacy Officer and/or Security Officer before proceeding. Under no circumstances shall detailed audit information be shared with parties without proper permissions and access to see such data.
   • Should the audit disclose that a workforce member has accessed ePHI inappropriately, the minimum necessary/least privileged information shall be shared with Meru Health’s Security Officer to determine appropriate sanction/corrective disciplinary action.
   • Only de-identified information shall be shared with Customer or Partner regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by Meru Health’s Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that Meru Health consider seeking risk management and/or legal counsel.

8.4 Review and Reporting of Audit Findings

1. Audit information that is routinely gathered must be reviewed in a timely manner, currently monthly, by the responsible workforce member(s). On a quarterly basis, logs are reviewed to assure the proper data is being captured and retained. The following process details how log reviews are done at Meru Health:
   1. The Security Officer initiates the log review by creating an Issue in the Meru Health Quality Management System.
   2. The Security Officer, or a Meru Health Security Engineer assigned by the Security Officer, is assigned to review the logs.
   3. Relevant audit log findings are added to the Issue; these findings are investigated in a later step. Once those steps are completed, the Issue is then reviewed again.
   4. Once the review is completed, the Security Officer approves or rejects the Issue. Relevant findings are reviewed at this stage. If the Issue is rejected, it goes back for further review and documentation. The communications protocol around specific findings are outlined below.
   5. If the Issue is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
2. The reporting process shall allow for meaningful communication of the audit findings to those workforce members, Customers, or Partners requesting the audit.
   • Significant findings shall be reported immediately in a written format. Meru Health’s security incident response form may be utilized to report a single event.
   • Routine findings shall be reported to the sponsoring leadership structure in a written report format.
3. Reports of audit results shall be limited to internal use on a minimum necessary/need-to-know basis. Audit results shall not be disclosed externally without administrative and/or legal counsel approval.
4. Security audits constitute an internal, confidential monitoring practice that may be included in Meru Health’s performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable e PHI shall not be included in the reports).
5. Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.
6. Log review activity is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.

8.5 Auditing Customer and Partner Activity

1. Periodic monitoring of Customer and Partner activity shall be carried out to ensure that access and activity is appropriate for privileges granted and necessary to the arrangement between Meru Health and the 3rd party. Meru Health will make every effort to assure Customers and Partners do not gain access to data outside of their own Environments.
2. If it is determined that the Customer or Partner has exceeded the scope of access privileges, Meru Health’s leadership must remedy the problem immediately.
3. If it is determined that a Customer or Partner has violated the terms of the HIPAA business associate agreement or any terms within the HIPAA regulations, Meru Health must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.

8.6 Audit Log Security Controls and Backup

1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy.
2. All audit logs are protected in transit and encrypted at rest to control access to the content of the logs.
3. Audit logs shall be stored on a separate system to minimize the impact auditing may have on the privacy system and to prevent access to audit trails by those with system administrator privileges.
   • Separate systems are used to apply the security principle of “separation of duties” to protect audit trails from hackers.
   • Meru Health utilizes GCP logging infrastructure that includes a logging API to capture all required data elements. The logging toolkit provides message summarization, reduction, and reporting functionality.

8.7 Workforce Training, Education, Awareness and Responsibilities

Meru Health workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI. Meru Health’s commitment to auditing access and activity of the information applications, systems, and networks is communicated through new employee orientation, ongoing training opportunities and events, and applicable policies. Meru Health workforce members are made aware of responsibilities with regard to privacy and security of information as well as applicable sanctions/corrective disciplinary actions should the auditing process detect a workforce member’s failure to comply with organizational policies.

8.8 External Audits of Information Access and Activity

1. Prior to contracting with an external audit firm, Meru Health shall:
   • Outline the audit responsibility, authority, and accountability;
   • Choose an audit firm that is independent of other organizational operations;
   • Ensure technical competence of the audit firm staff;
   • Require the audit firm’s adherence to applicable codes of professional ethics;
   • Obtain a signed HIPAA business associate agreement;
   • Assign organizational responsibility for supervision of the external audit firm.

8.9 Retention of Audit Data

1. Audit logs and reports summarizing audit activities shall be retained for a minimum period of six years.
2. Audit log data is retained locally on the audit log server for a one-month period. Beyond that, log data is encrypted and moved to warm storage using automated scripts, and is retained for a minimum of six years.

8.10 Potential Trigger Events

• High risk or problem prone incidents or events.
• Business associate, customer, patient, or partner complaints.
• Known security vulnerabilities.
• Atypical patterns of activity.
• Failed authentication attempts.
• Remote access use and activity.
• Activity post termination.
• Random audits.

9. Configuration Management Policy

Meru Health utilizes automated deployment and configuration management tools. Meru Health maintains a CI/CD (continious integration continious deployment) toolset which automatically configures all Meru Health systems according to established and tested policies, and are used as part of our Disaster Recovery plan and process.

9.1 Applicable Standards

9.1.1 Applicable Standards from the HITRUST Common Security Framework

• 06 - Configuration Management

9.1.2 Applicable Standards from the HIPAA Security Rule

• 164.310(a)(2)(iii) Access Control & Validation Procedures

9.2.1 Types of Changes

There are 2 types of changes:

Normal Change

A normal change is reviewed and approved following the Configuration Management outline below.

Emergency Change

A emergency change is made as soon as possible to prevent negative effects, such as a security incident or system degragation/outage. These changes are made to prevent negative impact and reviewed after following the below process.

All system changes follow the configuration guidelines below.

9.2.2 Configuration Management Policies

1. Deployment tools are used to standardize and automate configuration management.
2. No systems are deployed into Meru Health environments without approval of the Meru Health CTO.
3. All changes to production systems, network devices, and firewalls are approved by the Meru Health CTO before they are implemented to assure they comply with business and security requirements.
4. All changes to production systems are tested before they are implemented in production.
5. Implementation of approved changes are only performed by authorized personnel.
6. All frontend functionality (developer dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers or containers.
7. All software and systems are tested using unit tests and end to end tests.
8. All committed code is reviewed using pull requests to assure software code quality and proactively detect potential security issues in development.
9. Meru Health utilizes development and staging environments that mirror production to assure proper function.
10. Meru Health also deploys applications locally to assure functionality before moving to staging or production.
11. All formal change requests require unique ID and authentication.
12. Clocks are continuously synchronized to an authoritative source across all systems.

9.3 Provisioning Production Systems

Provisioning of all production systems hosting PHI are managed by Meru Health according to their Configuration Management Policy.

9.4 Changing Existing Systems

All system changes are made by commiting reviewed code. Deployments to production are made by pushing changes to a remote respository managed by Meru Health. Deployment process is monitored with system logs as well as verified after each deploy. If any errors are noted, deployment is rolled back to a previous stable version using the changes request documented rollback process.

9.5 Patch Management Procedures

All Meru utilized PaaS and SaaS are patched as part of their service offering in accordance with their policies.

9.6 Software Development Procedures

1. All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.
   • These changes must be covered under 1) a unit test where possible, and/or 2) integration tests, when appropriate.
2. Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.
   • Commit messages should be wrapped to 72 characters.
   • Commit messages should be written in the present tense. This convention matches up with commit messages generated by commands like git merge and git revert.
3. Once the feature and corresponding tests are complete, a pull request will be created using the GitHub web interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.
4. Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically via an @channel message in Slack.
   • Other engineers will review the changes, using the guidelines above.
   • Engineers should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.
5. If the feature or defect interacts with ePHI, or controls access to data potentially containing ePHI, the code changes must be reviewed by the CTO or security team member before the feature is marked as complete.
   • The CTO or security team member will provide a security analysis of features to ensure they satisfy Meru Health’s compliance and security commitments.
   • This review must include a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10 or the CWE top 25.
   • This review must also verify that any actions performed by authenticated users will generate appropriate audit log entries.
   • Security team members are required to undergo annual training on identifying the most common software vulnerabilities and will receive ongoing training on Meru Health’s compliance and security requirements.
6. Once the review process finishes, each reviewer may approve the pull request using the Github approval workflow, at which point the original author(s) may merge their change into the release branch.

9.7 Software Release Procedures

1. Software releases are treated as changes to existing systems and thus follow the procedure described in §9.4.

10. Facility Access Policy

Meru Health works with Subcontractors to assure restriction of physical access to systems used as part of the Meru Health Platform. Meru Health and its Subcontractors control access to the physical buildings/facilities that house these systems/applications, or in which Meru Health workforce members operate, in accordance to the HIPAA Security Rule 164.310 and its implementation specifications. Physical Access to all of Meru Health facilities is limited to only those authorized in this policy. In an effort to safeguard ePHi from unauthorized access, tampering, and theft, access is allowed to areas only to those persons authorized to be in them and with escorts for unauthorized persons. All workforce members are responsible for reporting an incident of unauthorized visitor and/or unauthorized access to Meru Health’s facility.

Of note, Meru Health does not have ready access to ePHI, it provides cloud-based, compliant web service and communication platform for patients and care personnel. Meru Health does not physically house any systems used by its Platform in Meru Health facilities. Physical security of our systems are outlined in §1.4.

10.1 Applicable Standards

10.1.1 Applicable Standards from the HITRUST Common Security Framework

• 08.b - Physical Entry Controls
• 08.d - Protecting Against External and Environmental Threats
• 08.j - Equipment Maintenance
• 08.l - Secure Disposal or Re-Use of Equipment
• 09.p - Disposal of Media

10.1.2 Applicable Standards from the HIPAA Security Rule

• 164.310(a)(2)(ii) Facility Security Plan
• 164.310(a)(2)(iii) Access Control & Validation Procedures
• 164.310(b-c) Workstation Use & Security

10.2 Meru Health-controlled Facility Access Policies

1. Visitor and third party support access is recorded and supervised. All visitors are escorted.
2. Repairs are documented and the documentation is retained.
3. Fire extinguishers and detectors are installed according to applicable laws and regulations.
4. Maintenance is controlled and conducted by authorized personnel in accordance with supplier-recommended intervals, insurance policies and the organization’s maintenance program.
5. Electronic and physical media containing covered information is securely destroyed (or the information securely removed) prior to disposal.
6. The organization securely disposes media with sensitive information.
7. Enforcement of Facility Access Policies
   • Report violations of this policy to the restricted area’s department team leader, supervisor, manager, or director, or the Privacy Officer.
   • Workforce members in violation of this policy are subject to disciplinary action, up to and including termination.
   • Visitors in violation of this policy are subject to loss of vendor privileges and/or termination of services from Meru Health.
8. Workstation Security
   • Workstations may only be accessed and utilized by authorized workforce members to complete assigned job/contract responsibilities.
   • All workforce members are required to monitor workstations and report unauthorized users and/or unauthorized attempts to access systems/applications as per the System Access Policy.
   • All workstations purchased by Meru Health are the property of Meru Health and are distributed to users by the company.
   • All workstations should be physically secured when not in use

11. Incident Response Policy

Meru Health implements an information security incident response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.

The incident response process addresses:

• Continuous monitoring of threats through intrusion detection systems (IDS) and other monitoring applications;
• Establishment of an information security incident response team;
• Establishment of procedures to respond to media inquiries;
• Establishment of clear procedures for identifying, responding, assessing, analyzing, and follow-up of information security incidents;
• Workforce training, education, and awareness on information security incidents and required responses; and
• Facilitation of clear communication of information security incidents with internal, as well as external, stakeholders

Note: These policies were adapted from work by the HIPAA Collaborative of Wisconsin Security Networking Group. Refer to the linked document for additional copyright information.

11.1 Applicable Standards

11.1.1 Applicable Standards from the HITRUST Common Security Framework

• 11.a - Reporting Information Security Events
• 11.c - Responsibilities and Procedures

11.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(5)(i) - Security Awareness and Training
• 164.308(a)(6) - Security Incident Procedures

11.2 Incident Management Policies

The Meru Health incident response process follows the process recommended by SANS, an industry leader in security. Process flows are a direct representation of the SANS process which can be found in this document.

Meru Health’s incident response classifies security-related events into the following categories:

• Events - Any observable computer security-related occurrence in a system or network with a negative consequence. Examples:
  • Hardware component failing causing service outages.
  • Software error causing service outages.
  • General network or system instability.
• Precursors - A sign that an incident may occur in the future. Examples:
  • Monitoring system showing unusual behavior.
  • Audit log alerts indicated several failed login attempts.
  • Suspicious emails targeting specific Meru Health staff members with administrative access to production systems.
• Indications - A sign that an incident may have occurred or may be occurring at the present time. Examples:
  • IDS alerts for modified system files or unusual system accesses.
  • Antivirus alerts for infected files.
  • Excessive network traffic directed at unexpected geographic locations.
• Incidents - A violation of computer security policies or acceptable use policies, often resulting in data breaches. Examples:
  • Unauthorized disclosure of ePHI.
  • Unauthorized change or destruction of ePHI.
  • A data breach accomplished by an internal or external entity.
  • A Denial-of-Service (DoS) attack causing a critical service to become unreachable.

Meru Health employees must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems (such as email or Slack). In practice this means keeping an eye out for security events, and letting the Security Officer know about any observed precursors or indications as soon as they are discovered.

11.2.1 Identification Phase

1. Immediately upon observation Meru Health members report suspected and known Events, Precursors, Indications, and Incidents in one of the following ways:
   1. Direct report to management, the Security Officer, Privacy Officer, or other;
   2. Email;
   3. Phone call;
   4. Secure Chat.
   5. Anonymously through workforce members desired channels.
2. The individual receiving the report facilitates completion of an Incident Identification form and notifies the Security Officer (if not already done).
3. The Security Officer determines if the issue is an Event, Precursor, Indication, or Incident.
   1. If the issue is an event, indication, or precursor the Security Officer forwards it to the appropriate resource for resolution.
      1. Non-Technical Event (minor infringement): the Security Officer completes a SIR Form and investigates the incident.
      2. Technical Event: Assign the issue to an IT resource for resolution. This resource may also be a contractor or outsourced technical resource, in the event of a small office or lack of expertise in the area.
   2. If the issue is a security incident the Security Officer activates the Security Incident Response Team (SIRT) and notifies senior management.
      1. If a non-technical security incident is discovered the SIRT completes the investigation, implements preventative measures, and resolves the security incident.
      2. Once the investigation is completed, progress to Phase V, Follow-up.
      3. If the issue is a technical security incident, commence to Phase II: Containment.
      4. The Containment, Eradication, and Recovery Phases are highly technical. It is important to have them completed by a highly qualified technical security resource with oversight by the SIRT team.
      5. Each individual on the SIRT and the technical security resource document all measures taken during each phase, including the start and end times of all efforts.
      6. The lead member of the SIRT team facilitates initiation of a SIR Form or an Incident Survey Form. The intent of the SIR form is to provide a summary of all events, efforts, and conclusions of each Phase of this policy and procedures.
4. The Security Officer, Privacy Officer, or Meru Health representative appointed notifies any affected Patients, Customers and Partners. If no Patients, Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer.
5. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to Meru Health and potentially external.

11.2.2 Containment Phase (Technical)

In this Phase, Meru Health’s IT department attempts to contain the security incident. It is extremely important to take detailed notes during the security incident response process. This provides that the evidence gathered during the security incident can be used successfully during prosecution, if appropriate.

1. The SIRT reviews any information that has been collected by the Security Officer or any other individual investigating the security incident.
2. The SIRT secures the network perimeter.
3. The IT department performs the following:
   1. Securely connect to the affected system over a trusted connection.
   2. Retrieve any volatile data from the affected system.
   3. Determine the relative integrity and the appropriateness of backing the system up.
   4. If appropriate, back up the system.
   5. Change the password(s) to the affected system(s).
   6. Determine whether it is safe to continue operations with the affected system(s).
   7. If it is safe, allow the system to continue to function;
      1. Complete any documentation relative to the security incident on the SIR Form.
      2. Move to Phase V, Follow-up.
   8. If it is NOT safe to allow the system to continue operations, discontinue the system(s) operation and move to Phase III, Eradication.
   9. The individual completing this phase provides written communication to the SIRT.
4. Continuously apprise Senior Management of progress.
5. Continue to notify affected Customers and Partners with relevant updates as needed

11.2.3 Eradication Phase (Technical)

The Eradication Phase represents the SIRT’s effort to remove the cause, and the resulting security exposures, that are now on the affected system(s).

1. Determine symptoms and cause related to the affected system(s).
2. Strengthen the defenses surrounding the affected system(s), where possible (a risk assessment may be needed and can be determined by the Security Officer). This may include the following:
   1. An increase in network perimeter defenses.
   2. An increase in system monitoring defenses.
   3. Remediation (“fixing”) any security issues within the affected system, such as removing unused services/general host hardening techniques.
3. Conduct a detailed vulnerability assessment to verify all the holes/gaps that can be exploited have been addressed.
   1. If additional issues or symptoms are identified, take appropriate preventative measures to eliminate or minimize potential future compromises.
4. Complete the Eradication Form.
5. Update the documentation with the information learned from the vulnerability assessment, including the cause, symptoms, and the method used to fix the problem with the affected system(s).
6. Apprise Senior Management of the progress.
7. Continue to notify affected Customers and Partners with relevant updates as needed.
8. Move to Phase IV, Recovery.

11.2.4 Recovery Phase (Technical)

The Recovery Phase represents the SIRT’s effort to restore the affected system(s) back to operation after the resulting security exposures, if any, have been corrected.

1. The technical team determines if the affected system(s) have been changed in any way.
   1. If they have, the technical team restores the system to its proper, intended functioning (“last known good”).
   2. Once restored, the team validates that the system functions the way it was intended/had functioned in the past. This may require the involvement of the business unit that owns the affected system(s).
   3. If operation of the system(s) had been interrupted (i.e., the system(s) had been taken offline or dropped from the network while triaged), restart the restored and validated system(s) and monitor for behavior.
   4. If the system had not been changed in any way, but was taken offline (i.e., operations had been interrupted), restart the system and monitor for proper behavior.
   5. Update the documentation with the detail that was determined during this phase.
   6. Apprise Senior Management of progress.
   7. Continue to notify affected Customers and Partners with relevant updates as needed.
   8. Move to Phase V, Follow-up.

11.2.5 Follow-up Phase (Technical and Non-Technical)

The Follow-up Phase represents the review of the security incident to look for “lessons learned” and to determine whether the process that was taken could have been improved in any way. It is recommended all security incidents be reviewed shortly after resolution to determine where response could be improved. Timeframes may extend to one to two weeks post-incident.

1. Responders to the security incident (SIRT Team and technical security resource) meet to review the documentation collected during the security incident.
2. Create a “lessons learned” document and attach it to the completed SIR Form.
   1. Evaluate the cost and impact of the security incident to Meru Health using the documents provided by the SIRT and the technical security resource.
   2. Determine what could be improved.
   3. Communicate these findings to Senior Management for approval and for implementation of any recommendations made post-review of the security incident.
   4. Carry out recommendations approved by Senior Management; sufficient budget, time and resources should be committed to this activity.
   5. Close the security incident.

11.2.6 Periodic Evaluation

It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding Meru Health’s expectation for them, relative to security responsibilities. The incident response plan is tested annually.

11.3 Security Incident Response Team (SIRT)

Current members of the Meru Health SIRT:

• Privacy Officer
• Security Officer
• Senior Software Engineer

12. Breach Policy

To provide guidance for breach notification when impressive or unauthorized access, acquisition, use and/or disclosure of the ePHI occurs. Breach notification will be carried out in compliance with the American Recovery and Reinvestment Act (ARRA)/Health Information Technology for Economic and Clinical Health Act (HITECH) as well as any other federal or state notification law.

The Federal Trade Commission (FTC) has published breach notification rules for vendors of personal health records as required by ARRA/HITECH. The FTC rule applies to entities not covered by HIPAA, primarily vendors of personal health records. The rule is effective September 24, 2009 with full compliance required by February 22, 2010.

The American Recovery and Reinvestment Act of 2009 (ARRA) was signed into law on February 17, 2009. Title XIII of ARRA is the Health Information Technology for Economic and Clinical Health Act (HITECH). HITECH significantly impacts the Health Insurance Portability and Accountability (HIPAA) Privacy and Security Rules. While HIPAA did not require notification when patient protected health information (PHI) was inappropriately disclosed, covered entities and business associates may have chosen to include notification as part of the mitigation process. HITECH does require notification of certain breaches of unsecured PHI to the following: individuals, Department of Health and Human Services (HHS), and the media. The effective implementation for this provision is September 23, 2009 (pending publication HHS regulations).

In the case of a breach, Meru Health shall notify all affected individuals.

12.1 Applicable Standards

12.1.1 Applicable Standards from the HITRUST Common Security Framework

• 11.a Reporting Information Security Events
• 11.c Responsibilities and Procedures

12.1.2 Applicable Standards from the HIPAA Security Rule

• Security Incident Procedures - 164.308(a)(6)(i)
• HITECH Notification in the Case of Breach - 13402(a) and 13402(b)
• HITECH Timeliness of Notification - 13402(d)(1)
• HITECH Content of Notification - 13402(f)(1)

12.2 Meru Health Breach Policy

1. Discovery of Breach: A breach of ePHI shall be treated as “discovered” as of the first day on which such breach is known to the organization, or, by exercising reasonable diligence would have been known to Meru Health (includes breaches by the organization’s Customers, Partners, or subcontractors). Meru Health shall be deemed to have knowledge of a breach if such breach is known or by exercising reasonable diligence would have been known, to any person, other than the person committing the breach, who is a workforce member or Partner of the organization. Following the discovery of a potential breach, the organization shall begin an investigation (see organizational policies for security incident response and/or risk management incident response) immediately, conduct a risk assessment, and based on the results of the risk assessment, begin the process to notify each Customer affected by the breach. Meru Health shall also begin the process of determining what external notifications are required or should be made (e.g., Secretary of Department of Health & Human Services (HHS), media outlets, law enforcement officials, etc.)
2. Breach Investigation: The Meru Health Security Officer shall name an individual to act as the investigator of the breach (e.g., privacy officer, security officer, risk manager, etc.). The investigator shall be responsible for the management of the breach investigation, completion of a risk assessment, and coordinating with others in the organization as appropriate (e.g., administration, security incident response team, human resources, risk management, public relations, legal counsel, etc.) The investigator shall be the key facilitator for all breach notification processes to the appropriate entities (e.g., HHS, media, law enforcement officials, etc.). All documentation related to the breach investigation, including the risk assessment, shall be retained for a minimum of six years. A template breach log is located here.
3. Risk Assessment: For an acquisition, access, use or disclosure of ePHI to constitute a breach, it must constitute a violation of the HIPAA Privacy Rule. A use or disclosure of ePHI that is incident to an otherwise permissible use or disclosure and occurs despite reasonable safeguards and proper minimum necessary procedures would not be a violation of the Privacy Rule and would not qualify as a potential breach. To determine if an impermissible use or disclosure of ePHI constitutes a breach and requires further notification, the organization will need to perform a risk assessment to determine if there is significant risk of harm to the individual as a result of the impermissible use or disclosure. The organization shall document the risk assessment as part of the investigation in the incident report form noting the outcome of the risk assessment process. The organization has the burden of proof for demonstrating that all notifications to appropriate Customers or that the use or disclosure did not constitute a breach. Based on the outcome of the risk assessment, the organization will determine the need to move forward with breach notification. The risk assessment and the supporting documentation shall be fact specific and address:
   • Consideration of who impermissibly used or to whom the information was impermissibly disclosed;
   • The type and amount of ePHI involved;
   • The cause of the breach, and the entity responsible for the breach, either Customer, Meru Health, or Partner.
   • The potential for significant risk of financial, reputational, or other harm.
4. Timeliness of Notification: Upon discovery of a breach, notice shall be made to the affected Patients no later than 24 hours after the discovery of the breach. It is the responsibility of the organization to demonstrate that all notifications were made as required, including evidence demonstrating the necessity of delay.
5. Delay of Notification Authorized for Law Enforcement Purposes: If a law enforcement official states to the organization that a notification, notice, or posting would impede a criminal investigation or cause damage to national security, the organization shall:
   • If the statement is in writing and specifies the time for which a delay is required, delay such notification, notice, or posting of the timer period specified by the official; or
   • If the statement is made orally, document the statement, including the identify of the official making the statement, and delay the notification, notice, or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement as described above is submitted during that time.
6. Content of the Notice: The notice shall be written in plain language and must contain the following information:
   • A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known;
   • A description of the types of unsecured protected health information that were involved in the breach (such as whether full name, Social Security number, date of birth, home address, account number, diagnosis, disability code or other types of information were involved), if known;
   • Any steps the Customer should take to protect Customer data from potential harm resulting from the breach.
   • A brief description of what Meru Health is doing to investigate the breach, to mitigate harm to individuals and Customers, and to protect against further breaches.
   • Contact procedures for individuals to ask questions or learn additional information, which may include a telephone number, an e-mail address, a web site, or postal address.
7. Methods of Notification: Patients will be notified via email or phone within the timeframe for reporting breaches, as outlined above.
8. Maintenance of breach information log: As described above and in addition to the reports created for each incident, Meru Health shall maintain a process to record or log all breaches of unsecured ePHI regardless of the number of records and Customers affected. The following information should be collected/logged for each breach (see sample Breach Notification Log):
   • A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known.
   • A description of the types of unsecured protected health information that were involved in the breach (such as full name, Social Security number, date of birth, home address, account number, etc.), if known.
   • A description of the action taken with regard to notification of patients regarding the breach.
   • Resolution steps taken to mitigate the breach and prevent future occurrences.
9. Workforce Training: Meru Health shall train all members of its workforce on the policies and procedures with respect to ePHI as necessary and appropriate for the members to carry out their job responsibilities. Workforce members shall also be trained as to how to identify and report breaches within the organization.
10. Complaints: Meru Health must provide a process for individuals to make complaints concerning the organization’s patient privacy policies and procedures or its compliance with such policies and procedures.
11. Sanctions: The organization shall have in place and apply appropriate sanctions against members of its workforce, Customers, and Partners who fail to comply with privacy policies and procedures.
12. Retaliation/Waiver: Meru Health may not intimidate, threaten, coerce, discriminate against, or take other retaliatory action against any individual for the exercise by the individual of any privacy right. The organization may not require individuals to waive their privacy rights under as a condition of the provision of treatment, payment, enrollment in a health plan, or eligibility for benefits.

12.3 Sample Letter to Patients in Case of Breach

[Date]

[Name] [Name of Customer] [Address 1] [Address 2] [City, State Zip Code]

Dear [Name of Patient]:

I am writing to you from Meru Health, Inc., with important information about a recent breach that affects your user account with us. We became aware of this breach on [Insert Date] which occurred on or about [Insert Date]. The breach occurred as follows:

Describe event and include the following information:

• A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known.
• A description of the types of unsecured protected health information that were involved in the breach (such as whether full name, Social Security number, date of birth, home address, account number, diagnosis, disability code or other types of information were involved), if known.
• Any steps the Customer should take to protect themselves from potential harm resulting from the breach.
• A brief description of what Meru Health is doing to investigate the breach, to mitigate harm to individuals, and to protect against further breaches.
• Contact procedures for individuals to ask questions or learn additional information, which includes a toll-free telephone number, an e-mail address, web site, or postal address.

Other Optional Considerations:

• Recommendations for the customer for remedying the breach.

Sincerely,

Albert Nazander Co-founder - Meru Health, Inc. albert@meruhealth.com 415-670-9417

13. Disaster Recovery Policy

The Meru Health Contingency Plan establishes procedures to recover Meru Health following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the Meru Health Security Officer and Privacy Officer.

The following objectives have been established for this plan:

1. Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:
   • Notification/Activation phase to detect and assess damage and to activate the plan;
   • Recovery phase to restore temporary IT operations and recover damage done to the original system;
   • Reconstitution phase to restore IT system processing capabilities to normal operations.
2. Identify the activities, resources, and procedures needed to carry out Meru Health processing requirements during prolonged interruptions to normal operations.
3. Identify and define the impact of interruptions to Meru Health systems.
4. Assign responsibilities to designated personnel and provide guidance for recovering Meru Health systems during prolonged periods of interruption to normal operations.
5. Ensure coordination with other Meru Health staff who will participate in the contingency planning strategies.
6. Ensure coordination with external points of contact and vendors who will participate in the contingency planning strategies.

This Meru Health Contingency Plan has been developed as required under the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, Appendix III, November 2000, and the Health Insurance Portability and Accountability Act (HIPAA) Final Security Rule, Section §164.308(a)(7), which requires the establishment and implementation of procedures for responding to events that damage systems containing electronic protected health information.

This Meru Health Contingency Plan is created under the legislative requirements set forth in the Federal Information Security Management Act (FISMA) of 2002 and the guidelines established by the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-34, titled “Contingency Planning Guide for Information Technology Systems” dated June 2002.

The Meru Health Contingency Plan also complies with the following federal and departmental policies:

• The Computer Security Act of 1987;
• OMB Circular A-130, Management of Federal Information Resources, Appendix III, November 2000;
• Federal Preparedness Circular (FPC) 65, Federal Executive Branch Continuity of Operations, July 1999;
• Presidential Decision Directive (PDD) 67, Enduring Constitutional Government and Continuity of Government Operations, October 1998;
• PDD 63, Critical Infrastructure Protection, May 1998;
• Federal Emergency Management Agency (FEMA), The Federal Response Plan (FRP), April 1999;
• Defense Authorization Act (Public Law 106-398), Title X, Subtitle G, “Government Information Security Reform,” October 30, 2000

Example of the types of disasters that would initiate this plan are natural disaster, political disturbances, man made disaster, external human threats, internal malicious activities.

Meru Health defines two categories of systems from a disaster recovery perspective.

1. Critical Systems. These systems host application servers and database servers or are required for functioning of systems that host application servers and database servers. These systems, if unavailable, affect the integrity of data and must be restored, or have a process begun to restore them, immediately upon becoming unavailable.
2. Non-critical Systems. These are all systems not considered critical by definition above. These systems, while they may affect the performance and overall security of critical systems, do not prevent Critical systems from functioning and being accessed appropriately. These systems are restored at a lower priority than critical systems.

13.1 Applicable Standards

13.1.1 Applicable Standards from the HITRUST Common Security Framework

• 12.c - Developing and Implementing Continuity Plans Including Information Security

13.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(7)(i) - Contingency Plan

13.2 Line of Succession

The following order of succession to ensure that decision-making authority for the Meru Health Contingency Plan is uninterrupted. The Chief Technology Officer (CTO) is responsible for ensuring the safety of personnel and the execution of procedures documented within this Meru Health Contingency Plan. If the CTO is unable to function as the overall authority or chooses to delegate this responsibility to a successor, the CEO or COO shall function as that authority. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below.

• Albert Nazander, CTO: 415-670-9417, albert@meruhealth.com
• Riku Lindholm, COO: +358-50-493-6488, riku@meruhealth.com

13.3 Responsibilities

Meru Health Dev Ops team has developed and trained to respond to a contingency event affecting the IT system. The team is responsible for recovery of the Meru Health Platform, application servers, and web services. It is also responsible for testing redeployments and assessing damage to the environment. Members of the team include personnel who are responsible for the daily operations and maintenance of Meru Health. The team leader is the CTO and directs the Dev Ops Team.

Members of the Dev Ops team must maintain local copies of the contact information from §13.2. Additionally, the CTO must maintain a local copy of this policy in the event Internet access is not available during a disaster scenario.

13.4 Testing and Maintenance

The CTO shall establish criteria for validation/testing of a Contingency Plan, an annual test schedule, and ensure implementation of the test. This process will also serve as training for personnel involved in the plan’s execution. At a minimum the Contingency Plan shall be tested annually (within 365 days). The types of validation/testing exercises include tabletop and technical testing. Contingency Plans for all application systems must be tested at a minimum using the tabletop testing process. However, if the application system Contingency Plan is included in the technical testing of their respective support systems that technical test will satisfy the annual requirement.

13.4.1 Tabletop Testing

The primary objective of the tabletop test is to ensure designated personnel are knowledgeable and capable of performing the notification/activation requirements and procedures, in a timely manner. The exercises include, but are not limited to:

• Testing to validate the ability to respond to a crisis in a coordinated, timely, and effective manner, by simulating the occurrence of a specific crisis.

13.4.2 Technical Testing

The primary objective of the technical test is to ensure the communication processes and data storage and recovery processes can function at an alternate site to perform the functions and capabilities of the system within the designated requirements. Technical testing shall include, but is not limited to:

• Process from backup system at the alternate site;
• Restore system using backups; and
• Switch compute and storage resources to alternate processing site.

13.5 Disaster Recovery Procedures

13.5.1 Notification and Activation Phase

This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to Meru Health. Based on the assessment of the Event, sometimes according to the Meru Health Incident Response Policy, the Contingency Plan may be activated by the CTO.

The notification sequence is listed below:

• The first responder is to notify the CTO. All known information must be relayed to the CTO.
• The CTO is to contact the Dev Ops Team and inform them of the event. The CTO is to to begin assessment procedures.
• The CTO is to notify team members and direct them to complete the assessment procedures outlined below to determine the extent of damage and estimated recovery time. If damage assessment cannot be performed locally because of unsafe conditions, the CTO is to follow the steps below.
  • Damage Assessment Procedures:
  • The CTO is to logically assess damage, gain insight into whether the infrastructure is salvageable, and begin to formulate a plan for recovery.
  • Alternate Assessment Procedures:
  • Upon notification, the CTO is to follow the procedures for damage assessment with Dev Ops Team.
• The Meru Health Contingency Plan is to be activated if one or more of the following criteria are met:
  • Meru Health systems will be unavailable for more than 24 hours.
  • Other criteria, as appropriate and as defined by Meru Health.
• If the plan is to be activated, the CTO is to notify and inform team members of the details of the event and if relocation is required.
• Upon notification from the CTO, group leaders and managers are to notify their respective teams. Team members are to be informed of all applicable information and prepared to respond and relocate if necessary.
• The CTO is to notify the hosting partners, such as Google Cloud Platform, that a contingency event has been declared and to ship the necessary materials (as determined by damage assessment) to the alternate site.
• The CTO is to notify remaining personnel and executive leadership on the general status of the incident.
• Notification can be message, email, or phone.

13.5.2 Recovery Phase

This section provides procedures for recovering the application at an alternate site, whereas other efforts are directed to repair damage to the original system and capabilities.

The following procedures are for recovering the Meru Health infrastructure at the alternate site. Procedures are outlined per team required. Each procedure should be executed in the sequence it is presented to maintain efficient operations.

Recovery Goal: The goal is to rebuild Meru Health infrastructure to a production state.

The tasks outlined below are not sequential and some can be run in parallel.

1. Contact Partners and Customers affected
2. Assess damage to the environment
3. Begin replication of new environment using automated and tested scripts.
4. Test new environment using pre-written tests
5. Test logging, security, and alerting functionality
6. Assure systems are appropriately patched and up to date
7. Deploy environment to production
8. Update DNS to new environment

13.5.3 Reconstitution Phase

This section discusses activities necessary for restoring Meru Health operations at the original or new site. The goal is to restore full operations within 24 hours of a disaster or outage. When the hosted data center at the original or new site has been restored, Meru Health operations at the alternate site may be transitioned back. The goal is to provide a seamless transition of operations from the alternate site to the computer center.

1. Original or New Site Restoration
   • Begin replication of new environment using automated and tested scripts
   • Test new environment using pre-written tests
   • Test logging, security, and alerting functionality
   • Deploy environment to production
   • Assure systems are appropriately patched and up to date
   • Update DNS to new environment
2. Plan Deactivation
   • If the Meru Health environment is moved back to the original site from the alternative site, all hardware used at the alternate site should be handled and disposed of according to the Meru Health Media Disposal Policy.

14. Disposable Media Policy

Meru Health recognizes that media containing ePHI may be reused when appropriate steps are taken to ensure that all stored ePHI has been effectively rendered inaccessible. Destruction/disposal of ePHI shall be carried out in accordance with federal and state law. The schedule for destruction/disposal shall be suspended for ePHI involved in any open investigation, audit, or litigation.

Most Meru ePHI is stored using GCP Platform as a Service, which in turn utilizes dedicated hardware. ePHI is stored in the GCP hosted environment. Google security policy summary may be found here: https://cloud.google.com/security/overview/whitepaper All storage volumes utilized by Google and Meru Health are encrypted. Meru Health does not use, own, or manage any removable media or tapes that have access to ePHI.

14.1 Applicable Standards

14.1.1 Applicable Standards from the HITRUST Common Security Framework

• 0.9o - Management of Removable Media

14.1.2 Applicable Standards from the HIPAA Security Rule

• 164.310(d)(1) - Device and Media Controls

14.2 Disposable Media Policy

1. All removable media is restricted, audited, and is encrypted.
2. Meru Health assumes all disposable media in its Platform may contain ePHI, so it treats all disposable media with the same protections and disposal policies.
3. All destruction/disposal of ePHI media will be done in accordance with federal and state laws and regulations and pursuant to the Meru Health’s written retention policy/schedule. Records that have satisfied the period of retention will be destroyed/disposed of in an appropriate manner.
4. Records involved in any open investigation, audit or litigation should not be destroyed/disposed of. If notification is received that any of the above situations have occurred or there is the potential for such, the record retention schedule shall be suspended for these records until such time as the situation has been resolved. If the records have been requested in the course of a judicial or administrative hearing, a qualified protective order will be obtained to ensure that the records are returned to the organization or properly destroyed/disposed of by the requesting party.
5. Before reuse of any media, for example all ePHI is rendered inaccessible, cleaned, or scrubbed. All media is formatted to restrict future access.
6. All Meru Health Subcontractors provide that, upon termination of the contract, they will return or destroy/dispose of all patient health information. In cases where the return or destruction/disposal is not feasible, the contract limits the use and disclosure of the information to the purposes that prevent its return or destruction/disposal.
7. Any media containing ePHI is disposed using a method that ensures the ePHI could not be readily recovered or reconstructed.
8. The methods of destruction, disposal, and reuse are reassessed periodically, based on current technology, accepted practices, and availability of timely and cost-effective destruction, disposal, and reuse technologies and services.
9. In the cases of a Meru Health terminating a contract with Google and no longer utilizing Google Services, Meru Health can export its data stored on Google Platform in accordance with Google’s Policies.

15. IDS Policy

Network of Meru Health Platform is partially managed by Google. Meru Health partly inherits Google’s IDS Policy. In order to preserve the integrity of data that Google stores, processes, or transmits for Customers, Google implements strong intrusion detection tools and policies to proactively track and retroactively investigate unauthorized access.

For more information, please refer to Google’s Policy.

15.1 Applicable Standards

15.1.1 Applicable Standards from the HITRUST Common Security Framework

• 09.ab - Monitoring System Use
• 06.e - Prevention of Misuse of Information
• 10.h - Control of Operational Software

15.1.2 Applicable Standards from the HIPAA Security Rule

• 164.312(b) - Audit Controls

16. Vulnerability Scanning Policy

Vulnerability scanning is part of Googles’s PaaS offering for Meru Health. Google conducts vulnerability scanning in accordance with its Vulnerability Scanning Policy.

For more information, please refer to Google’s Policy.

16.1 Applicable Standards

16.1.1 Applicable Standards from the HITRUST Common Security Framework

• 10.m - Control of Technical Vulnerabilities

16.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(8) - Evaluation

16.2 Penentration Testing

An external penetration testing is performed at least once a year by a qualified security researcher / ethical hacker on the security team internally and/or with an external security consulting firm.

17. Data Classification Policy

This data classification policy defines the requirements to ensure that information within the organization is protected at an appropriate level. This document applies to the entire scope of the organization’s information security program. It includes all types of information, regardless of its form, such as paper or electronic documents, applications and databases, and knowledge or information that is not written.

This policy applies to all individuals and systems that have access to information kept by the organization.

17.1 Applicable Standards

17.1.1 Applicable Standards from the HITRUST Common Security Framework

• 07.d - Classification Guidelines
• 07.e - Information Labeling and Handling

17.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(1)(ii)(a) - Risk analysis
• 164.308(a)(1)(ii)(b) - Risk management

17.2 Background

1. This policy defines the high level objectives and implementation instructions for the organization’s data classification scheme. This includes data classification levels, as well as procedures for the classification, labeling and handling of data within the organization. Confidentiality and non-disclosure agreements maintained by the organization must reference this policy.

17.3 Classifications

1. If classified information is received from outside the organization, the person who receives the information must classify it in accordance with the rules prescribed in this policy. The person thereby will become the owner of the information.

   • If classified information is received from outside the organization and handled as part of business operations activities (e.g., customer data on provided cloud services), the information classification, as well as the owner of such information, must be made in accordance with the specifications of the respective customer service agreement and other legal requirements.

2. When classifying information, the level of confidentiality is determined by:

   • The value of the information, based on impacts identified during the risk assessment process. More information on risk assessments is defined in the Risk Assessment Policy (reference (a)).
   • Sensitivity and criticality of the information, based on the highest risk calculated for each information item during the risk assessment.
   • Legal, regulatory and contractual obligations.

Table 3: Information Confidentiality Levels

1. Information must be classified based on confidentiality levels as defined in Table 3.

2. Information and information system owners should try to use the lowest confidentiality level that ensures an adequate level of protection, thereby avoiding unnecessary production costs.

3. Information classified as “Restricted” or “Confidential” must be accompanied by a list of authorized persons in which the information owner specifies the names or job functions of persons who have the right to access that information.

4. Information classified as “Internal Use” must be accompanied by a list of authorized persons only if individuals outside the organization will have access to the document.

5. Information and information system owners must review the confidentiality level of their information assets every five years and assess whether the confidentiality level should be changed. Wherever possible, confidentiality levels should be lowered.

6. For cloud-based software services provided to customers, system owners under the company’s control must also review the confidentiality level of their information systems after service agreement changes or after a customer’s formal notification. Where allowed by service agreements, confidentiality levels should be lowered.

7. Information must be labeled according to the following:

   • Paper documents: the confidentiality level is indicated on the top and bottom of each document page; it is also indicated on the front of the cover or envelope carrying such a document as well as on the filing folder in which the document is stored. If a document is not labeled, its default classification is Internal Use.
   • Electronic documents: the confidentiality level is indicated on the top and bottom of each document page. If a document is not labeled, its default classification is Internal Use.
   • Information systems: the confidentiality level in applications and databases must be indicated on the system access screen, as well as on the screen when displaying such information.
   • Electronic mail: the confidentiality level is indicated in the first line of the email body. If it is not labeled, its default classification is “Internal Use”.
   • Electronic storage media (disks, memory cards, etc.): the confidentiality level must be indicated on the top surface of the media. If it is not labeled, its default classification is “Internal Use”.
   • Information transmitted orally: the confidentiality level should be mentioned before discussing information during face-to-face communication, by telephone, or any other means of oral communication.

8. All persons accessing classified information must follow the guidelines listed in Appendix A, “Handling of Classified Information.”

9. All persons accessing classified information must complete and submit a Confidentiality Statement to their immediate supervisor or company point-of-contact. A sample Confidentiality Statement is in Appendix B.

10. Incidents related to the improper handling of classified information must be reported in accordance with the §11.3.3.

18. Data Integrity Policy

Meru Health takes data integrity very seriously. We strive to assure data is protected from unauthorized access and that it is available when needed. The following policies drive many of our procedures and technical settings in support of the Meru Health mission of data protection.

Production systems that create, receive, store, or transmit Customer data (hereafter “Production Systems”) must follow the guidelines described in this section.

18.1 Applicable Standards

18.1.1 Applicable Standards from the HITRUST Common Security Framework

• 10.b - Input Data Validation

18.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(8) - Evaluation

18.2 Disabling Non-Essential Services

1. All Production Systems must disable services that are not required to achieve the business purpose or function of the system.

18.3 Monitoring Log-in Attempts

1. All access to Production Systems must be logged. This is done following the Meru Health Auditing Policy.

18.4 Prevention of Malware on Production Systems

1. Virus scanning software and malware detection is managed by Google and adheres to their Security Policy.
2. All Production Systems are to only be used for Meru Health business needs.

18.5 Patch Management

1. Software patches and updates will be applied to all systems in a timely manner by Google as part of their PaaS offering.
2. Application and Database versions are kept up-to-date by Meru Health. Updates are done whenever new versions with security improvements become available. Current versions in use are reviewed quarterly by the CTO.

18.6 Intrusion Detection and Vulnerability Scanning

Intrusion detection and vulnerability scanning are done by Google as part of their PaaS offering.

18.7 Production System Security

1. System, network, and server security is managed and maintained by Google.
2. Up to date system lists and architecture diagrams are kept for all production environments.
3. Access to Production Systems is controlled using centralized tools and two-factor authentication.

18.8 Production Data Security

1. Reduce the risk of compromise of Production Data.
2. Implement and/or review controls designed to protect Production Data from improper alteration or destruction.
3. Ensure that confidential data is stored in a manner that supports user access logs and automated monitoring for potential security incidents.
4. Ensure PHI managed by Meru Health is only accessible by the authorized personnel.
5. All Production Data at rest is stored on encrypted volumes using encryption keys managed by Google as part of their PaaS offering.
6. Volume encryption keys and machines that generate volume encryption keys are protected from unauthorized access. Volume encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
7. Encrypted volumes use AES encryption with a minimum of 256-bit keys, or keys and ciphers of equivalent or higher cryptographic strength.

18.9 Transmission Security

1. All data transmission is encrypted end to end using encryption keys managed by Meru Health and Google. Encryption is not terminated at the network end point, and is carried through to the application.
2. Transmission encryption keys and machines that generate keys are protected from unauthorized access. Transmission encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
3. Transmission encryption keys use a minimum of 4096-bit RSA keys, or keys and ciphers of equivalent or higher cryptographic strength (e.g., 256-bit AES session keys in the case of IPsec encryption).
4. Transmission encryption keys are limited to use for one year and then must be regenerated.
5. System logs of all transmissions of Production Data access. These logs must be available for audit.

19. Data Retention Policy

Despite not being a requirement within HIPAA, Meru Health understands and appreciates the importance of health data retention. Meru Health is responsible for health and medical records retention as set forth by each state.

19.1 State Medical Record Laws

• Listing of state requirements for medical record retention

19.2 Data Retention Policy

The organization is bound by multiple legal, regulatory and contractual obligations with regard to the data it retains. These obligations stipulate how long data can be retained, and how data must be destroyed. Examples of legal, regulatory and contractual obligations include laws and regulations in the local jurisdiction where the organization conducts business, and contracts made with employees, customers, service providers, partners and others.

The organization may also be involved in events such as litigation or disaster recovery scenarios that require it to have access to original information in order to protect the organization’s interests or those of its employees, customers, service providers, partners and others. As a result, the organization may need to archive and store information for longer that it may be needed for day-to-day operations.

19.2.1 Information Retension

1. Information used in the development, staging, and testing of systems shall not be retained beyond their active use period nor copied into production or live environments.

2. By default, the retention period of information shall be an active use period of exactly one year from its creation unless an exception is obtained permitting a longer or shorter retention period. The business unit responsible for the information must request the exception.

3. After the active use period of information is over in accordance with this policy and approved exceptions, information must be archived for a defined period. Once the defined archive period is over, the information must be destroyed.

4. Each business unit is responsible for the information it creates, uses, stores, processes and destroys, according to the requirements of this policy. The responsible business unit is considered to be the information owner.

5. The organization’s legal counsel may issue a litigation hold to request that information relating to potential or actual litigation, arbitration or other claims, demands, disputes or regulatory action be retained in accordance with instructions from the legal counsel.

19.2.2 Information Archive

Archiving is defined as secured storage of information such that the information is rendered inaccessible by authorized users in the ordinary course of business but can be retrieved by an administrator designated by company management.

1. Electronic records must be archived with strict access controls set by the information owner and appropriate to secure the confidentiality, integrity and accessibility of the information.

The default archiving period of information shall be 7 years unless an approved exception permits a longer or shorter period. Exceptions must be requested by the information owner.

1. As a guideline, an archiving period of more than 7 years may be granted for information with a vital historical purpose such as corporate records, contracts, and technical/trade secrets.

2. As a guideline, an archiving period of less than 7 years may be granted for information with a limited business purpose such as email, travel itineraries, pre-trip advisories, or to comply with specific legal, contractual and/or regulatory requirements (e.g., PCI DSS, GDPR, etc.)

3. Information must be destroyed (defined below) at the end of the elapsed archiving period.

20. Employees Policy

Meru Health is committed to ensuring all workforce members actively address security and compliance in their roles at Meru Health. As such, training is imperative to assuring an understanding of current best practices, the different types and sensitivities of data, and the sanctions associated with non-compliance.

20.1 Applicable Standards

20.1.1 Applicable Standards from the HITRUST Common Security Framework

• 02.e - Information Security Awareness, Education, and Training
• 06.e - Prevention of Misuse of Information Assets
• 07.c - Acceptable Use of Assets
• 09.j - Controls Against Malicious Code
• 01.y - Teleworking

20.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(5)(i) - Security Awareness and Training

20.2 Employment Policies

1. All new workforce members, including contractors, are given training on security policies and procedures, including operations security, within 30 days of employment.
   • Records of training are kept for all workforce members.
   • Current Meru Health training is hosted in Trainual.
   • Employees must complete this training before accessing production systems containing ePHI.
2. All workforce members are granted access to formal organizational policies, which include the sanction policy for security violations.
3. The Meru Health training clearly states the responsibilities and acceptable behavior regarding information system usage, including rules for email, Internet, mobile devices, and social media usage.
   • By completing the training workforce members agree that they will abide by all terms outlined in the Meru Health training, along with all policies and processes described in this document.
4. Meru Health does not allow mobile devices to connect to any of its production networks.
5. All workforce members are educated about the approved set of tools to be installed on workstations.
6. All new workforce members, including contractors, are given HIPAA training within 30 days of beginning employment. Training includes HIPAA reporting requirements, including the ability to anonymously report security incidents, and the levels of compliance and obligations for Meru Health and its Customers and Partners.
   • Current Meru Health training is hosted at Trainual.
7. All remote (teleworking) workforce members are trained on the risks, the controls implemented, their responsibilities, and sanctions associated with violation of policies. Additionally, remote security is maintained through the use of secure network connections and strong authentication for all access to production systems with access to ePHI data.
8. Any workstations used to access production systems must be configured as prescribed in §7.8.
9. Any workstations used to access production systems must have virus protection software installed, configured, and enabled.
10. Meru Health may monitor access and activities of all users on workstations and production systems in order to meet auditing policy requirements (§8).
11. Access to internal Meru Health systems can be requested using the procedures outlined in §7.2. All requests for access must be granted by the Meru Health Security Officer.
12. Request for modifications of access for any Meru Health employee can be made using the procedures outlined in §7.2.
13. Meru Health employees are disallowed to download any ePHI to their workstations except for accomplishing of specific and limited tasks, such as sending a report to a referring physician.
    • If download of patient data is absolutely necessary, the downloaded data should be deleted from the workstation as soon as possible after finishing with the task.
    • If the task requiring downloading of ePHI cannot be completed immediately, any downloaded data should be deleted without delay.
    • Employees are trained on secure deletion of data from their workstations.
    • Employees are strictly forbidden to retain any ePHI on their workstations for any extended period of time.
    • Employees found to be in violation of this policy will be subject to sanctions as described in §5.3.3.
14. Employees are required to cooperate with federal and state investigations.
    • Employees must not interfere with investigations through willful misrepresentation, omission of facts, or by the use of threats against any person.
    • Employees found to be in violation of this policy will be subject to sanctions as described in §5.3.3.

20.3 Employment Background Checks

All employees will be required to complete a background check to verify the below information

• Identity Verification
• Healthcare Sanctions Search (Clinical only)
• Employment Verification
• Education Verification (Clinical only)
• Professional License Verification (Clinical only)
• Social Security Number Trace
• Nationwide Criminal Databases Search
• Sex Offender Registry Search

21. Approved Tools Policy

Meru Health utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by Meru Health, or they are hosted by a Subcontractor with appropriate business associate agreements in place to preserve data integrity. Use of other tools requires approval from Meru Health leadership.

21.1 List of Approved Tools

• Google Apps. Google Apps is used for email and document collaboration, as well as for storage and sharing of files with Partners and Customers.
• Asana. Asana is used for project management and collaboration. It hosts, for example, Meru Health Quality Management System.
• Slack. Slack is used for day-to-day communications.
• GitHub. GitHub is used for version control of all Meru Health code, configurations and documents.
• Kandji. Kandji is used for mobile device management. We can track company issued devices and push updates.
• Harvest. Harvest is used for time tracking on projects.
• Customer.io. Customer.io is used for email outreach and automated messaging.
• Notion. Notion is used for knowledge management.
• CircleCI. CircleCI is used for CI/CD pipeline for software development.
• Krisp. Krisp is used to keep quality of Zoom calls high
• Loom. Loom is used for video and screen recording.

22. Asset Management Policy

Asset management is the process of receiving, tagging, documenting, and eventually disposing of equipment. It is critically important to maintain up to date inventory and asset controls to ensure computer equipment locations and dispositions are well known. Lost or stolen equipment often contains sensitive data. Proper asset management procedures and protocols provide documentation that aid in recovery, replacement, criminal, and insurance activities.

22.1 Asset Inventory Policy

22.1.1 Policy Statements

1. IT and/or Security must maintain an inventory of all critical company assets, both physical and logical.
2. All assets should have identified owners and a unique identifier
3. All assets will be disposed of according to Meru Health Disposable Media Policy
4. Any asset that is lost or stolen will be immediately reported to the Security Officer

23. 3rd Party Policy

Meru Health makes every effort to assure all 3rd party organizations are compliant and do not compromise the integrity, security, and privacy of Meru Health or Meru Health Customer data. 3rd Parties include Customers, Partners, Subcontractors, and Contracted Developers.

23.1 Applicable Standards

23.1.1 Applicable Standards from the HITRUST Common Security Framework

• 05.i - Identification of Risks Related to External Parties
• 05.k - Addressing Security in Third Party Agreements
• 09.e - Service Delivery
• 09.f - Monitoring and Review of Third Party Services
• 09.g - Managing Changes to Third Party Services
• 10.1 - Outsourced Software Development

23.1.2 Applicable Standards from the HIPAA Security Rule

• 164.314(a)(1)(i) - Business Associate Contracts or Other Arrangements

23.2 Policies to Assure 3rd Parties Support Meru Health Compliance

1. Meru Health does not allow 3rd party access to production systems containing ePHI.
2. All connections and data in transit between the Meru Health Platform and 3rd parties are encrypted end to end.
3. A standard business associate agreement with Customers and Partners is defined and includes the required security controls in accordance with the organization’s security policies. Additionally, responsibility is assigned in these agreements.
4. Meru Health has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management.
   • Subcontractors must coordinate, manage, and communicate any changes to services provided to Meru Health.
   • Changes to 3rd party services are classified as configuration management changes and thus are subject to the policies and procedures described in §9; substantial changes to services provided by 3rd parties will invoke a Risk Assessment as described in §4.2.
   • Meru Health utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs.
5. Meru Health Patients have no access to other than their own data or their group members’ data that they choose to share. Patients cannot access, modify, or delete anything related to other Patients.
6. Meru Health does not outsource software development.
7. Meru Health maintains and annually reviews a list all current Partners and Subcontractors.
   • The list of current Partners and Subcontractors is maintained by the Meru Health Privacy Officer, includes details on all provided services (along with contact information), and is recorded in §1.4.
   • The annual review of Partners and Subcontractors is conducted as a part of the security, compliance, and SLA review referenced below.
8. Meru Health assesses security, compliance, and SLA requirements and considerations with all Partners and Subcontractors.
   • Meru Health leverages recurring calendar invites to assure reviews of all 3rd party services are performed annually. These reviews are performed by the Meru Health Security Officer and Privacy Officer. The process for reviewing 3rd party services is outlined below:
     1. The Security Officer initiates the SLA review by creating an Issue in the Meru Health Quality Management System.
     2. The Security Officer, or Privacy Officer, is assigned to review the SLA and performance of 3rd parties. The list of current 3rd parties, including contact information, is also reviewed to assure it is up to date and complete.
     3. SLA, security, and compliance performance is documented in the Issue.
     4. Once the review is completed and documented, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
9. Regular review is conducted as required by SLAs to assure security and compliance. These reviews include reports, audit trails, security events, operational issues, failures and disruptions, and identified issues are investigated and resolved in a reasonable and timely manner.
10. Any changes to Partner and Subcontractor services and systems are reviewed before implementation.
11. For all partners, Meru Health reviews activity annually to assure partners are in line with SLAs in contracts with Meru Health.
12. SLA review is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.

24. Key Definitions

• Application: An application hosted by Meru Health, either maintained and created by Meru Health, or maintained and created by a Customer or Partner.

• Application Level: Controls and security associated with an Application. In the case of PaaS Customers, Meru Health does not have access to and cannot assure compliance with security standards and policies at the Application Level.

• Audit: Internal process of reviewing information system access and activity (e.g., log-ins, file accesses, and security incidents). An audit may be done as a periodic event, as a result of a patient complaint, or suspicion of employee wrongdoing.

• Audit Controls: Technical mechanisms that track and record computer/system activities.

• Audit Logs: Encrypted records of activity maintained by the system which provide: 1) date and time of activity; 2) origin of activity (app); 3) identification of user doing activity; and 4) data accessed as part of activity.

• Access: Means the ability or the means necessary to read, write, modify, or communicate data/ information or otherwise use any system resource.

• BaaS: Backend-as-a-Service. A set of APIs, and associated SDKs, for rapid mobile and web application development. APIs offer the ability to create users, do authentication, store data, and store files.

• Backup: The process of making an electronic copy of data stored in a computer system. This can either be complete, meaning all data and programs, or incremental, including just the data that changed from the previous backup.

• Backup Service: A logging service for unifying system and application logs, encrypting them, and providing a dashboard for them. Offered with all Meru Health Add-ons and as an option for PaaS Customers.

• Breach: Means the acquisition, access, use, or disclosure of protected health information (PHI) in a manner not permitted under the Privacy Rule which compromises the security or privacy of the PHI. For purpose of this definition, “compromises the security or privacy of the PHI” means poses a significant risk of financial, reputational, or other harm to the individual. A use or disclosure of PHI that does not include the identifiers listed at §164.514(e)(2), limited data set, date of birth, and zip code does not compromise the security or privacy of the PHI. Breach excludes:

1. Any unintentional acquisition, access or use of PHI by a workforce member or person acting under the authority of a Covered Entity (CE) or Business Associate (BA) if such acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure in a manner not permitted under the Privacy Rule.
2. Any inadvertent disclosure by a person who is authorized to access PHI at a CE or BA to another person authorized to access PHI at the same CE or BA, or organized health care arrangement in which the CE participates, and the information received as a result of such disclosure is not further used or disclosed in a manner not permitted under the Privacy Rule.
3. A disclosure of PHI where a CE or BA has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.

• Business Associate: A person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.

• Covered Entity: A health plan, health care clearinghouse, or a healthcare provider who transmits any health information in electronic form.

• De-identification: The process of removing identifiable information so that data is rendered to not be PHI.

• Disaster Recovery: The ability to recover a system and data after being made unavailable.

• Disaster Recovery Service: A disaster recovery service for disaster recovery in the case of system unavailability. This includes both the technical and the non-technical (process) required to effectively stand up an application after an outage. Offered with all Meru Health Add-ons and as an option for PaaS Customers.

• Disclosure: Disclosure means the release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information.

• Customers: Contractually bound users of Meru Health Platform.

• Electronic Protected Health Information (ePHI): Any individually identifiable health information protected by HIPAA that is transmitted by, processed in some way, or stored in electronic media.

• Environment: The overall technical environment, including all servers, network devices, and applications.

• Event: An event is defined as an occurrence that does not constitute a serious adverse effect on Meru Health, its operations, or its Customers, though it may be less than optimal. Examples of events include, but are not limited to:

  • A hard drive malfunction that requires replacement;
  • Systems become unavailable due to power outage that is non-hostile in nature, with redundancy to assure ongoing availability of data;
  • Accidental lockout of an account due to incorrectly entering a password multiple times.

• Hardware (or hard drive): Any computing device able to create and store ePHI.

• Health and Human Services (HHS): The government body that maintains HIPAA.

• Individually Identifiable Health Information: That information that is a subset of health information, including demographic information collected from an individual, and is created or received by a health care provider, health plan, employer, or health care clearinghouse; and relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and identifies the individual; or with respect to which there is a reasonable basis to believe the information can be used to identify the individual.

• Indication: A sign that an Incident may have occurred or may be occurring at the present time. Examples of indications include:

  • The network intrusion detection sensor alerts when a known exploit occurs against an FTP server. Intrusion detection is generally reactive, looking only for footprints of known attacks. It is important to note that many IDS “hits” are also false positives and are neither an event nor an incident;
  • The antivirus software alerts when it detects that a host is infected with a worm;
  • Users complain of slow access to hosts on the Internet;
  • The system administrator sees a filename with unusual characteristics;
  • Automated alerts of activity from log monitors like OSSEC;
  • An alert from OSSEC about file system integrity issues.

• Intrusion Detection System (IDS): A software tool use to automatically detect and notify in the event of possible unauthorized network and/or system access.

• IDS Service: An Intrusion Detection Service for providing IDS notification to customers in the case of suspicious activity. Offered with all Meru Health Add-ons and as an option for PaaS Customers.

• Law Enforcement Official: Any officer or employee of an agency or authority of the United States, a State, a territory, a political subdivision of a State or territory, or an Indian tribe, who is empowered by law to investigate or conduct an official inquiry into a potential violation of law; or prosecute or otherwise conduct a criminal, civil, or administrative proceeding arising from an alleged violation of law.

• Logging Service: A logging service for unifying system and application logs, encrypting them, and providing a dashboard for them. Offered with all Meru Health Add-ons and as an option for PaaS Customers.

• Messaging: API-based services to deliver and receive SMS messages.

• Minimum Necessary Information: Protected health information that is the minimum necessary to accomplish the intended purpose of the use, disclosure, or request. The “minimum necessary” standard applies to all protected health information in any form.

• Off-Site: For the purpose of storage of Backup media, off-site is defined as any location separate from the building in which the backup was created. It must be physically separate from the creating site.

• Organization: For the purposes of this policy, the term “organization” shall mean Meru Health.

• Partner: Contractual bound 3rd party vendor with integration with the Meru Health Platform. May offer Add-on services.

• Platform: The overall technical environment of Meru Health.

• Protected Health Information (PHI): Individually identifiable health information that is created by or received by the organization, including demographic information, that identifies an individual, or provides a reasonable basis to believe the information can be used to identify an individual, and relates to:

  • Past, present or future physical or mental health or condition of an individual.
  • The provision of health care to an individual.
  • The past, present, or future payment for the provision of health care to an individual.

• Role: The category or class of person or persons doing a type of job, defined by a set of similar or identical responsibilities.

• Sanitization: Removal or the act of overwriting data to a point of preventing the recovery of the data on the device or media that is being sanitized. Sanitization is typically done before re-issuing a device or media, donating equipment that contained sensitive information or returning leased equipment to the lending company.

• Trigger Event: Activities that may be indicative of a security breach that require further investigation (See Appendix).

• Restricted Area: Those areas of the building(s) where protected health information and/or sensitive organizational information is stored, utilized, or accessible at any time.

• Role: The category or class of person or persons doing a type of job, defined by a set of similar or identical responsibilities.

• Precursor: A sign that an Incident may occur in the future. Examples of precursors include:

  • Suspicious network and host-based IDS events/attacks;
  • Alerts as a result of detecting malicious code at the network and host levels;
  • Alerts from file integrity checking software;
  • Audit log alerts.

• Risk: The likelihood that a threat will exploit a vulnerability, and the impact of that event on the confidentiality, availability, and integrity of ePHI, other confidential or proprietary electronic information, and other system assets.

• Risk Management Team: Individuals who are knowledgeable about the Organization’s HIPAA Privacy, Security and HITECH policies, procedures, training program, computer system set up, and technical security controls, and who are responsible for the risk management process and procedures outlined below.

• Risk Assessment: (Referred to as Risk Analysis in the HIPAA Security Rule); the process:

  • Identifies the risks to information system security and determines the probability of occurrence and the resulting impact for each threat/vulnerability pair identified given the security controls in place;
  • Prioritizes risks; and
  • Results in recommended possible actions/controls that could reduce or offset the determined risk.

• Risk Management: Within this policy, it refers to two major process components: risk assessment and risk mitigation. This differs from the HIPAA Security Rule, which defines it as a risk mitigation process only. The definition used in this policy is consistent with the one used in documents published by the National Institute of Standards and Technology (NIST).

• Risk Mitigation: Referred to as Risk Management in the HIPAA Security Rule, and is a process that prioritizes, evaluates, and implements security controls that will reduce or offset the risks determined in the risk assessment process to satisfactory levels within an organization given its mission and available resources.

• Security Incident (or just Incident): A security incident is an occurrence that exercises a significant adverse effect on people, process, technology, or data. Security incidents include, but are not limited to:

  • A system or network breach accomplished by an internal or external entity; this breach can be inadvertent or malicious;
  • Unauthorized disclosure;
  • Unauthorized change or destruction of ePHI (i.e. delete dictation, data alterations not following Meru Health’s procedures);
  • Denial of service not attributable to identifiable physical, environmental, human or technology causes;
  • Disaster or enacted threat to business continuity;
  • Information Security Incident: A violation or imminent threat of violation of information security policies, acceptable use policies, or standard security practices. Examples of information security incidents may include, but are not limited to, the following:
  • Denial of Service: An attack that prevents or impairs the authorized use of networks, systems, or applications by exhausting resources;
  • Malicious Code: A virus, worm, Trojan horse, or other code-based malicious entity that infects a host;
  • Unauthorized Access/System Hijacking: A person gains logical or physical access without permission to a network, system, application, data, or other resource. Hijacking occurs when an attacker takes control of network devices or workstations;
  • Inappropriate Usage: A person violates acceptable computing use policies;
  • Other examples of observable information security incidents may include, but are not limited to:
  • Use of another person’s individual password and/or account to login to a system;
  • Failure to protect passwords and/or access codes (e.g., posting passwords on equipment);
  • Installation of unauthorized software;
  • Terminated workforce member accessing applications, systems, or network.

• Threat: The potential for a particular threat-source to successfully exercise a particular vulnerability. Threats are commonly categorized as:

  • Environmental - external fires, HVAC failure/temperature inadequacy, water pipe burst, power failure/fluctuation, etc.
  • Human - hackers, data entry, workforce/ex-workforce members, impersonation, insertion of malicious code, theft, viruses, SPAM, vandalism, etc.
  • Natural - fires, floods, electrical storms, tornados, etc.
  • Technological - server failure, software failure, ancillary equipment failure, etc. and environmental threats, such as power outages, hazardous material spills.
  • Other - explosions, medical emergencies, misuse or resources, etc.

• Threat Source: Any circumstance or event with the potential to cause harm (intentional or unintentional) to an IT system. Common threat sources can be natural, human or environmental which can impact the organization’s ability to protect ePHI.

• Threat Action: The method by which an attack might be carried out (e.g., hacking, system intrusion, etc.).

• Unrestricted Area: Those areas of the building(s) where protected health information and/or sensitive organizational information is not stored or is not utilized or is not accessible there on a regular basis.

• Unsecured Protected Health Information: Protected health information (PHI) that is not rendered unusable, unreadable, or indecipherable to unauthorized individuals through the use of technology or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Pub. L.111-5 on the HHS website.

  1. Electronic PHI has been encrypted as specified in the HIPAA Security rule by the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without the use of a confidential process or key and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt. The following encryption processes meet this standard.
  2. Valid encryption processes for data at rest (i.e. data that resides in databases, file systems and other structured storage systems) are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.
  3. Valid encryption processes for data in motion (i.e. data that is moving through a network, including wireless transmission) are those that comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPSec VPNs; or 800-113, Guide to SSL VPNs, and may include others which are Federal Information Processing Standards FIPS 140-2 validated.
  4. The media on which the PHI is stored or recorded has been destroyed in the following ways:
  5. Paper, film, or other hard copy media have been shredded or destroyed such that the PHI cannot be read or otherwise cannot be reconstructed. Redaction is specifically excluded as a means of data destruction.
  6. Electronic media have been cleared, purged, or destroyed consistent with NIST Special Publications 800-88, Guidelines for Media Sanitization, such that the PHI cannot be retrieved.

• Vendors: Persons from other organizations marketing or selling products or services, or providing services to Meru Health.

• Vulnerability: A weakness or flaw in an information system that can be accidentally triggered or intentionally exploited by a threat and lead to a compromise in the integrity of that system, i.e., resulting in a security breach or violation of policy.

• Workstation: An electronic computing device, such as a laptop or desktop computer, or any other device that performs similar functions, used to create, receive, maintain, or transmit ePHI. Workstation devices may include, but are not limited to: laptop or desktop computers, personal digital assistants (PDAs), tablet PCs, and other handheld devices. For the purposes of this policy, “workstation” also includes the combination of hardware, operating system, application software, and network connection.

• Workforce: Means employees, volunteers, trainees, and other persons whose conduct, in the performance of work for a covered entity, is under the direct control of such entity, whether or not they are paid by the covered entity.

25. Meru Health HIPAA Business Associate Agreement (“BAA”)

This Business Associate Addendum is entered into by and between Meru Health Inc. (“Meru Health”) and _____________________________________________ (“Business Associate”) (each “Party”, collectively “Parties”).

The Parties have a prior written agreement, dated ___________________, (“the Primary Agreement”) under which the Business Associate regularly receives, uses and/or discloses Protected Health Information in its performance of the services described in the Primary Agreement. This Addendum sets forth the obligations and agreements of the Parties relating to compliance with the Standards for Privacy of Individually Identifiable Health Information (“the Privacy Regulation”), 45 C.F.R. Parts 160 and 164, and the Security Regulations (45 C.F.R. Parts 160, 162, and 164), promulgated under the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”), the Health Information Technology for Economic and Clinical Health (“HITECH”), and the California statutes governing social security numbers, I.C. 4-1-10-1 et. seq. This Addendum applies to all Protected Health Information created or received by Business Associate from Meru Health or from another person or entity on behalf of Meru Health, and governs how such Protected Health Information may be used or disclosed.

The Parties hereby agree as follows:

1. PERMITTED USES AND DISCLOSURES OF PROTECTED HEALTH INFORMATION

1.1 Business Associate shall be permitted to use and/or disclose Protected Health Information created or received on behalf of Meru Health for all purposes necessary to provide the services and to perform its obligations under the Primary Agreement, provided that said use and/or disclosure complies with the requirements of HIPAA. Business Associate acknowledges that under the requirements of HITECH, the HIPAA Privacy and Security Regulations apply to business associates and the additional privacy requirements set forth in HITECH apply to Business Associate to the same extent that they apply to covered entities under HIPAA. The requirements of the HITECH statutes are incorporated herein by reference. In accordance with the applicable requirements of HITECH, any uses or disclosures of PHI must be limited, to the extent practicable, to the Limited Data Set, or, if needed to accomplish the purposes of this Addendum, to the minimum necessary to accomplish the intended purpose of such use or disclosure.

1.2 Subject to paragraph 1.1, Business Associate may use Protected Health Information created or received by Business Associate from or on behalf of Meru Health, if necessary, for the proper management and administration of the Business Associate and to fulfill any current or future legal responsibilities of the Business Associate.

1.3 Subject to paragraph 1.1, Business Associate may disclose Protected Health Information created or received by Business Associate on behalf of Meru Health, if necessary, for the proper management and administration of the Business Associate and to fulfill any current or future legal responsibilities of the Business Associate, provided:

1.3.1 The disclosure is Required by Law, or

1.3.2 Business Associate obtains satisfactory assurances from the person or entity to whom the Protected Health Information is disclosed that (i) the Protected Health Information will be held confidentially and used or further disclosed only as Required by Law or for the purpose for which it was disclosed to the person or entity; and (ii) the Business Associate will be notified of any instances of which the person is aware in which the confidentiality of the information is breached.

1.3.3 As of the effective date of the applicable HITECH regulations, Business Associate shall not directly or indirectly receive remuneration in exchange for any Protected Health Information of an individual unless Business Associate has obtained from the individual a valid authorization that includes specification of whether the Protected Health Information can be further exchanged for remuneration by the Business Associate.

2. RESPONSIBILITIES OF BUSINESS ASSOCIATE WITH RESPECT TO

PROTECTED HEALTH INFORMATION

2.1 Business Associate agrees not to use or disclose Protected Health

Information except as expressly permitted by this Addendum, HIPAA, or as Required by Law.

2.2 Business Associate hereby agrees to maintain the security and privacy of all Protected Health Information in a manner consistent with California and Federal laws and regulations, including but not limited to the HIPAA Privacy Regulations and the Security Regulations (45 C.F.R. Parts 160, 162, and 164) and HITECH, and I.C. 4-1-10-1 et. seq., and Business Associate further agrees to use appropriate safeguards and security procedures to prevent use or disclosure of Protected Health Information not permitted by this Addendum.

2.3 Business Associate shall not disclose Protected Health Information to any member of its workforce unless such member of its workforce has a need to use such Protected Health Information, and Business Associate has advised such person of Business Associate’s privacy and security obligations under this Addendum, including the consequences for violation of such obligations. Business Associate shall take appropriate disciplinary action against any member of its workforce who uses or discloses Protected Health Information in violation of this Addendum or applicable law.

2.4 Business Associate shall require all of its subcontractors and agents that receive or use, or have access to, Protected Health Information under this Addendum to agree, in writing, to adhere to the same restrictions and conditions on the use or disclosure of Protected Health Information that apply to the Business Associate pursuant to this Addendum.

2.5. Business Associate agrees to maintain a record of all disclosures of Protected Health Information, including disclosures not made for the purposes of this Addendum, and further agrees within ten (10) days of a written request from Meru Health, to provide to Meru Health such information as is necessary to permit Meru Health to respond to a request by an individual for an accounting of the disclosures of the individual’s Protected Health Information in accordance with 45 C.F.R. § 164.528. Business Associate further agrees to comply with the requirements of HITECH to provide Meru Health with an accounting of all disclosures made for treatment, payment and health care operations when the HITECH statute requiring such an accounting becomes applicable to Meru Health. Meru Health agrees to notify Business Associate in advance of the applicability of this requirement.

2.6. Business Associate agrees to report to Meru Health any unauthorized use or disclosure of Protected Health Information by Business Associate or its workforce, agents or subcontractors and the remedial action taken or proposed to be taken with respect to such use or disclosure in accordance with the specific provisions of Section 2.11.

2.7 Business Associate agrees to make its internal practices, books, and records relating to the use and disclosure of Protected Health Information received from Meru Health, or created or received by Business Associate on behalf of Meru Health, available to the Secretary of the United States Department of Health and Human Services, for purposes of determining Meru Health’s compliance with HIPAA.

2.8. Within thirty (30) days of a written request, Business Associate shall allow a person who is the subject of Protected Health Information, such person’s legal representative, or Meru Health to have access to and to copy such person’s Protected Health Information maintained by Business Associate. Business Associate shall provide Protected Health Information in the format requested by such person, legal representative, or practitioner unless it is not readily producible in such format, in which case it shall be produced in standard hard copy format. Business Associate acknowledges that HITECH requires Meru Health and Business Associate to provide electronic health records to the individual in electronic format, and Business Associate agrees that to the extent applicable, Business Associate will produce any Protected Health Information in electronic format in a manner requested by Meru Health or by the individual who has made the request.

2.9 Within ten (10) days of a written request by Meru Health, Business Associate shall make available to Meru Health Protected Health Information received from or on behalf of Meru Health for amendment in accordance with 45 C.F.R. § 164.526. Business Associate further agrees to make such amendment to Protected Health Information as directed by Meru Health within thirty (30) days of a written request by Meru Health.

2.10 Business Associate shall implement and document appropriate administrative, physical and technical safeguards in order to preserve the confidentiality, integrity and availability of all Protected Health Information and to prevent any unauthorized use or disclosure of Protected Health Information, or any breach or security incident, or other material breach or violation of an underlying contract, this Addendum, HIPAA and HITECH involving said Protected Health Information. Business Associate shall further:

2.10.1 Establish administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity and availability of any electronic Protected Health Information that it creates, receives, maintains, or transmits on behalf of the covered entity as required by § 164.314 of the Security Regulations. Business Associate represents and warrants that its security program is periodically reviewed and appropriate updates are implemented to address any gaps identified in its security program. Business Associate agrees to make its security policies and procedures available to Meru Health upon reasonable request.

2.10.2 Require all of its subcontractors and agents that receive, use or have access to Protected Health Information to implement reasonable and appropriate security safeguards to protect it from unauthorized use or disclosure, and to report any improper use or disclosure of Protected Health Information in the time and manner required of Business Associate herein.

2.10.3 Immediately report to Meru Health any unauthorized or improper use or disclosure of Protected Health Information, including without limitation, any security or privacy incident or breach involving the Protected Health Information (“Incident”) without unreasonable delay, and not more than twenty-four (24) hours after Business Associate becomes aware of the Incident by Business Associate or its workforce, agents or subcontractors, and to provide Meru Health with notice and a report containing all information necessary to permit Meru Health to timely comply with HIPAA notification provisions and its implementing rules or any other applicable reporting law, if necessary. Said report shall identify: (i) the known facts and circumstances related to the Incident; (ii) the individuals affected;

(iii) the Protected Health Information that is known to be the subject of the Incident; (iv) the persons who are known to have information about the Incident; and (v) the corrective action that Business Associate took or will take to mitigate any deleterious effects of the Incident and to prevent future incidents. Business Associate further acknowledges that it is familiar with the requirements of I.C. 4-1-11 concerning breaches of security and notification of disclosures of social security numbers. To the extent Business Associate must make its own notification involving any disclosure of Protected Health Information, Business Associate agrees to cooperate with Meru Health regarding the notification process prior to making such notification.

2.10.4 Implement reasonable policies and procedures designed to detect and provide appropriate response to relevant “Red Flags” that identity theft may be occurring (as defined in 16 CFR 681.2) or that may arise in the performance of Business Associate’s activities, if Business Associate has access to information protected under the Red Flag Rules. Business Associate agrees that policies and procedures to detect relevant “Red Flags” are updated periodically. Business Associate further agrees to notify Meru Health of the detection of a Red Flag and to implement reasonable steps to prevent or mitigate identity theft.

3. TERM AND TERMINATION

3.1 This Addendum shall commence as of the date first signed below, and the obligations set forth in this Addendum shall continue in effect as long as Business Associate uses, discloses, creates, receives or otherwise possesses any Protected Health Information created or received from or on behalf of Meru Health and until all such Protected Health Information is destroyed or returned to Meru Health pursuant to the terms of this Addendum.

3.2 Meru Health may immediately terminate this Addendum and the Primary Agreement if Meru Health determines that the Business Associate has breached a material term of this Addendum. Alternatively, Meru Health may choose to: (i) provide Business Associate an opportunity to cure said alleged material breach to the satisfaction of Meru Health within ten (10) days. The Business Associate’s failure to cure shall be grounds for immediate termination of this Addendum. Meru Health’s remedies under this Addendum are cumulative, and the exercise of any remedy shall not preclude the exercise of any other.

3.3. Upon termination of this Addendum, Business Associate shall return or destroy, by rendering the Protected Health Information unusable, unreadable or undecipherable or beyond the ability to recover, all Protected Health Information received from Meru Health, or created or received by Business Associate on behalf of Meru Health and that Business Associate maintains in any form, and Business Associate shall retain no copies of such information. If the parties mutually agree that return or destruction of Protected Health Information is not feasible, Business Associate shall continue to maintain the security and privacy of such Protected Health Information in a manner consistent with the obligations of this Addendum and as required by applicable law, and shall limit further use of the information to those purposes that make the return or destruction of the information infeasible. The duties hereunder to maintain the security and privacy of Protected Health Information shall survive the termination of this Addendum.

4. AMENDMENT TO ADDENDUM

Meru Health may amend this Addendum by providing ten (10) days prior written notice to Business Associate in order to maintain compliance with California or Federal laws or regulations. Such amendment shall be binding upon Business Associate at the end of the ten (10) day period and shall not require the consent of Business Associate. Business Associate may elect to terminate the Addendum within the ten (10) day period, but Business Associate’s obligations to maintain the security and privacy of Protected Health Information as required herein shall survive such termination. Meru Health and Business Associate may otherwise amend this Addendum by mutual written agreement.

5. INDEMNITY

Business Associate shall, to the fullest extent permitted by law, protect, defend, indemnify and hold harmless Meru Health and its respective employees, directors, and agents (“Indemnitees”) from and against any and all losses, costs, claims, penalties, fines, demands, liabilities, legal actions, judgments, and expenses of every kind (including reasonable attorneys fees, including at trial and on appeal) asserted or imposed against any Indemnitees arising out of the acts or omissions of Business Associate or any subcontractor of or Provider of Business Associate or any of Business Associate’s employees, directors, or agents related to the performance or nonperformance of this Addendum.

6. NO THIRD PARTY BENEFICIARIES

Nothing express or implied in this Addendum is intended to confer, nor shall anything herein confer, upon any person other than the Parties and the respective successors or permitted assigns of the Parties, any rights, remedies, obligations, or liabilities whatsoever.

7. LIMITATION OF LIABILITY

NEITHER PARTY SHALL BE LIABLE TO THE OTHER PARTY FOR ANY INCIDENTAL, CONSEQUENTIAL, SPECIAL, OR PUNITIVE DAMAGES OF ANY KIND OR NATURE, WHETHER SUCH LIABILITY IS ASSERTED ON THE BASIS OF CONTRACT, TORT (INCLUDING NEGLIGENCE OR STRICT LIABILITY), OR OTHERWISE, EVEN IF THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGES. ANY DAMAGES AMOUNT AWARDED TO BUSINESS ASSOCIATE UNDER THIS AGREEMENT SHALL BE LIMITED TO ACTUAL AMOUNTS RECEIVED BY MERU HEALTH IN THE LAST 90 DAYS FROM BUSINESS ASSOCIATE.

8. DEFINITIONS

8.1 Limited Data Set. “Limited Data Set” shall have the meaning set out in

45 C.F.R. § 164.514(e)(2), as amended from time to time.

8.2 Protected Health Information. “Protected Health Information” shall have the meaning set out in 45 C.F.R. §160.103, as amended or revised from time to time. The term shall also include any social security numbers provided or made available to Business Associate.

8.3 Required by Law. “Required by Law” shall have the meaning set forth in

45 C.F.R. §164.103, as amended or revised from time to time.

SIGNATURE FOLLOWS

26. HIPAA Mappings to Meru Health Controls

Below is a list of HIPAA Safeguards and Requirements and the Meru Health controls in place to meet those.