PulseData Compliance

> Policy Docs
CLOSE MENU

1. Introduction

PulseData, Inc (“PulseData”) is committed to ensuring the confidentiality, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its Customers. As providers of machine learning analytics and patient workflow and management software used by healthcare providers and insurance providers, PulseData strives to maintain compliance, proactively address information security, mitigate risk for its Customers, and ensure known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by PulseData to maintain compliance and ensure the proper protections of infrastructure used to store, process, and transmit ePHI for PulseData Customers.

PulseData provides secure and compliant software to assess and manage patient risk. This software falls into two broad categories: 1) Client Hosted and 2) PulseData Hosted. These Categories are cited throughout polices as Customers in each category inherit different policies, procedures, and obligations from PulseData.

1.1 Client Hosted

PulseData is a small, flexible company that is able to tailor a solution specific to each client and comply with the risk management and security requirements of that client. We are able to deploy our platform within the client’s datacenter behind the client’s security controls. This allows for maximum security and ensures that client data does not have to be exported out of a client-controlled infrastructure.

PulseData has experience running our software and machine learning pipeline inside each of the three major cloud providers: Microsoft Azure, Google Cloud Platform, and Amazon Web Services. We can also run our software and machine leaning pipeline within the client’s own datacenter.

Once deployed, the PulseData software suite ingests client data using agreed upon queries and datasources within the provided environment. The machine learning pipeline processes the data and produces risk scores which are pushed to the client’s care management platform, ensuring that risky patients are flagged for follow-up. Patient lists and risk scores are also securely uploaded to the client directly.

PulseData developers access the deployment using agreed upon methods which is generally via secure shell (ssh) over VPN.

1.2 Business Associate Agreements

PulseData signs business associate agreements (BAAs) with its Customers. These BAAs outline PulseData obligations and Customer obligations, as well as liability in the case of a breach.

PulseData does not act as a covered entity. When PulseData does operate as a business associate (not a subcontractor), PulseData does not interface with patients to obtain or provide access to ePHI.

1.3 PulseData Hosted

PulseData can provision a new environment in one of the three three major cloud providers - Microsoft Azure, Google Cloud Platform, or Amazon Web Services - with a BAA as required for HIPAA compliance.

The physical infrastructure environment is hosted at Amazon Web Services (AWS), Microsoft Azure, and Google Cloud. The network components and supporting network infrastructure are contained within the AWS, Azure, and Google Cloud infrastructures and managed by AWS, Microsoft, and Google (respectively). PulseData does not have physical access into the network components.

Each cloud provider provides policies and reports for many standards, regulations and certifications * https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings * https://cloud.google.com/security/compliance/#/ * https://aws.amazon.com/compliance/programs/

The PulseData environment consists of the Apache Spark analytics engine for data processing as well as Python and JavaScript applications running on a Kubernetes cluster for workflow and patient management.

PulseData takes advantage of the security features available on each cloud platform. For example: We ensure that all data is encrypted at rest and during transfer, firewalls and network security policies are configured to block unauthorized access, access and login activity is logged, access to public facing web applications require JWT authentication tokens, and all traffic is encrypted using TLS. PulseData assumes all data may contain ePHI, even though our Risk Assessment does not indicate this is the case, and provides appropriate protections based on that assumption.

Within this environment PulseData will provide a secure method for the client to upload data which is generally an SFTP (Secure File Transfer Protocol) server. The uploaded data is stored in disks that are encrypted at rest with the AES-128 standard at minimum. Our machine learning pipeline processes the uploaded data and produces risk scores which are displayed within the client’s care management platform. PulseData developers access the deployment using secure shell (ssh) from inside of a VPN protected connection.

1.4 Requesting Audit and Compliance Reports

PulseData, at its sole discretion, may share audit reports with Customers on a case by case basis. All audit reports are shared under explicit NDA (Non-Disclosure Agreement) in PulseData format between PulseData and the party to receive the materials. Audit reports can be requested by PulseData workforce members on behalf of Customers or directly by PulseData Customers.

The following process is used to request audit reports:

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

1.5 Version Control

Refer to the GitLab repository at https://gitlab.com/pulsedata/pd_policies/ for the full version history of these policies.

2. Privacy Policy

PulseData, Inc. (“PulseData”) protects our customer’s personal information to maintain their privacy. This document (the “Privacy Policy”) details how we collect, use, share, transfer, and disclose personal information. The Privacy Policy applies to the PulseData Website, PulseData.io (the “Website”), as well as the PulseData Platform (the “Platform”).

Personal Information

Website

Visitors to the Website are free to view the Website at any time. Visitors do not need to provide personal information to access the Website’s contents, however they may choose to provide contact information through forms. PulseData does not publish any personal information about customers or visitors on the Website nor share any personal information with third parties without first receiving their explicit and informed consent with the only exception being cases where PulseData is required to do so by law or regulation. If visitors choose to supply contact information we may contact them and ask for additional information, however they may decline to receive our contact requests and/or answer any questions.

Platform

Users of the Platform must first be authorized by PulseData to have access to the Platform. PulseData will give each user, in a secure manner, a unique user ID and initial password. Upon first using the Platform users will be prompted to change their password as well as provide an email address. Neither the user ID, password, nor email address will be published or shared with a third party with the only exception being cases where PulseData is required to do so by law or regulation.

Email

We will never email you to ask for your password, user ID, account numbers, or any other personal information. Do not respond to such communications. These messages are most likely fraudulent and meant to steal your information in a tactic called “Phishing”.

User Name and Password

If you become a user of the Platform it is your responsibility to not share your user ID or password. We inform you that sharing such information could allow someone to log in into your account on the Platform and access your personal information.

Data Retention

PulseData will save your personal information with your other account or contact information. The information will be held until there is no longer an existing or possible future customer relationship or as needed to comply with our legal obligations, to resolve disputes, or to enforce our agreements.

Accessing and Updating Personal Information

You can ask to change your personal information we store by contacting us at: privacy@pulsedata.io.

Quality

You are responsible for ensuring the personal information provided to PulseData is accurate and complete and you are responsible for contacting PulseData through the above email if the provided information needs to be corrected.

Monitoring and Enforcement

To maintain Website security, PulseData reserves the right to utilize network traffic monitoring services and software to uncover harmful and/or malicious activity. Any unauthorized actions attempting to upload or change information are strictly prohibited and may be punishable under the Computer Fraud and Abuse Act of 1986 and the National Information Infrastructure Protection Act as well as other federal, state, and local law as is applicable.

Non-Personal Information

PulseData reserves the right to collect non-personal information such as number of Website visits, Website response times, and other statistics. This information is collected from tracking your visits to the Website and/or Platform.

IP Addresses

PulseData reserves the right to collect the IP (Internet Protocol) address of computers that access the Website or Platform. Since the IP address is assigned to the device and it is not known who is using the device the IP address is not considered personally identifiable information. You should be aware that, from an IP address, a visitor’s internet service provider and geographic location can be determined. PulseData may use summaries of this data to understand how to improve the Website.

Security of Personal Information

PulseData encrypts all personal information supplied to our Website and Platform. The received personal information is secured in a password protected database to prevent unauthorized access.

PulseData periodically reviews and updates its security policy and procedures. PulseData takes reasonable steps to protect your personal information.

Disclaimer of Warranty

THE FOLLOWING WARRANTY APPLIES TO THE WEBSITE AND PLATFORM. MATERIALS, SERVICES AND OTHER INFORMATION ARE PROVIDED “AS IS” BY PULSEDATA FOR EDUCATIONAL PURPOSES ONLY. PULSEDATA MAKES NO EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR USE, TITLE OR NON-INFRINGEMENT.

PLEASE NOTE THAT, BY ITS VERY NATURE, A WEBSITE CANNOT BE ABSOLUTELY PROTECTED AGAINST INTENTIONAL OR MALICIOUS INTRUSION ATTEMPTS. FURTHERMORE, PULSEDATA DOES NOT CONTROL THE DEVICES OR COMPUTERS OR THE INTERNET OVER WHICH YOU MAY CHOOSE TO SEND CONFIDENTIAL PERSONAL INFORMATION AND CANNOT, THEREFORE, PREVENT SUCH INTERCEPTIONS OF COMPROMISES TO YOUR INFORMATION WHILE IN TRANSIT TO PULSEDATA.

