HealthTensor Compliance

> Policy Docs


HealthTensor, Inc (“HealthTensor”) 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 Service and Customers. HealthTensor strives to maintain compliance, proactively address information security, mitigate risk, and assure known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by HealthTensor to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for HealthTensor Customers.

HealthTensor provides secure and compliant Software as a Service (SaaS).

Software as a Service (SaaS)

SaaS Customers utilize hosted software and infrastructure from HealthTensor to structure ePHI owned by HealthTensor or SaaS Customers. HealthTensor makes every effort to reduce the risk of unauthorized disclosure, access, and/or breach of SaaS Customer data through network (firewalls, dedicated IP spaces, etc) and server settings (encryption at rest and in transit).

HealthTensor Organizational Concepts

The physical infrastructure environment is hosted by Amazon Web Services (AWS). GitLab hosts unrestricted configuration files and scripts, while AWS stores backups. The network components and supporting network infrastructure are contained within AWS and managed by Amazon. The HealthTensor environment consists of software firewalls, nginx web servers, PostgreSQL database servers, Linux Ubuntu monitoring servers, configuration management scripts, OSSEC IDS services, Docker containers, and developer tools servers running on Linux Ubuntu and FreeBSD.

Within the HealthTensor Software infrastructure all data transmission is encrypted and all filesystems with ePHI are encrypted so data at rest is also encrypted. Servers which do not host ePHI are not necessarily encrypted.

In the case of SaaS Customers, it is the responsibility of the Customer to restrict, secure, and assure the privacy of all ePHI data at the Application Level, as this is not under the control or purview of HealthTensor.

Our data and network segmentation is provided by hardware and software firewalls which limit access to critical services. FreeBSD’s pf and AWS security groups are configured to restrict access to only justified ports and protocols. HealthTensor has implemented strict logical access controls so that only authorized personnel are given access to ePHI.

The router is externally facing and accessible via the Internet. The database servers, where the ePHI resides, are located on the internal HealthTensor network and can only be accessed directly over an SSH connection. The access to the internal database is restricted to a limited number of personnel and strictly controlled to only those personnel with a business justified reason. Remote access to the internal servers is not accessible except through the internal router.

Version Control

Policies were last updated March 6th, 2017.

Policy Management Policy

HealthTensor 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 HealthTensor 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.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Maintenance of Policies

  1. All policies are stored and up to date to maintain HealthTensor compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control is done similar to 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 accurate and up-to-date.
  3. Edits and updates made by appropriate and authorized workforce members are done on their own versions, or branches. These changes are only merged back into final, or master, versions by the Privacy or Security Officer, similarly to a pull request. All changes are linked to workforce personnel who made them and the Officer who accepted them.
  4. All policies are made accessible to all HealthTensor workforce members. The current master policies are published here.
    • Changes can be requested to policies via GitLab.
    • Once the change has been approved to a HealthTensor Policy we implement the policy change using Ansible. The process for that is spelled out in the HealthTensor Configuration Management Policy.
    • Changes are automatically communicated to all HealthTensor team members through integrations between GitLab and Slack that log all GitLab policy channels to a dedicated HealthTensor Slack Channel.
  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 HealthTensor policies is done via GitLab.
    2. Backup storage of all policies is done with Box.
  6. The policies and information security policies are reviewed and audited annually. Issues that come up as part of this process are reviewed by HealthTensor management to assure all risks and potential gaps are mitigated and/or fully addressed. The policy review form can be found here.
  7. HealthTensor utilizes the HITRUST MyCSF framework to track compliance with the HITRUST CSF on an annual basis. HealthTensor also tracks compliance with HIPAA and publishes results here.

Additional documentation related to maintenance of policies is outlined in the Security officers responsibilities.

Risk Management Policy

This policy establishes the scope, objectives, and procedures of HealthTensor’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.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Risk Management Policies

  1. It is the policy of HealthTensor 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 HealthTensor’s information security program.
  2. Risk analysis and risk management are recognized as important components of HealthTensor’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:
    2. Before the integration of new system technologies and before changes are made to HealthTensor 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 HealthTensor Platform.
    3. While making changes to HealthTensor physical equipment and facilities that introduce new, untested configurations.
    4. HealthTensor 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. HealthTensor 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 HealthTensor 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 HealthTensor’s Security Officer.
  5. All HealthTensor 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 HealthTensor Roles Policy.
  6. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of HealthTensor’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.