THEREFORE, PULSEDATA HEREBY MAKES NO GUARANTEE AS TO SECURITY, INTEGRITY OR CONFIDENTIALITY OF ANY INFORMATION TRANSMITTED TO OR FROM THIS WEBSITE, OR STORED WITHIN THIS WEBSITE.

BEYOND OUR REASONABLE CARE TO SAFEGUARD YOUR INFORMATION WHILE IN TRANSIT, PULSEDATA CANNOT AND DOES NOT GUARANTEE THE ABSOLUTE SECURITY OF ELECTRONIC COMMUNICATIONS OR TRANSMISSIONS SINCE ANY TRANSMISSION MADE OVER THE INTERNET BY ANY ORGANIZATION OR ANY INDIVIDUAL RUNS THE RISK OF INTERCEPTION.

IN ADDITION, PULSEDATA HEREBY MAKES NO GUARANTEE AS TO SECURITY, INTEGRITY OR CONFIDENTIALITY OF ANY INFORMATION TRANSMITTED TO OR FROM THIS WEBSITE, OR STORED WITHIN THIS WEBSITE.

Limitations of Liability

THE FOLLOWING LIMITATION OF LIABILITY CLAUSE APPLIES TO THE WEBSITE AND PLATFORM.

YOU ASSUME THE SOLE RISK OF TRANSMITTING YOUR INFORMATION AS IT RELATES TO THE USE OF THIS WEBSITE, AND FOR ANY DATA CORRUPTIONS, INTENTIONAL INTERCEPTIONS, INTRUSIONS OR UNAUTHORIZED ACCESS TO INFORMATION, OR OF ANY DELAYS, INTERRUPTIONS TO OR FAILURES PREVENTING THE USE THIS WEBSITE.

IN NO EVENT SHALL PULSEDATA BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL OR MONETARY DAMAGES, INCLUDING FEES, AND PENALTIES IN CONNECTION WITH YOUR USE OF MATERIALS POSTED ON THIS SITE OR CONNECTIVITY TO OR FROM THIS SITE TO ANY OTHER SITE.

PULSEDATA MAY CHANGE THIS PRIVACY POLICY WITHOUT NOTICE TO YOU.

Other services provided by PulseData on this Website may require you to agree to additional terms.

By using our Website and/or the Platform, you consent to the collection and use of the information discussed above by PulseData. Changes in this policy will be posted on this page so that you may always be aware of what information is being collected, how it is being used, and under what circumstances it is being disclosed

If you have any questions about our privacy policy or our use of information gathered through our Web site, please contact our Webmaster at privacy@pulsedata.io

3. Policy Management Policy

PulseData implements policies and procedures to maintain compliance and the integrity of data. The Security Officer, Privacy Officer, and assigned delegates are responsible for maintaining policies and procedures and ensuring all PulseData workforce members, business associates, customers, and partners are adherent to all applicable policies. Previous versions of policies are retained to ensure 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

3.1.2 Applicable Standards from the HIPAA Security Rule

3.2 Maintenance of Policies

  1. All policies are stored and updated to maintain PulseData compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control are managed similarly 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 the Security Officer, Privacy Officer, or assigned delegates to ensure they are accurate and up-to-date.
  3. PulseData employees may request changes to policies using the following process:
    1. The PulseData employee initiates a policy change request by creating an Issue in the PulseData Quality Management System. The change request may optionally include a Gitlab merge request from a separate branch or repository containing the desired changes.
    2. The Security Officer, Privacy Officer, or an assigned delegate is assigned to review the policy change request.
    3. Once the review is completed, the Security Officer, Privacy Officer, or an assigned delegate 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, Privacy Officer, or an assigned delegate 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 PulseData’s change management process (§9.4).
  4. All policies are made accessible to all PulseData workforce members. The current master policies are published at https://policy.pulsedata.io.
    • Changes are automatically communicated to all PulseData team members through integrations between Gitlab and Slack that log all Gitlab policy channels to a dedicated PulseData Slack Channel.
    • The Security Officer or an assigned delegate 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 was last in effect, whichever is later.
    1. The version histories of all PulseData policies are managed via Gitlab.
  6. The policies and information security policies are reviewed and audited annually or after significant changes occur to PulseData’s organizational environment. Issues that come up as part of this process are reviewed by PulseData management to ensure all risks and potential gaps are mitigated and/or fully addressed. The process for reviewing polices is outlined below:
    1. The Security Officer or an assigned delegate initiates the policy review by creating an Issue in the PulseData Quality Management System.
    2. The Security Officer, Privacy Officer or an assigned delegate is assigned to review the current PulseData policies (https://policy.pulsedata.io/).
    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, Privacy Officer or an assigned delegate 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, Privacy Officer or an assigned delegate 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.

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 PulseData’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

4.1.2 Applicable Standards from the HIPAA Security Rule

4.2 Risk Management Policies

  1. It is the policy of PulseData 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 for its Customers and to develop strategies to efficiently and effectively mitigate the risks identified in the assessment process as an integral part of the PulseData information security program.

  2. Risk analysis and risk management are recognized as important components of PulseData’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:
      1. Before the integration of new system technologies and before changes are made to PulseData 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 PulseData Platform.
      2. While making changes to PulseData physical equipment and facilities that introduce new, untested configurations.
    2. PulseData 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. PulseData implements security measures that will sufficiently reduce risks and vulnerabilities to a reasonable and appropriate level and to:

    1. Ensure the confidentiality, integrity, and availability of all ePHI PulseData 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 PulseData’s Security Officer or an assigned delegate.

  5. All PulseData workforce members are expected to fully cooperate with all persons charged with doing risk management work, including all 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 PulseData Roles Policy.

  6. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of PulseData’s Security Officer or an assigned delegate 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, Privacy Officer, or an assigned delegate initiates the Risk Management Process by creating an Issue in the PulseData Quality Management System.
    2. The Security Officer, Privacy Officer, or an assigned delegate is assigned to carry out the Risk Management Process.
    3. All findings are documented in an approved spreadsheet that is linked to the Issue.
    4. Once the Risk Management Process is complete, along with corresponding documentation, the Security Officer or an assigned delegate 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 assigned delegate then marks the Issue as Done, adding any pertinent notes required.

  9. The Risk Management Process is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with the above policy.

4.3 Risk Management Process

4.3.1 Risk Assessment

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

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

4.3.3 Risk Management Schedule

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

4.4 Process Documentation

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

5. Roles Policy

PulseData 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

5.1.2 Applicable Standards from the HIPAA Security Rule

5.2 Privacy Officer

The Privacy Officer is responsible for assisting with compliance and security training for workforce members, ensuring the organization remains in compliance with evolving compliance rules, and helping the Security Officer or assigned delegate with their responsibilities. The Privacy Officer is appointed by and reports to the CEO.

  1. Provides annual training to all workforce members on established policies and procedures as necessary and appropriate to carry out their job functions and maintains documentation on the training provided.
  2. Assists in the administration and oversight of business associate agreements.
  3. Manages relationships with customers and partners as those relationships affect the confidentiality, integrity, and availability of ePHI and compliance of the organization.
  4. Assist Security Officer or assigned delegate as needed.

The current PulseData Privacy Officer is Ash Luna.

5.2.1 Workforce Training Responsibilities

  1. The Privacy Officer or an assigned delegate 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 policies and procedures within a month after the material change becomes effective; and
    4. Existing workforce members as needed due to changes in security and risk posture of PulseData.
  2. The Security Officer or an assigned delegate maintains documentation of training session materials and attendees for a minimum of six years.
  3. The training sessions focus on, but are not limited to, the following subjects defined in PulseData’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 with the knowledge that PulseData may monitor the access and activities of all users
    6. Workstations may only be used to perform assigned job responsibilities
    7. Users may not download software onto PulseData’s workstations and/or systems without prior approval from the Security Officer or an assigned delegate
    8. Users are required to report malicious software to the Security Officer or an assigned delegate immediately
    9. Users are required to report unauthorized attempts, uses of, and theft of PulseData’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 PulseData Customer
    13. Users are required to understand their role in PulseData’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 15 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 back up 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

5.3 Security Officer

The Security Officer, or an assigned delegate, 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 PulseData security policies and non-compliance with the security regulations [164.308(a)(1)(ii)©], and writing, implementing, and maintaining all policies, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)]. The Security Officer is appointed by and reports to the CEO.

The current PulseData Security Officer is Ash Luna.

5.3.1 Organizational Responsibilities

The Security Officer or their assigned delegate, in collaboration with the Privacy Officer or their assigned delegate, is responsible for facilitating the development, testing, implementation, training, and oversight of all activities pertaining to PulseData’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’s, or their assigned delegate’s, 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 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 the date they were 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 the date they were 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 the 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 the PulseData 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. In addition:
    • 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 PulseData.
    • Mitigates, to the extent practicable, any harmful effect known to PulseData of a use or disclosure of ePHI in violation of PulseData’s policies and procedures, even if the effect is the result of the actions of PulseData 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 PulseData Breach Policy.
  12. The Security Officer or an assigned delegate 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;
    • PulseData’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 or an assigned delegate. 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 or an assigned delegate works with the COO to ensure that any security objectives have appropriate consideration during the budgeting process.
    • In general, security and compliance are core to PulseData’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 or an assigned delegate follows PulseData’s standard corporate budgeting process.
      • At the beginning of every fiscal year, the COO contacts the Security Officer to plan for the upcoming year’s expenses.
      • The Security Officer or an assigned delegate works with the COO to forecast spending needs based on the previous year’s level, along with changes for the upcoming year such as additional staff hires.
      • If an unforeseen security-related expense arises during the year that was not in the budget forecast then the Security Officer or an assigned delegate works with the COO to reallocate any resources as necessary to cover this expense.

5.3.2 Supervision of Workforce Responsibilities

Although the Security Officer and their assigned delegate 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 PulseData’s systems, applications, servers, workstations, etc., that may 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, or their assigned delegates, 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 PulseData’s security policies and procedures.

5.3.3 Sanctions of Workforce Responsibilities

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

  1. The Security Officer or their assigned delegate promptly facilitates a thorough investigation of all reported violations of PulseData’s security policies and procedures. The Security Officer or their assigned delegate 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 PulseData’s policies and procedures with 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.
    • A violation resulting in a breach of confidentiality (i.e. release of ePHI to an unauthorized individual), change to the integrity of any ePHI, or the inability to access any ePHI by other users requires immediate termination of the workforce member from PulseData.
  3. The Security Officer or their assigned delegate 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, or their assigned delegates, are to set up a team to investigate and mitigate the risk of insider malicious activity. PulseData workforce members are encouraged to come forward with information about insider threats, and can do so anonymously.
  5. The Security Officer or their assigned delegate maintains all documentation of the investigation, sanctions enacted, and actions taken to prevent recurrence for a minimum of six years after the conclusion of the investigation.

6. Backup Policy

PulseData has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI) as we delivered by the customer. The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by PulseData.

Data backup is an important part of the day-to-day operations of PulseData. To protect the confidentiality, integrity, and availability of ePHI, both for PulseData and PulseData Customers, complete backups are done routinely 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

6.1.2 Applicable Standards from the HIPAA Security Rule

6.2 Backup Policy and Procedures

  1. Perform routine snapshot backups of all systems that process, store, or transmit ePHI for PulseData Customers.
  2. The PulseData Ops Team is designated to be in charge of backups.
  3. Dev Ops 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 annually and document that files have been completely and accurately restored from the backup media.

7. System Access Policy

Access to PulseData systems and applications are 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 use 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

7.1.2 Applicable Standards from the HIPAA Security Rule

7.2 Access Establishment and Modification

  1. Requests for access to PulseData Platform systems and applications is made formally using the following process:
    1. A PulseData workforce member initiates the access request by creating an Issue in the PulseData 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, Privacy Officer, or an assigned delegate will approve 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, Privacy Officer, or an assigned delegate 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, Privacy Officer, or an assigned delegate then marks the Issue as Approved, adding any pertinent notes required. The IT Ops Team then grants the requested and approved 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 and encrypted channel.
      • For production systems, access grants are accomplished by adding the appropriate user account to the corresponding Auth0 database.
      • For non-production systems, access grants are accomplished by leveraging the access control mechanisms built into those systems. Account management for non-production systems may be delegated to a PulseData employee at the discretion of the Security Officer, Privacy Officer, or an assigned delegate .
  2. Access is not granted until after the receipt, review, and approval by the PulseData Security Officer, Privacy Officer, or an assigned delegate.
  3. The request for access and all associated notes are retained for future reference.
  4. All access to PulseData 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, or an assigned delegate, initiates the review of user access by creating an Issue in the PulseData Quality Management System.
    2. The Security Officer, or assigned delegate, is assigned to review levels of access for each PulseData 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 or assigned delegate 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 assigned delegate 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 PulseData workforce member can request change of access using the process outlined in §7.2 paragraph 1.
  6. Access to production systems is controlled using centralized user management and authentication.
  7. 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.
  8. In the case of non-personal information, such as generic educational content, identification and authentication may not be required. This is the responsibility of PulseData Customers to define, and not PulseData.
  9. Privileged users must first access systems using standard, unique user accounts before switching to privileged users and performing privileged tasks.
    • For production systems, this is enforced by creating non-privileged user accounts that must invoke sudo to perform privileged tasks.
    • Rights for privileged accounts are granted by the Security Officer, Privacy Officer, or an assigned delegate using the process outlined in §7.2 paragraph 1.
  10. 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.
  11. Generic accounts are not allowed on PulseData systems.
  12. Access is granted through encrypted SSH connections accessible only via VPN connection.
  13. In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security Officer, Privacy Officer, or an assigned delegate to limit access and reduce risk of unauthorized access.
  14. Direct system to system, system to application, and application to application authentication and authorizations are limited and controlled to restrict access.

7.3 Workforce Clearance

  1. The level of access assigned to a user for 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 considered using the “least-access principle.”
  3. PulseData maintains a minimum necessary approach for access to Customer data. As such, PulseData, including all workforce members, do not readily have access to any ePHI.

7.4 Access Authorization

  1. Role based access categories for each PulseData system and application are pre-approved by the Security Officer, or an authorized delegate of the Security Officer.
  2. PulseData utilizes hardware and software firewalls 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 them as a user of the information system.
  2. Each Customer and Partner has and uses a unique user ID and password that identifies them as a user of the information system.
  3. All Customer support desk interactions must be verified before PulseData support personnel will satisfy any request having information security implications.
    • Support issues submitted by email must be verified by PulseData personnel using a phone number that has been registered with the corresponding account.

7.6 Unique User Identification

  1. Access to the PulseData 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 PulseData systems or networks.
  6. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with PulseData 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 or an assigned delegate pre-approves exceptions to automatic log off requirements.

7.8 Employee Workstation Use

All workstations at PulseData are company owned, and all devices are laptop products running Windows, Mac OSX, or Linux operating systems.

  1. Workstations may not be used to engage in any activity that is illegal or is in violation of organizational 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 the 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 the organization’s best interests.
  4. Solicitation of non-company business, or any use of the 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 the AES-128 standard at minimum with AES-256 where possible.
  8. All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.

7.9 Wireless Access Use

  1. PulseData 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 PulseData 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 quarterly. This process is managed by the PulseData Security Officer or an assigned delegate.

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 or their assigned delegate 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 or their assigned delegate 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 or an assigned delegate):
    • 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 or an assigned delegate will terminate a user’s access rights immediately upon notification, and will coordinate with the appropriate PulseData employees to terminate access to any non-production systems managed by those employees.
  4. The Security Officer or an assigned delegate audits and may terminate the access of users that have not logged into the organization’s information systems/applications for an extended period of time.

7.11 Paper Records

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