Risk Management Procedures

Risk Assessment: The intent of completing a risk assessment is to determine potential threats and vulnerabilities and the likelihood and impact should they occur. The output of this process helps to identify appropriate controls for reducing or eliminating risk.

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 HealthTensor Platform ePHI. Determination of appropriate controls to reduce risk is dependent upon the risk tolerance of the organization consistent with its goals and mission.

Risk Management Schedule: The two principle components of the risk management process - risk assessment and risk mitigation - will be carried out according to the following schedule to ensure the continued adequacy and continuous improvement of HealthTensor’s information security program:

Process Documentation

Maintain documentation of all risk assessment, risk management, and risk mitigation efforts for a minimum of six years.

Roles Policy

HealthTensor 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.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Privacy Officer

The Privacy Officer is responsible for assisting with compliance and security training for workforce members, assuring 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 HealthTensor Privacy Officer is Thomas Moulia (

Workforce Training Responsibilities

  1. The Privacy Officer facilitates the training of all workforce members as follows:

    1. New workforce members within their first month 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 HealthTensor.
  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 HealthTensor ‘s security policies and procedures:

    1. HIPAA Privacy, Security, and Breach notification rules;
    2. HITRUST Common Security Framework;
    3. NIST Security Rules;
    4. Risk Management procedures and documentation;
    5. Auditing. HealthTensor may monitor access and activities of all users;
    6. Workstations may only be used to perform assigned job responsibilities;
    7. Users may not download software onto HealthTensor’s workstations and/or systems without prior approval from the Security Officer;
    8. Users are required to report malicious software to the Security Officer immediately;
    9. Users are required to report unauthorized attempts, uses of, and theft of HealthTensor’s systems and/or workstations;
    10. Users are required to report unauthorized access to facilities
    11. 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;
    12. Users may not alter ePHI maintained in a database, unless authorized to do so by a HealthTensor Customer;
    13. Users are required to understand their role in HealthTensor’s contingency plan;
    14. Users may not share their user names nor passwords with anyone;
    15. Requirements for users to create and change passwords;
    16. Users must set all applications that contain or transmit ePHI to automatically log off after 10 minutes of inactivity;
    17. Supervisors are required to report terminations of workforce members and other outside users;
    18. Supervisors are required to report a change in a users title, role, department, and/or location;
    19. Procedures to backup ePHI;
    20. Procedures to move and record movement of hardware and electronic media containing ePHI;
    21. Procedures to dispose of discs, CDs, hard drives, and other media containing ePHI;
    22. Procedures to re-use electronic media containing ePHI;
    23. SSH key and sensitive document encryption procedures.

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 HealthTensor security policies and non-compliance with the security regulations [164.308(a)(1)(ii)©], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)].