7.12 Password Management

  1. User IDs and passwords are used to control access to PulseData 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 PulseData environment, password configurations are set to require:
    • a minimum length of 8 characters;
    • a mix of upper case characters, lower case characters, and numbers or special characters;
    • a 90-day password expiration, or 60-day password expiration for administrative accounts;
    • prevention of password reuse using a history of the last 6 passwords;
    • where supported, modifying at least 4 characters when changing passwords;
    • account lockout after 5 invalid attempts.
  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. Each information system automatically requires users to change passwords at a pre-determined interval as determined by the organization, based on the criticality and sensitivity of the ePHI contained within the network, system, application, and/or database.
  6. Passwords are deactivated immediately upon an employee’s termination (refer to the Employee Termination Procedures in §7.10).
  7. All default system, application, and Partner passwords are changed before deployment to production.
  8. Upon initial login, users must change any passwords that were automatically generated for them.
  9. Password change methods must use a confirmation method to correct for user input errors.
  10. All passwords used in configuration scripts are secured and encrypted.
  11. If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Office.
  12. 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@pulsedata.io. 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.
    • Password reset requests are stored and tracked via the password-reset inbox. The Security Officer or an assigned delegate is the owner of this group and modifies membership as needed.

8. Auditing Policy

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

This policy applies to all PulseData Add-on systems, including BaaS, that store, transmit, or process ePHI.

8.1 Applicable Standards

8.1.1 Applicable Standards from the HITRUST Common Security Framework

8.1.2 Applicable Standards from the HIPAA Security Rule

8.2 Auditing Policies

  1. Responsibility for auditing information system access and activity is assigned to PulseData’s Security Officer. The Security Officer or an assigned delegate 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 PulseData are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
  2. PulseData’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 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. PulseData utilizes file system monitoring from Datadog to ensure the integrity of file system data.
    • Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
  3. PulseData 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 PulseData.
  4. PulseData utilizes Malwarebytes and ClamAV to scan all systems for malicious and unauthorized software daily.
  5. PulseData leverages process monitoring tools throughout its environment.
  6. PulseData uses the Datadog platform to monitor the integrity of log files.
  7. PulseData 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 PulseData Platform or may be specific to a Customer, partner, business associate, Platform Add-on or application (See Listing of Potential Trigger Events below).
  8. In addition to trigger events, PulseData utilizes Datadog’s log correlation functionality to proactively identify and enable alerts based on log data.
  9. Logs are reviewed weekly by the Security Officer or an assigned delegate.
  10. PulseData’s Security Officer and Privacy Officer, or their assigned delegates, 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 PulseData 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.

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, the Privacy Officer, Security Officer, Customer, Partner, 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 PulseData’s Security Officer, Privacy Officer, or an assigned delegate.
  3. A request for an audit must be approved by PulseData’s Privacy Officer and/or Security Officer, or an assigned delegate, 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 PulseData’s Security Officer or an assigned delegate 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 PulseData’s Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that PulseData 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 ensure that the proper data is being captured and retained. The following process details how log reviews are done at PulseData:
    1. The Security Officer or an assigned delegate initiates the log review by creating an Issue in the PulseData Quality Management System.
    2. The Security Officer, or a PulseData 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 or an assigned delegate 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 or an assigned delegate 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. PulseData’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 PulseData’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 PulseData and the 3rd party. PulseData will make every effort to ensure that 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, PulseData’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, PulseData 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.
    • PulseData uses the logging systems provided by the cloud provider. This includes stackdriver for GCP, Azure Monitor, etc. These services provide error logging, resource usage monitoring and alerting.

8.7 Workforce Training, Education, Awareness and Responsibilities

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

8.8 External Audits of Information Access and Activity

  1. Prior to contracting with an external audit firm, PulseData 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 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:
    • Organizational history and experience.
    • Available storage space.
  2. Reports summarizing audit activities shall be retained for a period of six years.
  3. Audit log data is retained locally on the audit log server for a one-month period. Beyond that, log data is encrypted, moved to warm storage (currently Google Drive), and is retained for a minimum of one year.

8.10 Potential Trigger Events

9. Configuration Management Policy

PulseData standardizes and automates configuration management through the use of Toaster, an internally developed python application, Slack automation tools and Terraform, as well as documentation of all changes to production systems and networks. These tools configure all PulseData 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

9.1.2 Applicable Standards from the HIPAA Security Rule

9.2 Configuration Management Policies

  1. Toaster, Slack, and Terraform are used to standardize and automate configuration management.
  2. No systems are deployed into PulseData production environments without the approval of a member of the security team.
  3. All changes to production systems, network devices, and firewalls are approved by a member of the security team before they are implemented to ensure 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. An up-to-date inventory of systems, including corresponding architecture diagrams for related products and services, is automatically generated via the Datadog platform.
    • These inventories are used as requirements for the Risk Assessment phase of PulseData’s Risk Management procedures (§4.3.1).
  7. All frontend functionality (developer dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers or containers.
  8. All software and systems are tested using unit tests and end to end tests.
  9. All committed code is reviewed using merge requests to ensure software code quality and proactively detect potential security issues in development.
  10. PulseData utilizes development and staging environments that mirror production to ensure proper function.
  11. All formal change requests require unique ID and authentication.
  12. PulseData uses suggestions from the Security Technical Implementation Guides (STIGs) published by the Defense Information Systems Agency as a baseline for hardening systems.
  13. Clocks are continuously synchronized to an authoritative source across all systems using NTP or a platform-specific equivalent. Modifying time data on systems is restricted.

9.3 Provisioning Production Systems

  1. Before provisioning any systems, ops team members must file a request in the PulseData Quality Management System.
  2. A member of the security team must approve the provisioning request before any new system can be provisioned.
  3. Once provisioning has been approved, the ops team member must configure the new system according to the standard baseline chosen for the system’s role.
    • For Kubernetes systems, this means adding a new cluster configuration to Toaster.
    • For Linux systems, this means adding or modifying the appropriate Terraform module.
  4. If the system will be used to house production data (ePHI), the ops team member must add an encrypted block data volume to the VM during provisioning.
  5. Once the system has been provisioned, the ops team member must contact the security team to inspect the new system. A member of the security team will verify that the secure baseline has been applied to the new system, including (but not limited to) verifying the following items:
    • Removal of default users used during provisioning.
    • Network configuration for system.
    • Data volume encryption settings.
    • Intrusion detection and virus scanning software installed.
    • Standard firewall “block by default” rulesets
    • All items listed below in the operating system-specific subsections below.
  6. Once the security team member has verified the new system is correctly configured, the team member must add that system to the Datadog security agent configuration and the InsightVM vulnerability scanning platform.
  7. The new system may be rotated into production once a member of the security team verifies all the provisioning steps listed above have been correctly followed and has marked the Issue with the Approved state.

9.3.1 Provisioning Linux Systems

  1. Linux systems have their baseline security configuration applied via Terraform modules. These baseline modules states cover:
    • Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
    • Stopping and disabling any unnecessary OS services.
    • Installing and configuring the Datadog agent.
    • Configuring 15-minute session inactivity timeouts.
    • Installing and configuring the ClamAV virus scanner.
    • Installing and configuring the NTP daemon, including ensuring that modifying system time cannot be performed by unprivileged users.
    • Configuring LUKS volumes for providers that do not have native support for encrypted data volumes, including ensuring that encryption keys are protected from unauthorized access.
    • Configuring authentication and ssh keys
    • Configuring audit logging as described in the Auditing Policy section.
  2. Any additional Terraform modules applied to the Linux system must be clearly documented by the ops team member in the DT request by specifying the purpose of the new system.

9.3.2 Provisioning Management Systems

  1. Critical infrastructure services such as logging and monitoring must be configured with appropriate Terraform module or Toaster configuration.
    • These must have been approved by a member of the security team to be in accordance with all PulseData policies, including setting appropriate:
      • Audit logging requirements.
      • Password size, strength, and expiration requirements.
      • Transmission encryption requirements.
      • Network connectivity timeouts.
  2. Critical infrastruture roles applied to new systems must be clearly documented by the ops team member in the DT request.

9.4 Changing Existing Systems

  1. Subsequent changes to already-provisioned systems are unconditionally handled by one of the following methods:
    • Changes to a Terraform module
    • Changes to the Toaster configuration
    • For configuration changes that cannot be handled by Toaster or Terraform, a comment on the JIRA ticket describing exactly what changes were made and by whom. The output should include screenshots of the cloud console or a copy of the terminal commands and output when relevant.
  2. Configuration changes to Terraform modules or Toaster configurations must be initiated by creating a Merge Request in GitLab.
    • The ops team member will create a feature branch and make their changes on that branch.
    • The ops team member must test their configuration change locally when possible, or on a development and/or staging sandbox otherwise.
    • At least one other ops team member must review the change before merging the change into the main branch.
  3. In all cases, before rolling out the change to production, the ops team member must file an issue in JIRA describing the change. This issue must link to the reviewed Merge Request and/or include a link to the runbook.
  4. Once the request has been approved, the ops team member may roll out the change into production environments.

9.5 Patch Management Procedures

  1. PulseData uses automated tooling to ensure systems are up-to-date with the latest security patches.
  2. Our Kubernetes clusters use automatically updated release channels as provided by the cloud provider.
    • On GCP, PulseData uses the stable release channel with a maintenance window outside of business hours.
  3. On all Ubuntu Linux systems, the apt package management tool is used to apply security patches in phases.
    • The security team maintains a separate snapshot of security patches from the upstream OS vendor. This snapshot is synchronized and applied to testing instances weekly.
    • If the testing systems function properly after the one-week testing period, the security team will promote that snapshot to the instance used by all other development systems.
    • Patches for critical kernel security vulnerabilities may be applied to production systems using hot-patching tools at the discretion of the Security Officer or an assigned delegate. These patches must follow the same phased testing process used for non-kernel security patches; this process may be expedited for severe vulnerabilities.

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.
  2. Once the changes are complete a merge request will be created using the GitLab web interface. The merge request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made, references to the relevant JIRA ticket are highly encouraged. Merge requests must pass the CICD pipeline on that repo, which include unit tests, integration tests, static error checking and linting.
  3. Code reviews are performed as part of the merge request procedure. Once a change is ready for review, the author will designate an assigned and notify other engineers using an appropriate mechanism, typically via Slack.
    • The assigned engineer will review the changes, ensuring the accuracy of the change, emphasizing the readability, maintainability, and scalability of the code.
    • Engineers should note all potential issues with the code; it is the responsibility of the author to address those issues or explain why they are not applicable.
  4. If the feature or defect interacts with a core component of ML pipeline, or controls access to data potentially containing ePHI, the code changes must be reviewed by a senior member of PulseData’s development before the merge request is marked as approved.
    • The reviewer will consider a security analysis of features to ensure they satisfy PulseData’s compliance and security commitments.
    • This reviewer will consider 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.
    • All engineering team members are required to undergo annual training on identifying the most common software vulnerabilities and will receive ongoing training on PulseData’s compliance and security requirements.
  5. Once the review process finishes, each reviewer should use the “Approve” button on the merge request, 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

PulseData works with Cloud computing providers (AWS, Google Cloud, Microsoft Azure) to assure restriction of physical access to systems used as part of the PulseData Platform. These providers control access to the physical buildings/facilities that house these systems/applications in accordance to the HIPAA Security Rule 164.310 and its implementation specifications.

Additionally, physical Access to all of PulseData 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 PulseData’s facility.

PulseData does not physically house any systems used by its Software in PulseData facilities. Physical security of our Platform servers is outlined in §1.3.

10.1 Applicable Standards

10.1.1 Applicable Standards from the HITRUST Common Security Framework

10.1.2 Applicable Standards from the HIPAA Security Rule

10.2 PulseData-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. Physical access is restricted using smart locks that track all access.
    • Restricted areas and facilities are locked when unattended (where feasible).
    • Only authorized workforce members receive access to restricted areas (as determined by the Security Officer or an assigned delegate).
    • 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 or their assigned delegate.
    • The Security Officer or an assigned delegate 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 or their assigned delegate.
    • 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 PulseData.
  9. 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 PulseData are the property of PulseData and are distributed to users by the company.

11. Incident Response Policy

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

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.1.2 Applicable Standards from the HIPAA Security Rule

11.2 Incident Management Policies

The PulseData 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.

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

PulseData 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 or an assigned delegate know about any observed precursors or indications as soon as they are discovered.

11.2.1 Identification Phase

  1. Immediately upon observation PulseData 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 or their assigned delegate (if not already done).
  3. The Security Officer or an assigned delegate determines if the issue is an Event, Precursor, Indication, or Incident.
    1. If the issue is an event, indication, or precursor the Security Officer or an assigned delegate forwards it to the appropriate resource for resolution.
      1. Non-Technical Event (minor infringement): the Security Officer or an assigned delegate 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 or an assigned delegate 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 PulseData representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security Officer and Privacy Officer or their assigned delegates.
  5. In the case of a threat identified, the Security Officer or an assigned delegate is to form a team to investigate and involve necessary resources, both internal to PulseData and potentially external.

11.2.2 Containment Phase (Technical)

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

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 or an assigned delegate). 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 PulseData 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 PulseData’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 PulseData SIRT:

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

12.1 Applicable Standards

12.1.1 Applicable Standards from the HITRUST Common Security Framework

12.1.2 Applicable Standards from the HIPAA Security Rule

12.2 PulseData 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 PulseData (includes breaches by the organization’s Customers, Partners, or subcontractors). PulseData 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. PulseData 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 PulseData Security Officer or an assigned delegate 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, PulseData, 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 PulseData Customers no later than 4 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 PulseData 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: PulseData 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, PulseData 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: PulseData 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: PulseData 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: PulseData 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 PulseData Platform Customer Responsibilities

  1. The PulseData 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 PulseData of such breach. The Customer shall provide PulseData 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: PulseData Customers are responsible for providing notice to prominent media outlets at the Customer’s discretion.
  3. Notice to Secretary of HHS: PulseData Customers are responsible for providing notice to the Secretary of HHS at the Customer’s discretion.

12.4 Sample Letter to Customers in Case of Breach

[Date]

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

Dear [Name of Customer]:

I am writing to you from PulseData, 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:

Other Optional Considerations:

We will assist you in remedying the situation.

Sincerely,

Dean Panovich CEO - PulseData, Inc. dean@pulsedata.io

13. Disaster Recovery Policy

The PulseData Contingency Plan establishes procedures to recover PulseData following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the PulseData Security Officer and Privacy Officer, or their assigned delegates.

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 PulseData processing requirements during prolonged interruptions to normal operations.
  3. Identify and define the impact of interruptions to PulseData systems.
  4. Assign responsibilities to designated personnel and provide guidance for recovering PulseData during prolonged periods of interruption to normal operations.
  5. Ensure coordination with other PulseData 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 PulseData 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 PulseData 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 PulseData 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.

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

13.1 Applicable Standards

13.1.1 Applicable Standards from the HITRUST Common Security Framework

13.1.2 Applicable Standards from the HIPAA Security Rule

13.2 Line of Succession

The following order of succession to ensure that decision-making authority for the PulseData 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 PulseData 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.

13.3 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 PulseData hosted environment, network devices, and all servers. Members of the team include personnel who are also responsible for the daily operations and maintenance of PulseData. The team leader is the CTO 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.

Members of the Ops and Web Services teams 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

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:

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:

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 PulseData. Based on the assessment of the Event, sometimes according to the PulseData Incident Response Policy, the Contingency Plan may be activated by either the CTO.

The notification sequence is listed below:

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 PulseData 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 PulseData 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 scripts, currently Chef and 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

13.5.3 Reconstitution Phase

This section discusses activities necessary for restoring PulseData 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, PulseData 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, currently Chef and 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 PulseData 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 PulseData Media Disposal Policy.

14. Disposable Media Policy

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

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

14.1 Applicable Standards

14.1.1 Applicable Standards from the HITRUST Common Security Framework

14.1.2 Applicable Standards from the HIPAA Security Rule

14.2 Disposable Media Policy

  1. All removable media is restricted, audited, and is encrypted.
  2. PulseData 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 PulseData’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 PulseData 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 PulseData Customer terminating a contract with PulseData and no longer utilizing PulseData Services, the following actions will be taken depending on the PulseData Services in use. In all cases it is solely the responsibility of the PulseData Customer to maintain the safeguards required of HIPAA once the data is transmitted out of PulseData Systems.