The current HealthTensor Security Officer is Thomas Moulia (

Organizational Responsibilities

The Security Officer, in collaboration with the Privacy Officer, is responsible for facilitating the development, implementation, and oversight of all activities pertaining to HealthTensor’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. 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 established 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. 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 HealthTensor 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.

    1. Promptly, properly, and consistently investigates and addresses reported violations and takes steps to prevent recurrence.
    2. Applies consistent and appropriate sanctions against workforce members who fail to comply with the security policies and procedures of HealthTensor.
    3. Mitigates, to the extent practicable, any harmful effect known to HealthTensor of a use or disclosure of ePHI in violation of HealthTensor’s policies and procedures, even if effect is the result of actions of HealthTensor 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 HealthTensor 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:

    1. Latest malicious software or virus alerts;
    2. HealthTensor’s requirement to report unauthorized attempts to access ePHI;
    3. Changes in creating or changing passwords;
    4. Additional security-focused training is provided to all workforce members by the Security Officer. This training includes, but is not limited to:
    5. Data backup plans;
    6. System auditing procedures;
    7. Redundancy procedures;
    8. Contingency plans;
    9. Virus protection;
    10. Patch management;
    11. Media Disposal and/or Re-use;
    12. Documentation requirements.

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 HealthTensor’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 HealthTensor’s security policies and procedures.

Sanctions of Workforce Responsibilities

All workforce members report non-compliance of HealthTensor’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 HealthTensor’s security policies and procedures. The Security Officer may request the assistance from others.

    1. Complete an audit trail/log to identify and verify the violation and sequence of events.
    2. Interview any individual that may be aware of or involved in the incident.
    3. All individuals are required to cooperate with the investigation process and provide factual information to those conducting the investigation.
    4. Provide individuals suspected of non-compliance of the Security rule and/or HealthTensor’s policies and procedures the opportunity to explain their actions.
    5. The investigators thoroughly documents the investigation as the investigation occurs.
  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.

    1. A violation resulting in a breach of confidentiality (i.e. release of PHI to an unauthorized individual), change of the integrity of any ePHI, or inability to access any ePHI by other users, requires immediate termination of the workforce member from HealthTensor.
  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 setup a team to investigate and mitigate the risk of insider malicious activity. HealthTensor 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.

Data Management Policy

HealthTensor has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI) stored in conjunction with HealthTensor Add-ons and for SaaS Customers utilizing our Backup Service. This policy, and associated procedures for testing and restoring from backup data, do not apply to SaaS Customers that do not choose HealthTensor Backup Service. The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by HealthTensor.

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

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

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Backup Policy and Procedures

  1. Perform daily snapshot backups of all systems that process, store, or transmit ePHI for HealthTensor Customers, including SaaS Customers that utilize the HealthTensor Backup Service
  2. HealthTensor Engineering, lead by the CTO, is designated to be in charge of backups.
  3. Engineering Team members are trained and assigned 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.

System Access Policy

Access to HealthTensor systems and application is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, consultants, and 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:

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Access Establishment and Modification

Workforce Clearance Procedures

Access Authorization

Person or Entity Authentication

Unique User Identification

Automatic Logoff

Employee Workstation Use

Wireless Access Use

Employee Termination Procedures

Paper Records

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

Password Management

Auditing Policy

HealthTensor 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. HealthTensor 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 HealthTensor to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, HealthTensor shall audit access and activity to detect, report, and guard against:

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Auditing Policies

  1. Responsibility for auditing information system access and activity is assigned to HealthTensor’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 HealthTensor are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
  2. HealthTensor’s auditing processes shall address access and activity at the following levels listed below. In the case of Customers, Application and User level auditing is the responsibility of the Customer. 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 generally monitor and log all commands directly initiated by the user, all identification and authentication attempts, and data and services accessed.
    • Application: Application level audit trails generally monitor and log all user activities, including data accessed and modified and specific actions.
    • System: System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions. HealthTensor utilizes file system monitoring from OSSEC to assure the integrity of file system data.
    • Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
  3. HealthTensor shall log all incoming and outgoing traffic to into and out of its environment. This includes all successful and failed attempts at data access and editing. Data associated with this data will include origin, destination, time, and other relevant details that are available to HealthTensor.
  4. HealthTensor utilizes OSSEC to scan all systems for malicious and unauthorized software every day.
  5. HealthTensor leverages process monitoring tools throughout its environment.
  6. HealthTensor uses OSSEC to monitor the integrity of log files by utilizing OSSEC System Integrity Checking capabilities.
  7. HealthTensor shall identify “trigger events” or criteria that raise awareness of questionable conditions of viewing of confidential information. The “events” may be applied to the entire HealthTensor Platform or may be specific to a Customer, partner, or business associate.
  8. In addition to trigger events, HealthTensor utilizes OSSEC log correlation functionality to proactively identify and enable alerts based on log data.
  9. Logs are reviewed biweekly by Security Officer.
  10. HealthTensor’s Security Officer and Privacy Officer are authorized to select and use auditing tools that are designed to detect network vulnerabilities and intrusions. Such tools are explicitly prohibited by others, including Customers and Partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to:
    • Scanning tools and devices;
    • Password cracking utilities;
    • Network “sniffers.”
    • Passive and active intrusion detection systems.
  11. 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 HealthTensor 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.
  12. Vulnerability testing software may be used to probe the network to identify what is running (e.g., operating system or product versions in place), whether publicly-known vulnerabilities have been corrected, and evaluate whether the system can withstand attacks aimed at circumventing security controls.
    • Testing may be carried out internally or provided through an external third-party vendor. Whenever possible, a third party auditing vendor should not be providing the organization IT oversight services (e.g., vendors providing IT services should not be auditing their own services - separation of duties).
    • Testing shall be done on a routine basis, currently monthly.
  13. Software patches and updates will be applied to all systems in a timely manner. In the case of routine updates, they will be applied after thorough testing. In the case of updates to correct known vulnerabilities, priority will be given to testing to speed the time to production. Critical security patches are applied within 30 days from testing and all security patches are applied within 90 days after testing.

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, 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 HealthTensor’s Privacy or Security Officer.
  3. A request for an audit must be approved by HealthTensor’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 HealthTensor’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 HealthTensor’s Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that HealthTensor consider seeking risk management and/or legal counsel.

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.
  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. HealthTensor’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 HealthTensor’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.

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 HealthTensor and the 3rd party. HealthTensor 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, HealthTensor’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, HealthTensor must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.

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 encrypted in transit and 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. This is done to apply the security principle of “separation of duties” to protect audit trails from hackers.
  4. For SaaS Customers choosing to use HealthTensor logging services, log data will be separated from the log data of other HealthTensor Customers.