15. IDS Policy

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

15.1 Applicable Standards

15.1.1 Applicable Standards from the HITRUST Common Security Framework

15.1.2 Applicable Standards from the HIPAA Security Rule

15.2 Intrusion Detection Policy

  1. Datadog is used to monitor and correlate log data from different systems on an ongoing basis. Reports generated by Datadog are reviewed by the Security Officer or an assigned delegate on a monthly basis.
  2. Datadog generates alerts to analyze and investigate suspicious activity or suspected violations.
  3. Datadog monitors file system integrity and sends real time alerts when suspicious changes are made to the file system.
  4. Automatic monitoring is done to identify patterns that might signify the lack of availability of certain services and systems (DoS attacks).
  5. PulseData firewalls monitor all incoming traffic to detect potential denial of service attacks. Suspected attack sources are blocked automatically. Additionally, our hosting provider actively monitors its network to detect denial of services attacks.
  6. All new firewall rules and configuration changes are tested before being pushed into production. All firewall and router rules are reviewed every quarter.
  7. PulseData utilizes redundant firewalls on network perimeters.
  8. All incoming traffic is blocked by default with specific rules to allow approved inbound ports and protocols.
  9. Remote access to network resources is possible only via VPN protected by MFA.

16. Vulnerability Scanning Policy

PulseData is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. PulseData utilize Rapid7’s InsightVM on all systems for weekly vulnerability scanning.

16.1 Applicable Standards

16.1.1 Applicable Standards from the HITRUST Common Security Framework

16.1.2 Applicable Standards from the HIPAA Security Rule

16.2 Vulnerability Scanning Policy

  1. Frequency of scanning is as follows:
    1. on a weekly basis;
    2. after every production deployment.
  2. Reviewing reports and findings, as well as any further investigation into discovered vulnerabilities, is the responsibility of the PulseData Security Officer or an assigned delegate. The process for reviewing reports is outlined below:
    1. The Security Officer or an assigned delegate initiates the review of a report by creating an Issue in the PulseData Quality Management System.
    2. The Security Officer, or a PulseData Security Engineer assigned by the Security Officer, is assigned to review the report.
    3. If new vulnerabilities are found during review, the process outlined below is used to test those vulnerabilities. Once those steps are completed, the Issue is then reviewed again.
    4. Once the review is completed, the Security Officer or an assigned delegate approves or rejects the Issue. If the Issue is rejected, it goes back for further review.
    5. If the review is approved, the Security Officer or an assigned delegate then marks the Issue as Done, adding any pertinent notes required.
  3. In the case of new vulnerabilities, the following steps are taken:
    • All new vulnerabilities are verified manually to assure they are repeatable. Those not found to be repeatable are manually tested after the next vulnerability scan, regardless of if the specific vulnerability is discovered again.
    • Vulnerabilities that are repeatable manually are documented and reviewed by the Security Officer and Privacy Officer, or their assigned delegates, to see if they are part of the current risk assessment performed by PulseData.
    • Those that are a part of the current risk assessment are checked for mitigations.
    • Those that are not part of the current risk assessment trigger a new risk assessment, and this process is outlined in detail in the PulseData Risk Assessment Policy.
  4. All vulnerability scanning reports are retained for 6 years by PulseData. Vulnerability report review is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.
  5. Penetration testing is performed regularly as part of the PulseData vulnerability management policy.
    • External penetration testing is performed annually by a third party.
    • Internal penetration testing is performed quarterly. Below is the process used to conduct internal penetration tests.
      1. The Security Officer or an assigned delegate initiates the penetration test by creating an Issue in the PulseData Quality Management System.
      2. The Security Officer, or a PulseData Security Engineer assigned by the Security Officer, is assigned to conduct the penetration test.
      3. Gaps and vulnerabilities identified during penetration testing are reviewed, with plans for correction and/or mitigation, by the PulseData Security Officer or an assigned delegate before the Issue can move to be approved.
      4. Once the testing is completed, the Security Officer or an assigned delegate approves or rejects the Issue. If the Issue is rejected, it goes back for further testing and review.
      5. If the Issue is approved, the Security Officer or an assigned delegate then marks the Issue as Done, adding any pertinent notes required.
    • Penetration tests results are retained for 6 years by PulseData.
    • Internal penetration testing is monitored on an annual basis using the Quality Management System reporting to assess compliance with above policy.
  6. This vulnerability policy is reviewed on a quarterly basis by the Security Officer and Privacy Officer, or their assigned delegates.

17. Data Integrity Policy

PulseData takes data integrity very seriously. As stewards and partners of PulseData 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 PulseData 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. Additional measures are listed for PulseData employee devices.

17.1 Applicable Standards

17.1.1 Applicable Standards from the HITRUST Common Security Framework

17.1.2 Applicable Standards from the HIPAA Security Rule

17.2 Disabling Non-Essential Services

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

17.3 Monitoring Log-in Attempts

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

17.4 Prevention of Malware on PulseData Systems

  1. All PulseData Production Servers must have Datadog and ClamAV installed and running, and must be set to scan the server every 2 hours and at reboot to ensure no malware or malicious payloads are present. Detected malware is quarantined, evaluated, and removed.
  2. Virus scanning software is run on all PulseData systems, both servers and employeee devices, for antivirus, spyware, and malware protection.
    • Systems are scanned daily for malicious binaries in critical system paths.
    • The malware signature database is checked hourly and automatically updated if new signatures are available.
    • Logs of virus scans are maintained according to the requirements outlined in §8.6.
    • PulseData employee devices are also configured with real-time protection, which actively monitors connections and processes for malicious activity or payloads.
  3. All PulseData systems, both servers and employee devices, are to be used only for PulseData business needs.

17.5 Patch Management

  1. 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.
  2. Administrators subscribe to mailing lists to ensure that they are using current versions of all PulseData-managed software on Production Systems.

17.6 Intrusion Detection and Vulnerability Scanning

  1. Production systems are monitored using IDS systems. Suspicious activity is logged and alerts are generated.
  2. Vulnerability scanning of Production Systems must occur on a predetermined, regular basis, no less than annually. Currently it is weekly. Scans are reviewed by the Security Officer or an assigned delegate, with defined steps for risk mitigation, and retained for future reference.

17.7 Production System Security

  1. System, network, and server security is managed and maintained by the Security Officer or an assigned delegate in conjunction with the Dev Ops team.
  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.

17.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 PulseData Customer Production Data is segmented and only accessible to Customers authorized to access data.
  5. All Production Data at rest is stored on encrypted volumes using encryption keys managed by PulseData. Encryption at rest is ensured through the use of automated deployment scripts referenced in the Configuration Management Policy.
  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.

17.9 Transmission Security

  1. All data transmission is encrypted in transit using encryption keys managed by PulseData or the cloud provider. 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. In the case of PulseData-provided APIs, PulseData will provide mechanisms to ensure the person sending or receiving data is authorized to send and receive data.
  6. Ensure the system logs of all transmissions and Production Data access. These logs must be available for audit.

18. Data Retention Policy

Acting as a business associate, PulseData is not directly responsible for health and medical records retention as set forth by each state. Despite this, PulseData has created and implemented the following policy to make it easier for PulseData Customers to support data retention laws, and to comply with HIPAA regulations regarding data disposal.

18.1 State Medical Record Laws

18.2 Data Disposal Policy

18.3 Data Retention Policy

19. Employees Policy

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

19.1 Applicable Standards

19.1.1 Applicable Standards from the HITRUST Common Security Framework

19.1.2 Applicable Standards from the HIPAA Security Rule

19.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.
    • Upon completion of training, workforce members complete a form certifing their training
    • Current PulseData training is completed by the policy officer
    • 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 PulseData Employee Handbook clearly states the responsibilities and acceptable behavior regarding information system usage, including rules for email, Internet, mobile devices, and social media usage.
    • Workforce members are required to sign an agreement stating that they have read and will abide by all terms outlined in the PulseData Employee Handbook, along with all policies and processes described in this document.
    • A Human Resources representative will provide the agreement to new employees during their onboarding process.
  4. PulseData 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 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 PulseData and its Customers and Partners.
  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 VPN software and Secure Access Service Edge (SASE) for all access to production systems with access to ePHI data.
  8. All PulseData workstations will be configured to lock after 15 minutes of inactivity.
  9. Employees may only use PulseData owned or approved workstations for accessing production systems with access to ePHI data.
    • Any workstations used to access production systems must be configured as prescribed in §7.8.
    • Any workstations used to access production systems must have virus protection software installed, configured, and enabled.
    • PulseData may monitor access and activities of all users on workstations and production systems in order to meet auditing policy requirements (§8).
  10. Access to internal PulseData systems can be requested using the procedures outlined in §7.2. All requests for access must be granted by the PulseData Security Officer or an assigned delegate.
  11. Request for modifications of access for any PulseData employee can be made using the procedures outlined in §7.2.
  12. PulseData employees are strictly forbidden from downloading any ePHI to their workstations.
    • Restricting transfers of ePHI is enforced through technical controls as described in §7.13.
    • Employees found to be in violation of this policy will be subject to sanctions as described in §5.3.3.
  13. 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.

19.3 Issue Escalation

PulseData workforce members are to escalate issues using the procedures outlined in the Employee Handbook. Issues that are brought to the Escalation Team are assigned an owner. The membership of the Escalation Team is maintained by the Chief Executive Officer.

Security incidents, particularly those involving ePHI, are handled using the process described in §11.2. If the incident involves a breach of ePHI, the Security Officer or an assigned delegate will manage the incident using the process described in §12.2. Refer to §11.2 for a list of sample items that can trigger PulseData’s incident response procedures; if you are unsure whether the issue is a security incident, contact the Security Officer or their assigned delegate immediately.

It is the duty of that owner to follow the process outlined below:

  1. Create an Issue in the PulseData Quality Management System.
  2. The Issue is investigated, documented, and, when a conclusion or remediation is reached, it is moved to Review.
  3. The Issue is reviewed by another member of the Escalation Team. If the Issue is rejected, it goes back for further evaluation and review.
  4. If the Issue is approved, it is marked as Done, adding any pertinent notes required.
  5. The workforce member that initiated the process is notified of the outcome via email.

20. Approved Tools Policy

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

20.1 List of Approved Tools

21. 3rd Party Policy

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

21.1 Applicable Standards

21.1.1 Applicable Standards from the HITRUST Common Security Framework

21.1.2 Applicable Standards from the HIPAA Security Rule

21.2 Policies to Assure 3rd Parties Support PulseData Compliance

  1. PulseData does not allow 3rd party access to production systems containing ePHI.
  2. All connections and data in transit between the PulseData 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. PulseData 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 PulseData.
    • 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.
    • PulseData utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs.
  5. No PulseData Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
  6. PulseData does not outsource software development.
  7. PulseData maintains and annually reviews a list all current Partners and Subcontractors.
    • The list of current Partners and Subcontractors is maintained by the PulseData Privacy Officer or an assigned delegate.
    • The annual review of Partners and Subcontractors is conducted as a part of the security, compliance, and SLA review referenced below.
  8. PulseData assesses security, compliance, and SLA requirements and considerations with all Partners and Subcontractors. This includes annual assessment of SOC2 reports for all PulseData infrastructure partners.
    • PulseData leverages recurring calendar invites to assure reviews of all 3rd party services are performed annually. These reviews are performed by the PulseData Security Officer and Privacy Officer, or their assigned delegates. The process for reviewing 3rd party services is outlined below:
      1. The Security Officer or an assigned delegate initiates the SLA review by creating an Issue in the PulseData Quality Management System.
      2. The Security Officer, Privacy Officer, or an assigned delegate 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 or an assigned delegate 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, PulseData reviews activity annually to assure partners are in line with SLAs in contracts with PulseData.
  12. SLA review is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.
  13. The 3rd Party Assurance process is reviewed annually and updated to include any necessary changes.
  14. Changes to the 3rd Party Assurance process will also be made on an ad-hoc basis in cases where operational changes require it or if the process is found lacking.
  15. Except for cloud providers, PulseData currently does not have any 3rd party vendors or contractors that have access to ePHI. All cloud providers used are HITRUST and SOC II certified.

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

23. Reporting Illegal or Unethical Behavior

PulseData requires directors, officers and employees to observe high standards of business and personal ethics in the conduct of their duties and responsibilities. As employees and representatives of PulseData, we must practice honesty and integrity in fulfilling our responsibilities and comply with all applicable laws and regulations.

Employees, clients and other interested parties should report promptly to supervisors, managers or other appropriate personnel when they observe illegal and or unethical behavior, and any violations of law, rules or regulations, and when in doubt about the best course of action in a particular situation.

Reports can be directed to: * Chris Kipers, CTO: kipers@pulsedata.io * Dean Panovich, CEO: dean@pulsedata.io

An anonomous report can also be made using this form: https://forms.gle/TLf4yPnYCCCsi9z97

All whistleblower complaints will be taken seriously and addressed promptly, discreetly, and professionally. PulseData does not permit retaliation against employees for good faith reports of potential ethical violations or questionable accounting or auditing matters.

24. HIPAA Mappings to PulseData Controls

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

Administrative Controls HIPAA Rule PulseData Control
Security Management Process - 164.308(a)(1)(i) Risk Management Policy
Assigned Security Responsibility - 164.308(a)(2) Roles Policy
Workforce Security - 164.308(a)(3)(i) Employee Policies
Information Access Management - 164.308(a)(4)(i) System Access Policy
Security Awareness and Training - 164.308(a)(5)(i) Employee Policy
Security Incident Procedures - 164.308(a)(6)(i) IDS Policy
Contingency Plan - 164.308(a)(7)(i) Disaster Recovery Policy
Evaluation - 164.308(a)(8) Auditing Policy
Physical Safeguards HIPAA Rule PulseData Control
Facility Access Controls - 164.310(a)(1) Facility and Disaster Recovery Policies
Workstation Use - 164.310(b) System Access, Approved Tools, and Employee Policies
Workstation Security - 164.310(’c’) System Access, Approved Tools, and Employee Policies
Device and Media Controls - 164.310(d)(1) Disposable Media and Data Management Policies
Technical Safeguards HIPAA Rule PulseData Control
Access Control - 164.312(a)(1) System Access Policy
Audit Controls - 164.312(b) Auditing Policy
Integrity - 164.312(’c’)(1) System Access, Auditing, and IDS Policies
Person or Entity Authentication - 164.312(d) System Access Policy
Transmission Security - 164.312(e)(1) System Access and Data Management Policy
Organizational Requirements HIPAA Rule PulseData Control
Business Associate Contracts or Other Arrangements - 164.314(a)(1)(i) Business Associate Agreements and 3rd Parties Policies
Policies and Procedures and Documentation Requirements HIPAA Rule PulseData Control
Policies and Procedures - 164.316(a) Policy Management Policy
Documentation - 164.316(b)(1)(i) Policy Management Policy
HITECH Act - Security Provisions HIPAA Rule PulseData Control
Notification in the Case of Breach - 13402(a) and (b) Breach Policy
Timelines of Notification - 13402(d)(1) Breach Policy
Content of Notification - 13402(f)(1) Breach Policy

25. Clean Desk Policy

25.1 Overview

PulseData stands committed to the development of secure policies and practices, and in doing so, has implemented this Clean Desk Policy to increase physical security at PulseData locations. This policy ensures that confidential information and sensitive materials are stored away and out of sight when they are not in use or when the workspace is vacant.

This policy sets forth the basic requirements for keeping a clean workspace, where sensitive and confidential information about PulseData employees, clients, vendors, and intellectual property is secured.

The policy shall apply to all PulseData employees, contractors, and affiliates.

25.2 Policy

It is the responsibility of each employee to ensure enforcement with the policies above. Repeated or serious violations of the clean desk policy can result in disciplinary actions in accordance with PulseData’s Employee Handbook.

If you notice that any of your devices or documents have gone missing, or if you believe your workspace has been tampered with in any way, please notify Ash Luna immediately.

26. Mobile Device Management Policy

PulseData’s Mobile Device Management (MDM) policy defines standards, procedures, and restrictions for any and all end users with legitimate business uses connecting mobile devices to the PulseData corporate network, digital resources, and data.