Workforce Training, Education, Awareness and Responsibilities

  1. HealthTensor workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI. HealthTensor’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. HealthTensor 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.
  2. HealthTensor Customers are provided with necessary information to understand HealthTensor auditing capabilities, and SaaS Customers can choose the level of logging and auditing that HealthTensor will implement on their behalf.

External Audits of Information Access and Activity

  1. Prior to contracting with an external audit firm, HealthTensor 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.

Retention of Audit Data

  1. Audit logs shall be maintained based on organizational needs. There is no standard or law addressing the retention of audit log/trail information. Retention of this information shall be based on: A. Organizational history and experience. B. Available storage space.
  2. Reports summarizing audit activities shall be retained for a period of six years.
  3. Log data is currently retained and readily accessible for a 1-month period. Beyond that, log data is available via cold backup.
  4. For Paas Customers, they choose the length of backup retention and availability that HealthTensor will implement and enforce.

Potential Trigger Events

Configuration Management Policy

HealthTensor standardizes and automates configuration management through the use of Ansible scripts as well as documentation of all changes to production systems and networks. Scripts automatically configure all HealthTensor systems according to established and tested policies, and is used as part of our Disaster Recovery plan and process.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Configuration Management

  1. Ansible is used to standardize and automate configuration management.
  2. No systems are deployed into HealthTensor environments without approval of the HealthTensor CTO.
  3. All changes to production systems, network devices, and firewalls are approved by the HealthTensor CTO before they are implemented to assure they comply with business and security requirements. Additionally, all changes are tested before they are implemented in production. All changes are documented using Google forms. Implementation of approved changes are only performed by authorized personnel.
  4. Clocks are synchronized across all systems using NTP. Modifying time data on systems is restricted.
  5. All front end functionality (developer dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers.
  6. All software and systems are tested using unit tests and end to end tests.
  7. All committed code is reviewed to assure software code quality and proactively detect potential security issues in development.
  8. HealthTensor utilizes development and staging environments that mirror production to assure proper function.
  9. All formal change requests require unique ID and authentication.
  10. All physical media which might contain ePHI is encrypted at provisioning. To verify encryption is consistent and in place for all production storage, checks are performed on a quarterly basis.

Facility Access Policy

HealthTensor works with Subcontractors to ensure restriction of physical access to systems used as part of the HealthTensor Platform. HealthTensor and its Subcontractors control access to the physical buildings/facilities that house these systems/applications, or in which HealthTensor workforce members operate, in accordance to the HIPAA Security Rule 164.310 and its implementation specifications. Physical Access to all of HealthTensor 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 HealthTensor’s facility.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

HealthTensor-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 organizations 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. Physical access is restricted
    • Restricted areas and facilities are locked and when unattended (where feasible).
    • Only authorized workforce members receive access to restricted areas (as determined by the Security Officer).
    • Access and keys are revoked upon termination of workforce members.
    • Workforce members must report a lost and/or stolen key(s) to the Security Officer.
    • The Security Officer facilitates the changing of the lock(s) within 7 days of a key being reported lost/stolen
  8. 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 HealthTensor.
  9. Workstation Security
    • 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 HealthTensor are the property of HealthTensor and are distributed to users by the company.

Incident Response Policy

HealthTensor 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:

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Incident Management Policies

The HealthTensor incident response process follows the process recommended by SANS, an industry leader in security ( Process flows are a direct representation of the SANS process. Review Appendix 1 for a flowchart identifying each phase.

Identification Phase

  1. Immediately upon observation HealthTensor members report suspected and known Precursors, Events, 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. Online incident response form located here;
    5. Secure Chat.
    6. Anonymously through workforce members desired channels.
    7. The individual receiving the report facilitates completion of an Incident Identification form and notifies the Security Officer (if not already done).
    8. The Security Officer determines if the issue is a Precursor, Event, Indication, or Incident.
    9. 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 (see Appendix 2) 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.
    10. 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 Security Incident Report (SIR) Form (See Appendix 2 for sample format) or an Incident Survey Form (See Appendix 4). 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.
    11. The Security Officer, Privacy Officer, or HealthTensor representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer.
    12. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to HealthTensor and potentially external.

Containment Phase (Technical)

In this Phase, HealthTensor’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 affect 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

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 (see Appendix 4).
  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.

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.

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 HealthTensor 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.

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 the HealthTensor’s expectation for them, relative to security responsibilities. The incident response plan is tested annually.

Security Incident Response Team (SIRT)

Individuals needed and responsible to respond to a security incident make up a Security Incident Response Team (SIRT). Members may include the following:

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, HealthTensor shall notify all affected Customers and partners. It is the responsibility of the Customers to notify affected individuals.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

HealthTensor 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 HealthTensor (includes breaches by the organization’s Customers, Partners, or subcontractors). HealthTensor 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. HealthTensor 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 HealthTensor 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, HealthTensor, 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 HealthTensor partners no later than 5 days 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 HealthTensor 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 toll-free telephone number, an e-mail address, a web site, or postal address.
  7. Methods of Notification: HealthTensor Customers will be notified via email and 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, HealthTensor 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: HealthTensor 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: HealthTensor 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: HealthTensor 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.

HealthTensor SaaS Customer Responsibilities

  1. The HealthTensor Customer that accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses unsecured ePHI shall, without unreasonable delay and in no case later than 60 calendar days after discovery of a breach, notify HealthTensor of such breach. The Customer shall provide HealthTensor with the following information:
    • 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.
  2. Notice to Media: HealthTensor Customers are responsible for providing notice to prominent media outlets at the Customer’s discretion.
  3. Notice to Secretary of HHS: HealthTensor Customers are responsible for providing notice to the Secretary of HHS at the Customer’s discretion.

Sample Letter to Customers in Case of Breach


[Name here] [Address 1 Here] [Address 2 Here] [City, State Zip Code]

Dear [Name of Customer]:

I am writing to you from HealthTensor, Inc. with important information about a recent breach that affects your 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. A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known. B. 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. C. Any steps the Customer should take to protect themselves from potential harm resulting from the breach. D. A brief description of what HealthTensor is doing to investigate the breach, to mitigate harm to individuals, and to protect against further breaches. E. 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:

We will assist you in remedying the situation.


Thomas Moulia Co-founder - HealthTensor, Inc 609-483-6767

Disaster Recovery Policy

The HealthTensor Contingency Plan establishes procedures to recover HealthTensor following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the HealthTensor 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 HealthTensor processing requirements during prolonged interruptions to normal operations.
  3. Identify and define the impact of interruptions to HealthTensor systems.
  4. Assign responsibilities to designated personnel and provide guidance for recovering HealthTensor during prolonged periods of interruption to normal operations.
  5. Ensure coordination with other HealthTensor 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 HealthTensor 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 HealthTensor 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 HealthTensor Contingency Plan also complies with the following federal and departmental policies:

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.

HealthTensor defined 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.

As of November 11th HealthTensor has no Critical Systems deployed.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Line of Succession

The following order of succession to ensure that decision-making authority for the HealthTensor Contingency Plan is uninterrupted. The Chief Technology Officer (CTO) and Security Officer, Thomas Moulia, are responsible for ensuring the safety of personnel and the execution of procedures documented within this HealthTensor Contingency Plan. If the CTO and VP of Engineering are 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.

If the VP of Engineering is not defined, the CTO will take on the VP of Engineering’s responsibilities.


The following teams have been developed and trained to respond to a contingency event affecting the IT system.

  1. The Ops Team is responsible for recovery of the HealthTensor hosted environment, network devices, and all servers. Members of the team include personnel who are also responsible for the daily operations and maintenance of HealthTensor. The team leader is the VP of Engineering and directs the Dev Ops Team.
  2. The Web Services Team is responsible for assuring all application servers, web services, and platform add-ons are working. It is also responsible for testing redeployments and assessing damage to the environment. The team leader is the CTO and directs the Web Services Team.

Everyone on the Engineering Team is a member of both the Ops Team and the Web Services Team.

Testing and Maintenance

The CTO and VP of Engineering 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.

Tabletop Testing

Tabletop Testing is conducted in accordance with the the CMS Risk Management Handbook, Volume 2 ( The primary objective of the tabletop test is to ensure designated personnel are knowledgeable and capable of performing the notification/activation requirements and procedures as outlined in the CP, in a timely manner. The exercises include, but are not limited to:

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:

1. Notification and Activation Phase

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

The notification sequence is listed below:

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 HealthTensor 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 HealthTensor infrastructure to a production state.

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

  1. Contact Partners and Customers affected - Web Services
  2. Assess damage to the environment - Web Services
  3. Begin replication of new environment using automated and tested scrips, currently Salt. At this point it is determined whether to recover in Rackspace, AWS, Azure, or SoftLayer. - Dev Ops
  4. Test new environment using pre-written tests - Web Services
  5. Test logging, security, and alerting functionality - Dev Ops
  6. Assure systems are appropriately patched and up to date. - Dev Ops
  7. Deploy environment to production - Web Services
  8. Update DNS to new environment. - Dev Ops

3. Reconstitution Phase

This section discusses activities necessary for restoring HealthTensor 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, HealthTensor 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 scrips, currently Salt. - Dev Ops
    • Test new environment using pre-written tests. - Web Services
    • Test logging, security, and alerting functionality. - Dev Ops
    • Deploy environment to production - Web Services
    • Assure systems are appropriately patched and up to date. - Dev Ops
    • Update DNS to new environment. - Dev Ops
  2. Plan Deactivation

If the HealthTensor 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 HealthTensor Media Disposal Policy.

Disposable Media Policy

HealthTensor 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.

HealthTensor utilizes dedicated hardware from Subcontractors. ePHI is only stored on volumes in our hosted environment. All volumes containing ePHI are encrypted. HealthTensor does not use, own, or manage any mobile devices, SD cards, or tapes that have access to ePHI.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Disposable Media Policy

  1. All removable media is restricted, audited, and is encrypted.
  2. HealthTensor 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 HealthTensor’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 HealthTensor 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 HealthTensor Customer terminating a contract with HealthTensor and no longer utilize HealthTensor Services, the following actions will be taken depending on the HealthTensor Services in use. In all cases it is solely the responsibility of the HealthTensor Customer to maintain the safeguards required of HIPAA once the data is transmitted out of HealthTensor Systems.
    • In the case of BaaS Customer termination, HealthTensor will provide the customer with the ability to export data in commonly used format, currently CSV, for 30 days from the time of termination.
    • In the case of SaaS Customer termination, HealthTensor will provide the customer with 30 days from the date of termination to export data.

IDS Policy

In order to preserve the integrity of data that HealthTensor stores, processes, or transmits for Customers, HealthTensor implements strong intrusion detection tools and policies to proactively track and retroactively investigate unauthorized access. HealthTensor currently utilizes OSSEC to track file system integrity, monitor log data, and detect rootkit access.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Intrusion Detection Policy

Vulnerability Scanning Policy

HealthTensor is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. HealthTensor utilizes OSSEC on all systems, including logs, for file integrity checking and intrusion detection.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Vulnerability Scanning Policy

Data Integrity Policy

HealthTensor takes data integrity very seriously. As stewards and partners of HealthTensor Customers, 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 HealthTensor mission of data protection.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Data integrity Policy

Production Systems that create, receive, store, or transmit customer ePHI (hereafter “Production Systems”) must follow the following guidelines.

Disabling non-essential services

Monitoring Log-in Attempts

Prevention of malware on Production Systems

Intrusion Detection and Vulnerability Scanning

Production System Security

Production Data Security

Transmission Security

Data Retention Policy

Despite not being a requirement within HIPAA, HealthTensor understands and appreciates the importance of health data retention. Acting as a a business associate, HealthTensor is not directly responsible for health and medical records retention as set forth by each state. Despite this, HealthTensor has created and implemented the following policy to make it easier for HealthTensor Customers to support data retention laws.

State Medical Record Laws

Data Retention Policy

Patch Management Policy

HealthTensor keeps its software and dependencies patched to ensure any discovered vulnerabilities are mitigated quickly. In the context of this policy, a patch is a change to software with HealthTensor has deployed in production systems, and a security patch is a patch intended to address a security vulnerability.

Staying up-to-date on Patches / Vulnerabilities

Patch Impact and Priority

Communicating Changes due to Patches

Applying Patches

Employees Policy

HealthTensor is committed to ensuring all workforce members actively address security and compliance in their roles at HealthTensor. 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.

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

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.
    • Ongoing security training is conducted yearly.
    • Current HealthTensor training is hosted here.
  2. All workforce members are granted access to formal organizational policies, which include the sanction policy for security violations.
  3. HealthTensor does not allow mobile devices to connect to any of its production networks.
  4. All workforce members are educated about the approved set of tools to be installed on workstations.
  5. All new workforce members are given HIPAA training within 60 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 HealthTensor and its Customers and Partners.
  6. 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 VPN tunnels for all access to production systems with access to ePHI data.
  7. Employees may only use HealthTensor-approved workstations for accessing production systems with access to ePHI data.
    • Any workstations used to access production systems must be configured as prescribed by the Employee Workstation Use section of the Systems Access Policy.
    • Any workstations used to access production systems must have virus protection software installed, configured, and enabled.
  8. Access to internal HealthTensor systems can be requested using this form. All requests for access much be granted to the HealthTensor Security Officer.
  9. Request for modifications of access for any HealthTensor employee can be made using this form.

Approved Tools Policy

HealthTensor utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by HealthTensor, 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 HealthTensor leadership.

List of Approved Tools

3rd Party Policy

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

Applicable Standards from the HITRUST Common Security Framework

Applicable Standards from the HIPAA Security Rule

Policies to Assure 3rd Parties Support HealthTensor Compliance

  1. The following steps are required before 3rd parties are granted access to any HealthTensor systems:
    • Due diligence with the 3rd party;
    • Controls implemented to maintain compliance;
    • Written agreements, with appropriate security requirements, are executed.
  2. All connections and data in transit between the HealthTensor Platform and 3rd parties are encrypted end to end.
  3. Access granted to external parties is limited to the minimum necessary and granted only for the duration required.
  4. 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.
  5. HealthTensor has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management.
    • HealthTensor utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs.
  6. Third parties are unable to make changes to any HealthTensor infrastructure without explicit permission from HealthTensor. Additionally, no HealthTensor Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
  7. Whenever outsourced development is utilized by HealthTensor, all changes to production systems will be approved and implemented by HealthTensor workforce members only. All outsourced development requires a formal contract with HealthTensor.
  8. HealthTensor maintains and annually reviews a list all current Partners and Subcontractors.
  9. HealthTensor assesses security requirements and compliance considerations with all Partners and Subcontracts. This includes annual assessment of SOC2 Reports for all HealthTensor infrastructure partners.
    • HealthTensor leverages recurring calendar invites to assure reviews of SLAs with all 3rd parties are performed annually. These are performed by the HealthTensor Security Officer and Privacy Officer. Google Forms are used to track such reviews.
  10. 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.
  11. Any changes to Partner and Subcontractor services and systems are reviewed before implementation.
  12. For all partners, HealthTensor reviews activity annually to assure partners are in line with SLAs in contracts with HealthTensor.

Key Definitions

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. 
© HealthTensor, Inc. 2016