The primary goal of this policy is to protect the integrity of the confidential client and business data that resides within the PulseData technology infrastructure, including internal and external cloud services. This policy intends to prevent this data from being deliberately or inadvertently stored insecurely on a mobile device or carried over an insecure network where it could potentially be accessed by unauthorized resources. A breach of this type may result in loss of information, damage to critical applications, loss of revenue, damage the company’s public image, breach our data privacy requirements, and violate data privacy laws.

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

The mobile device policy applies, but is not limited to, all devices and accompanying media that fit the following classifications:

26.1 Applicable Standards

26.1.1 Applicable Standards from the HITRUST Common Security Framework

26.1.2 Applicable Standards from the HIPAA Security Rule

26.2 Responsibilities

The PulseData Security Officer and their assigned delegates have the overall responsibility for the confidentiality, integrity, and availability of corporate data. All PulseData employees are responsible to act in accordance with company policies and procedures.

26.3 Policy & Appropriate Use

It is the responsibility of any PulseData employee using a mobile device to access corporate resources to ensure that all security protocols normally used in the management of data on conventional storage infrastructure are also applied here. It is imperative that any mobile device that is used to conduct PulseData business be used appropriately, responsibly, and ethically. Failure to do so will result in immediate suspension of that user’s account. Based on this requirement, the following rules must be observed:

26.3.1 Access Control

  1. PulseData reserves the right to refuse, by physical and non-physical means, the ability to connect mobile devices to corporate and corporate-connected infrastructure. PulseData will engage in such action if such equipment is being used in a way that puts the company’s systems, data, users, and clients at risk.
  2. Prior to initial use on the corporate network or related infrastructure, all mobile devices must be approved by PulseData.
  3. End users who wish to connect such devices to non-corporate network infrastructure to gain access to enterprise data must employ, for their devices and related infrastructure, security measures deemed necessary by PulseData. Enterprise data is not to be accessed on any hardware that fails to meet PulseData’s established enterprise PulseData security standards.
  4. All personal mobile devices attempting to connect to the corporate network through the Internet will be inspected by PulseData. Devices that are not approved, are not in compliance with PulseData security policies, or represent any threat to the corporate network or data will not be allowed to connect.

26.3.2 Mobile Device Management (MDM)

  1. PulseData uses the Hexnode mobile device management solution to secure laptop devices and enforce policies remotely. Before connecting a mobile device to corporate resources, the device must have the Hexnode agent installed on it.
  2. Other mobile devices are required to permit the Google MDM software to apply security policies and isolate corporate data before being granted access to corporate resources.
  3. The Hexnode MDM solution enables PulseData to remotely lock, change passwords on, or wipe devices to prevent sensitive data from being compromised.
  4. Any attempt to contravene or bypass the mobile device management implementation will result in immediate disconnection from all corporate resources, and there may be additional consequences in accordance with PulseData’s overarching security policy.

26.3.3 Security

  1. Employees using mobile devices and related software for network and data access will, without exception, use secure data management procedures. All mobile devices must be protected by a strong password; a PIN is not sufficient. All data stored on the device must be encrypted using strong encryption. See PulseData’s password and encryption policy for additional background. Employees agree never to disclose their PINs or passwords to anyone.
  2. All users of mobile devices must employ reasonable physical security measures. End users are expected to secure all such devices against being lost or stolen, whether or not they are actually in use and/or being carried.
  3. Any non-corporate computers used to synchronize or backup data on mobile devices will have installed up-to-date anti-virus and anti-malware software deemed necessary by PulseData.
  4. Passwords and other confidential data, as defined by PulseData, are not to be stored unencrypted on mobile devices.
  5. Any mobile device that is being used to store or access PulseData company data must adhere to the authentication requirements of PulseData. In addition, all hardware security configurations must be pre-approved by PulseData’s Security Officer or an assigned delegate before any enterprise data-carrying device can be connected to the corporate network.
  6. PulseData will manage security policies as well as network, application, and data access centrally using whatever technology solutions it deems suitable. Any attempt to contravene or bypass that security implementation will be deemed an intrusion attempt and will be dealt with in accordance with PulseData’s overarching security policy.
  7. Employees, contractors, and temporary staff accessing PulseData internet resources from a smartphone or tablet will NOT save their user credentials or internet sessions when logging in or accessing company resources of any kind.
  8. Employees, contractors, and temporary staff will follow all enterprise-sanctioned data removal procedures to permanently erase company-specific data from such devices once its use is no longer required.
  9. In the event of a lost or stolen mobile device, the user is required to report the incident to PulseData immediately. The device will be remotely wiped of all data and locked to prevent access by anyone other than PulseData. If the device is recovered, it can be submitted to PulseData for re-provisioning. The remote wipe will destroy all data on the device, whether it is related to company business or personal. The PulseData Remote Wipe Waiver, which ensures that the user understands that personal data may be erased in the rare event of a security breach, must be agreed to before connecting the device to corporate resources.
  10. Usage of a mobile device to capture images, video, or audio of proprietary content or sensitive data, whether native to the device or through third-party applications, is prohibited within the workplace.
  11. Applications that are not necessary to complete PulseData job functions are not to be used within the workplace or in conjunction with corporate data unless approved by PulseData.

26.3.4 Hardware Support

  1. PulseData reserves the right, through policy enforcement and any other means it deems necessary, to limit the ability of end users to transfer data to and from specific resources on the enterprise network.
  2. Users will make no modifications to the hardware or software that change the nature of the device in a significant way (e.g. replacing or overriding the operating system, jail-breaking, rooting) without the express approval of PulseData.
  3. PulseData will support the connection of mobile devices to corporate resources. On personally owned devices, PulseData will not support hardware issues or non-corporate applications.

26.3.5 Organizational Protocol

  1. PulseData can and will establish audit trails, which will be accessed, published, and used without notice. Such trails will be able to track the attachment of an external device to the corporate network, and the resulting reports may be used for investigation of possible breaches and/or misuse. The end user agrees to and accepts that their access and/or connection to PulseData networks may be monitored to record dates, times, duration of access, etc. in order to identify unusual usage patterns or other suspicious activity. The status of the device, including location, IP address, Serial Number, IMEI, may also be monitored. This monitoring is necessary in order to identify accounts/computers that may have been compromised by external parties or users who are not complying with PulseData policies.
  2. The end user agrees to immediately report to their manager and PulseData any incident or suspected incidents of unauthorized data access, data loss, and/or disclosure of company resources, databases, networks, etc.
  3. Every mobile device user will be entitled and expected to attend a training session about this policy. While a mobile device user will not be granted access to corporate resources using a mobile device without accepting the terms and conditions of this policy, employees are entitled to decline signing this policy if they do not understand the policy or are uncomfortable with its contents.

A. Changelog and Review History

A.1 Changelog

Date Change Author Approver
2026-01-13 Incident Response policy updates Ash Luna Chris Kipers
2025-07-16 Data retention policy updates Ash Luna Chris Kipers
2024-04-09 Configuration management policy updates Ash Luna Job Evers
2024-03-21 Updates to reflect Security and Privacy Officer changes Ash Luna Job Evers
2023-10-05 Updates to reflect changes in leadership Ash Luna Job Evers
2023-08-09 Updates to reflect changes in leadership and branding Ash Luna Job Evers
2023-05-11 Updates to reflect changes in security tools Ash Luna Job Evers
2022-06-28 Updates to reflect Officer permission delegation Ash Luna Job Evers
2022-03-28 Spelling/clarity fixes, change from Trello to Jira Ash Luna Job Evers
2022-02-08 Update of 15 and 17 for clarity on security Ash Luna Job Evers
2022-01-14 Clarity fixes and addition of MDM Policy Ash Luna Job Evers
2019-12-20 First Publication Job Evers Ed Lee

A.2 Review History

Date Reviewer
2026-01-13 Ash Luna
2025-01-10 Ash Luna
2024-03-21 Ash Luna
2023-08-09 Ash Luna
2023-05-11 Ash Luna
2022-02-08 Ash Luna
2021-07-20 Job Evers
2020-11-03 Job Evers
2019-12-20 Ed Lee