Cordata# Introduction

Cordata Healthcare Innovations, Inc. (“Cordata”) is a leading cloud-based, web application provider. All software and systems are fully HIPAA compliant and HITRUST certified via ClearDATA. Our suite of software bridges the intersection between individuals, providers, and communities. We provide care coordination solutions that seamlessly connect the highest-risk, most difficult-to-reach populations to treatment and support.

Child Welfare - Improve outcomes for children in foster care with Cordata IDENTITY, a proprietary deterministic matching technology that closes the information gap between healthcare organizations and child welfare agencies.

Community Response - Connect a new ecosystem for recovery with Cordata Community, the only comprehensive platform that empowers deflection and diversion programs focused on addiction and mental health.

Healthcare Navigation - Cordata Healthcare provides core technology infrastructure to expand patient support, streamline access to care, and enhance the healing process for individuals fighting chronic, complex diseases.

Survivors of Interpersonal Violence - Cordata provides an online hub for managing forensic medical reporting, mandatory reports, cross-agency referrals, survivor workflows and detailed data analysis. Collaborating towards survivors’ care with other healthcare, law enforcement, advocacy and public health professionals, all in one place.

Cordata is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its customers. The following documents address core policies used by Cordata to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for Cordata customers.

Cordata Organizational Concepts

The infrastructure environment is hosted on AWS (administered by ClearDATA ). The network components, data, source code and supporting services are contained within the ClearDATA infrastructure, and are managed and maintained by ClearDATA. Cordata does not have physical access to the network components. The Cordata environment consists of AWS firewalls, Linux Servers, PostgreSQL servers, Linux Ubuntu monitoring servers, AWS ECS containers, RDS databases, and developer tools servers running on Ubuntu Linux.

Within the Cordata Platform, and within the ClearDATA infrastructure, all data transmission is encrypted and all drives and storage are encrypted, data at rest and in transit is also encrypted; this applies to all servers - those hosting Docker containers, databases, APIs, log servers, etc. Cordata 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.

Data is segmented in such a way that each customer is only able to see that customer’s data at a database level security control. Cordata has implemented strict logical access controls so that only authorized personnel are given access to the internal management servers. The environment is configured so that data is transmitted from the load balancers to the application servers over an SSL encrypted session.

The App server is externally facing and accessible via the Internet. The database servers, where the ePHI resides, are located on the internal Cordata network on the ClearDATA AWS infrastructure and can only be accessed directly over a VPN connection. The access to the internal database is restricted to a limited number of personnel and strictly controlled to only those personnel with a business justified reason. Remote access to the internal servers is not accessible except through the load balancers.

Version Control

Policies are checked into Github for source control.

Policies are reviewed annually and updated accordingly.

3rd Party Policy

Cordata makes every effort to assure all 3rd party organizations are compliant and do not compromise the integrity, security, and privacy of Cordata or Cordata customer data. 3rd Parties include customers, partners, subcontractors, and contracted developers.

Applicable Standards from the HITRUST Common Security Framework

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

Applicable Standards from the HIPAA Security Rule

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

Policies to Assure 3rd Parties Support Cordata Compliance

1. The following steps are required before 3rd parties are granted access to any Cordata systems:
   • Due diligence with the 3rd party;
   • Controls implemented to maintain compliance;
   • Written agreements, with appropriate security requirements, are executed.
2. All connections and data in transit between the Cordata Platform and 3rd parties are encrypted end to end.
3. Access granted to external parties is limited to the minimum necessary and granted only for the duration required.
4. A standard business associate agreement with customers and partners is defined and includes the required security controls in accordance with the organization’s security policies. Additionally, responsibility is assigned in these agreements.
5. Cordata has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management.
   • Cordata utilizes monitoring tools to regularly evaluate subcontractors against relevant SLAs.
6. Third parties are unable to make changes to any Cordata infrastructure without explicit permission from Cordata. Additionally, no Cordata Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
7. Whenever outsourced development is utilized by Cordata, all changes to production systems will be approved and implemented by Cordata workforce members only. All outsourced development requires a formal contract with Cordata.
8. Cordata maintains and annually reviews a list all current partners and subcontractors.
9. Cordata assesses security requirements and compliance considerations with all partners and subcontracts.
10. Regular review is conducted as required by SLAs to assure security and compliance. These reviews include reports, audit trails, security events, operational issues, failures and disruptions, and identified issues are investigated and resolved in a reasonable and timely manner.
11. Any changes to Partner and Subcontractor services and systems are reviewed before implementation.
12. For all partners, Cordata reviews activity annually to assure partners are in line with SLAs in contracts with Cordata.

Cordata#Administrative Safeguards (see 164.308)

Taken directly from the wording of the Security Rule, administrative safeguards are administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information.

There aren’t specific security settings in this section, and the most important area covered is the risk assessment. The risk assessment is a fundamental process for any organization that wants to become compliant.

Security Management Process - 164.308(a)(1)(i)

Cordata has a risk management policy that defines the risk analysis and risk management process. This policy is operationalized with processes to conduct regularly risk assessments. Cordata uses NIST800-30 and 800-26 for performing risk analysis. Our policy begins with an inventory of all Cordata systems, mapping of where ePHI is processed, transmitted, or stored, identification of threats, risks, and likelihood, and the mitigation of risks. Policies address risk inherent within the environment and mitigating the risk to an acceptable and reasonable level.

Cordata has a Sanction Policy that has sanctions for employees not adhering to certain policies, and for specifically violating HIPAA rules.

Policies and procedures address the requirements of monitoring and logging system level events and actions taken by individuals within the environment. All requests into and out of the Cordata network are logged, as well as all system events. Cordata, has implemented multiple logging and monitoring solutions to track events within their environment and to monitor for certain types of behavior. Log data is regularly reviewed. Additionally, proactive alerts are enabled and triggered based on certain suspicious activity.

Assigned Security Responsibility - 164.308(a)(2)

Cordata has formally assigned and documented its security officer. Our security officer is Jon Stonis. He can be reached by email at jon.stonis@cordatahealth.com.

Workforce Security - 164.308(a)(3)(i)

Cordata has policies in place that require workforce members requesting access to ePHI to submit an authorization form that is signed and acknowledges their responsibility of safeguarding ePHI. The form must also be approved by the Security Officer. Once signed and approved, then the individual will be provisioned access to systems deemed business necessary. All Access to ePHI is based on minimum necessary requirements and least privilege.

Cordata policies define the immediate removal of access once an employee has been terminated, with the Security Officer responsible for terminating the access. Once HR initiates the termination process the termination checklist is referenced to ensure necessary actions are taken to remove systems and facilities access.

Information Access Management - 164.308(a)(4)(i)

Cordata does not perform the functions of a Healthcare Clearinghouse so aspects of this section are not applicable.

The security officer determines the roles necessary for each system and application. When access is needed to Cordata infrastructure, a request and acknowledgement form is signed and then approved by the Security Officer.

Cordata has a formal process for requesting additional access to ePHI, and again Cordata customers must approve all requests concerning ePHI.

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

Cordata has a Security Awareness training policy in place that requires new employees and current employees to conduct training upon hire and annually thereafter. Minimum training is done annually, with regularly informal security and compliance training done periodically.

Cordata proactively assesses and tests for malicious software within their environment, both infrastructure and workstations.

Cordata is monitoring and logging successful and unsuccessful log-in attempts to the servers within its environment and policies are in place requiring audit logging, which includes login attempts.

Password configurations are set to require that passwords are a minimum of 8 character length, 90 day password expiration, account lockout after 5 invalid attempts, password history of last 4 passwords remembered, and account lockout after 60 minutes of inactivity.

Security Incident Procedures - 164.308(a)(6)(i)

Cordata has implemented a formal incident response plan (IRP), which discusses the procedures for identifying, responding to, and escalating suspected and confirmed security breaches. Cordata has implemented an incident response team for the purposes of dealing with potential security breaches. The IRP has specific types of incidents to look out for, as well as some common types of incidents that are monitored for within the environment.

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

Cordata has inherited the Backup and Recovery Policy from their platform-as-a-service partner, ClearDATA that defines the data backup strategy including: Schedule, associated responsibilities, and any risk-assessed exclusion to the backup schedule.

Cordata has a formal Disaster Recovery plan to ensure the efficient recovery of critical business data and systems in the event of a disaster. The Disaster Recovery (DR) plan includes specific technical procedures necessary to reinstate the infrastructure and data to allow critical business functions to continue business operations after a disaster has occurred. Additionally, the Cordata DR plan includes requirements for performing annual testing of the DR plan to ensure its effectiveness.

Cordata has a DR plan, or a a Business Continuity Plan (BCP), to aid in the efficient recovery of critical business functions after a disaster has been declared. The BCP goes into effect after facility outage of 24 hours. The BCP identifies critical information necessary to resume business operations such as: Hardware/software requirements, recovery time objectives, forms, employee/vendor contact lists, alternate working procedures, emergency access procedures, and a data and application criticality analysis. The BCP includes an Emergency Mode Operations Plan that addresses the access and protection of ePHI while operating in emergency mode.

The DR and BPC plans are reviewed and tested annually or whenever significant infrastructure changes occur.

Cordata has performed an applications and data criticality analysis that details what systems and application need to be recovered and their specific order in the recovery process.

Evaluation - 164.308(a)(8)

Cordata has formal internal policies and procedures for conducting periodic technical and non-technical testing. These define procedures for performing quarterly internal and external vulnerability scanning, as well as annual penetration testing. Vulnerability scanning is performed with any major changes in infrastructure. Additionally, non-technical evaluations occur on an annual basis to ensure that the security posture of Cordata is at the defined level, approved by management, and communicated down to Cordata employees.

Business Associate Contracts and Other Arrangement - 164.308(b)(1)

Cordata has a formalized template, as well as policies in place regarding Business Associate Agreements and written contracts. Cordata has engaged a third party provider for hosting responsibilities and has written attestations of safeguarding its data. Additionally, Cordata performs due diligence in assuring that third party providers they select go through their due diligence process and provide services consistent with the Cordata security and compliance posture.

Approved Tools Policy

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

List of Approved Tools

• Bitbucket

• Github

• DockerHub

• Docker

• AWS HIPAA Compliant Tools

• Shortcut

• Hubspot

• Codeship

• Sendgrid/Twilio

• PatientBond

• ProtonMail

• Helpscout

• Rosetta

• RingCentral

• SignNow (esign)

• TractorScope

• Userback

• Mailtrap

• Keepass

• Microsoft Suite

• DBeaver

• Navicat

• Insomnia

• Postman

• Browsers Chrome, Firefox, Edge, Brave, Safari, Vivaldi

Auditing Policy

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

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

This policy applies to all Cordata systems that store, transmit, or process ePHI.

Applicable Standards from the HITRUST Common Security Framework

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

Applicable Standards from the HIPAA Security Rule

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

Auditing Policies

1. Responsibility for auditing information system access and activity is assigned to Cordata’s Security Officer. The Security Officer shall:
   • Assign the task of generating reports for audit activities to the workforce member responsible for the application, system, or network;
   • Assign the task of reviewing the audit reports to the workforce member responsible for the application, system, or network, the Privacy Officer, or any other individual determined to be appropriate for the task;
   • Organize and provide oversight to a team structure charged with audit compliance activities (e.g., parameters, frequency, sample sizes, report formats, evaluation, follow-up, etc.).
   • All connections to Cordata are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
2. Cordata’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.
   • Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
3. Cordata 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 Cordata.
4. Cordata utilizes ClearDATA and their HITRUST certified systems to scan all systems for malicious and unauthorized software. Alerts from these scans are either communicated directly to Cordata or are contained within the ClearDATA dashboard depending upon the severity of the finding. Vulnerabilites are remediated in a timely manner.
5. Cordata leverages process monitoring tools throughout its environment.
6. Cordata 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 Cordata Platform or may be specific to a customer, partner, business associate, platform add-on or application (See Listing of Potential Trigger Events below).
7. Logs are reviewed monthly by the Security Officer and Security Team.
8. Cordata’s Security Officer and Privacy Officer are authorized to select and use auditing tools that are designed to detect network vulnerabilities and intrusions. Such tools are explicitly prohibited by others, including customers and partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to:
   • Scanning tools and devices;
   • Password cracking utilities;
   • Network “sniffers.”
   • Passive and active intrusion detection systems.
9. 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 Cordata 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.
10. 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.
11. 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 patches are applied within 90 days after testing.

Audit Requests

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

Review and Reporting of Audit Findings

1. Audit information that is routinely gathered must be reviewed in a timely manner, currently monthly, by the responsible workforce member(s).
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. Cordata’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 Cordata’s performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable e PHI shall not be included in the reports).
5. Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.

Auditing Customer and Partner Activity

1. Periodic monitoring of customer and partner activity shall be carried out to ensure that access and activity is appropriate for privileges granted and necessary to the arrangement between Cordata and the 3rd party. Cordata will make every effort to assure Customers and Partners do not gain access to data outside of their own Environments.
2. If it is determined that the customer or partner has exceeded the scope of access privileges, Cordata’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, Cordata must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.

Audit Log Security Controls and Backup

1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy.
2. All audit logs are encrypted in transit and at rest to control access to the content of the logs. For PaaS customers, it is the responsibility of the customer to encrypt log data before it is sent to Cordata Logging Service.
3. Audit logs shall be stored on a separate system to minimize the impact auditing may have on the privacy system and to prevent access to audit trails by those with system administrator privileges. This is done to apply the security principle of “separation of duties” to protect audit trails from hackers.

Workforce Training, Education, Awareness and Responsibilities

1. Cordata workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI. Cordata’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. Cordata 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. Cordata customers are provided with necessary information to understand Cordata auditing capabilities, as PaaS customers of ClearDATA, Cordata is able to choose the level of logging and auditing that ClearDATA will implement on Cordata’s behalf.

External Audits of Information Access and Activity

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

Retention of Audit Data

1. Audit logs shall be maintained based on organizational needs. There is no standard or law addressing the retention of audit log/trail information. Retention of this information shall be based on: A. Organizational history and experience. B. Available storage space.
2. Reports summarizing audit activities shall be retained for a period of six years.
3. Log data is currently retained and readily accessible for a 1-month period.
4. For Paas customers, all audit is retained indefinitely whereas Application Log Data is retained for all clients for 7-days.

Potential Trigger Events

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

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

Applicable Standards from the HITRUST Common Security Framework

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

Applicable Standards from the HIPAA Security Rule

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

Cordata 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 Cordata (includes breaches by the organization’s customers, partners, or subcontractors). Cordata 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. Cordata 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 Cordata Security Officer shall name an individual to act as the investigator of the breach (e.g., privacy officer, security officer, risk manager, etc.). The investigator shall be responsible for the management of the breach investigation, completion of a risk assessment, and coordinating with others in the organization as appropriate (e.g., administration, security incident response team, human resources, risk management, public relations, legal counsel, etc.) The investigator shall be the key facilitator for all breach notification processes to the appropriate entities (e.g., HHS, media, law enforcement officials, etc.). All documentation related to the breach investigation, including the risk assessment, shall be retained for a minimum of six years. A template breach log is located here.
3. Risk Assessment: For an acquisition, access, use or disclosure of ePHI to constitute a breach, it must constitute a violation of the HIPAA Privacy Rule. A use or disclosure of ePHI that is incident to an otherwise permissible use or disclosure and occurs despite reasonable safeguards and proper minimum necessary procedures would not be a violation of the Privacy Rule and would not qualify as a potential breach. To determine if an impermissible use or disclosure of ePHI constitutes a breach and requires further notification, the organization will need to perform a risk assessment to determine if there is significant risk of harm to the individual as a result of the impermissible use or disclosure. The organization shall document the risk assessment as part of the investigation in the incident report form noting the outcome of the risk assessment process. The organization has the burden of proof for demonstrating that all notifications to appropriate Customers or that the use or disclosure did not constitute a breach. Based on the outcome of the risk assessment, the organization will determine the need to move forward with breach notification. The risk assessment and the supporting documentation shall be fact specific and address:
   • Consideration of who impermissibly used or to whom the information was impermissibly disclosed;
   • The type and amount of ePHI involved;
   • The cause of the breach, and the entity responsible for the breach, either customer, Cordata, 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 Cordata 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 Cordata 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: Cordata 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, Cordata 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: Cordata 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: Cordata 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: Cordata 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.

Cordata Customer Responsibilities

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

Sample Letter to Customers in Case of Breach

[Date]

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

Dear [Name of Customer]:

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

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

Other Optional Considerations:

• Recommendations to assist customer in remedying the breach.

We will assist you in remedying the situation.

Sincerely,

Gary Winzenread CEO - Cordata gary.winzenread@cordatahealth.com xxx-xxx-xxxx

Configuration Management Policy

Server and network configuration management is managed through Amazon Web Services (AWS). Security safeguards are managed by ClearDATA. These safeguards adhere to all established and accepted policies within the guidelines of their certifications.

Applicable Standards from the HITRUST Common Security Framework

• 06 - Configuration Management

Applicable Standards from the HIPAA Security Rule

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

Configuration Management

1. No systems are deployed into Cordata environments without approval of the Cordata Security Officer.
2. All changes to production systems, network devices, and firewalls are approved by the Cordata Security Officer before they are implemented. Additionally, all changes are tested before they are implemented in production.
3. Clocks are synchronized across all systems using AWS standard features. Cordata employees do not have the capability to change the time on production-class application servers
4. Customer-facing software and systems are tested using standard unit tests and end to end tests
5. All committed code is reviewed using pull requests (on Github) to assure software code quality and proactively detect potential security issues in development.
6. Cordata utilizes development and staging environments that mirror production to assure proper function.

Change Management Policy

Overview

Change management generally includes the following steps: * Planning * Evaluation * Review * Approval * Communication * Implementation (Deployment) * Documentation * Post-change review NOTE: This document is subject is change. Change management / audit of changes is found in github where the source of policy.cordatahealth.com is located. This document is available live by accessing the aforementioned url.

Scope

This policy applies to all changes to architecture, tools, IT services and software development provided by Cordata.

Security

While our overall security strategy is outlined in other documents located on policy.cordatahealth.com, we find it necessary to include some general information about this topic in the Change Management policy. The following is provided by both AWS and ClearDATA.

• FedRAMP.
• Data encryption in transit.
• Data encryption at rest.
• Denial of services prevention.
• Intrusion detection.
• Regular vulnerability scans.
• Fully audited, SOC1, SOC2 and HITRUST audits.

Policy

All changes to IT services must follow a structured process to ensure that appropriate planning and execution occur. There are three types of changes we will cover. * Standard changes. Minimal changes required to support day-to-day operations - e.g. divisional configuration in setting up a client. * Normal Change (typically applies to our quarterly deployments). * Emergency Changes (hotfixes and/or production fixes) - A change that must be introduced as soon as possible due to likely negative service impacts. There may be fewer people involved in the change management process review, and the change assessment may involve fewer steps due to the urgent nature of the issue.

Data Change Audit

All data changes to our system are 100% audited. We maintain a before / after audit of all database tables contained within our system to ensure that all auditing / change control is maintained. Regular backups of all data is maintained by ClearDATA according to their documented data retention policies.

Policy for Standard, Normal and Emergency Changes

Standard production changes.

• Any changes required are escalated through our ticketing system (currently Hubspot) and routed through to an authorized Database Engineer. This individual will review the changes and make inquiries into additional information where necessary.
• Changes are made only where necessary and according to industry acceptable data change standards (e.g. database transactions).
  1. Normal changes
• Covered by Software Development (below)
• Covered by Software Release Process (below)
  1. Emergency Changes
• Typically arise due to a customer discovered issue.
  
• Escalated to the senior manager of Product Engineering using our ticketing system (Hubspot).
• The Product Engineering senior manager collaborates with Product Management to prioritize the changes and to determine whether this meets the definition of an emergency change required (see above for emergency change definition).
• All code changes go through a peer code review process before being released.
• Code is deployed to our staging environment where it is tested by QA and Client Services. This may occur quickly depending on the nature of the emergency.
• The Product Engineering senior manager approves the emergency deployment.
• Authorized deployer initiates the AWS ECS CLI command to commence with the deployment.
• All deploys are managed without any system downtime using docker (Amazon AWS ECS).
• Production system is then validated by QA and Client Services to ensure appropriate deployment occurred.
• Deployment information is logged / audited and available via a real-time report.

Software Development - Change Management Process

All software development lifecycle changes are managed using shortcut.com as our Agile / Process Engineering tool. Product Management outlines the priorities for a given release (e.g. 8.4) and has them approved by the Senior Management Team. Product Management and the Sr. Manager of Product Engineering meet to break the priorities into agile “stories”. These stories are then broken into sprints (2 week increments). A developer begins an approved story within a 2-week sprint time period. During this time, this person (the developer) will checkout code from GitHub (our approved organizational code repository). Any work done during this timeframe is on the local device (e.g. desktop computer). Upon code completion, a developer submits a pull request. Two things must occur at this time. 1) A mandatory peer code review is completed and 2) an authorized branch admin will commit the code once the code review is completed. These constraints are configured and enforced utilizing GitHub permissions according to job responsibility. This ensures that no code makes it into our pipeline without being examined first. All changes are 100% audited through our source control management tool (GitHub). All changes must be tested by the Cordata QA department. A Shortcut card is moved into the QA team’s lane where they pick up the work and complete testing. If bugs are found, a card is introduced and someone from the development team must fix it before the item is marked as done. Prior to the release into staging / production, the team performs Regression Testing on the entire suite of applications to ensure a quality release to our customers. Once a release cycle is completed, the release branch is then merged into the mainline branch and released into staging and then production according to the normal process.

Software Release Process (Deployments)

All software utilized by Cordata’s staging or production systems is located within AWS and utilizes ClearDATA’s infrastructure for security. We are a cloud-based, web application provider. All software and systems are fully HIPAA compliant and HITRUST certified via ClearDATA. The normal release process works as follows: Only a few authorized individuals can access the AWS account utilizing the aws CLI for deployment. These individuals are approved and granted access by means of the Sr. Manager of Product Engineering. Upon full approval by QA and Product Management, an approved individual will execute the necessary steps to upgrade our server environment. We use Amazon ECS / Docker Containers which allows us to do real-time upgrades without any downtime to the system. All deployment changes are audited. Each deployment requires an explanation - the deployment activity is then logged into a database and made available in report form for audit purposes.

Change Management Roles

Change Advisory Board (CAB)

Change Advisory Board is comprised of the Release Manager, Senior Manager of Product Engineering and the Senior Manager of Product Management. For normal and emergency changes, discretion is delegated to the Sr. Manager of Product Engineering. The members of the Change Advisory Board provide a due diligence readiness assessment and advice about timing for any Request for Change (RFC) that are referred to it for review. This assessment should ensure that all changes to the IT environment are carefully considered to minimize the impact on users and existing services. CAB members are responsible for: * thoroughly reviewing all change requests / prioritizations * raising any potential concerns about the impact or timing of those requests\ * ensuring the changes requested * have undergone proper planning and testing * are planned to ensure the lowest possible risk to services are coordinated so changes do not impact each other * are coordinated with the campus calendar to avoid times of high impact for affected services * providing advice regarding any additional measures that should be considered prior to the change.

Release Manager

Change Management responsibilities for first level managers include the following tasks: * Review and approve timing and feasibility of RFCs * Review and approve RFCs when authorized by CAB * Engage IT Communications manager to initiate communication with users * Ensure staff availability to successfully complete the RFC

Requestor

Change Management responsibilities for the Requestor include the following tasks: * Ensure that additional resources are available in case of problems * Prepare the request for change (RFC) and submit to the appropriate Change Authority. * Incorporate feedback from the Change Authority into the RFC * Document the outcome of the change

ClearDATA#Cordata HIPAA Compliance

Cordata values open and honest communication which enables transparency to all interestes parties with regard to our approach to complying with HIPAA and other regulations. This site is dedicated to providing you with the details behind our policies and procedures. Below is a high level summary of key architecture and guiding principles that maximize our security posture.

See the finer grain details of how we comply with HIPAA below. These are mapped to specific HIPAA rules. Controls marked with a (Req) are Required. Controls marked with an (A) are Addressable. In our environment, controls outlined below are implemented on all infrastructure that processes, stores, transmits or can otherwise gain access to ePHI (electronic protected health information). If have questions, please email us.

Cordata HIPAA Business Associate Agreement (“BAA”)

A. PURPOSE OF AGREEMENT

Company and Agent have entered into an arrangement whereby Agent provides software services for or in conjunction with Company on behalf of certain Healthcare facilities and other healthcare providers with which Company has entered into written service agreements to provide various software and software support services. Each such facility or healthcare provider with which Company does business is a “Covered Entity” for purposes of the HIPAA (Health Insurance Portability & Accountability Act) Privacy and Security Standards. In its relationship to these Covered Entities, Company is a “Business Associate,” as that term is defined in the federal HIPAA Privacy Regulations, and Agent acts as Company’s agent or sub-contractor in carrying out certain Business Associate functions or activities for or on behalf of the Healthcare Entity. In the course of providing its services, Agent may, upon occasion, use or disclose Protected Health Information (“PHI”), provided by Company, which originated from the physician practices. This Agreement is intended to satisfy a specific requirement of the HIPAA Privacy Regulations by setting forth Agent’s responsibilities and obligations with respect to its obligations to safeguard the confidentiality and security of the PHI that it uses or accesses from Company in the performance of such services.

B. DEFINITIONS.

1.“Breach” (with respect to Unsecured Health Information) shall have the meaning set forth in 45 C.F.R. § 164.402, as amended from time to time, and currently means the acquisition, access, use or disclosure of protected health information in a manner not permitted under the Privacy or Security Standards and which compromises the security or privacy of the Health Information.

2.“Business Associate” means an individual or entity that performs a function or activity on behalf of, or provides a service to a Covered Entity (as defined herein), that involves the collection, creation, use or disclosure of Health Information.

3.“Covered Entity” means a health plan, health care clearinghouse or a health care provider who transmits any health information in electronic form in connection with a transaction covered under the HIPAA Privacy Regulations.

4.“De-Identify” or “De-Identification” means Health Information that does not identify an individual and with respect to which there is no reasonable basis to believe that such information can be used to identify an individual.

5.“Designated Record Set” means a group of records maintained by or for a Covered Entity comprising the enrollment, payment, claims adjudication, and case or medical management record systems maintained by or for a Covered Entity or Business Associate of the Covered Entity or used, in whole or in part, by or for the Covered Entity to make decisions about individuals. For purposes of this Section, the term “record” includes any item, collection, or grouping of information that contains Personal and Health Information and is maintained, collected, used, or disseminated by or for a Covered Entity or the Company.

6.“Electronic Health Information” means Health Information that is transmitted or maintained in electronic media.

7.“Electronic Media” means: (i) Electronic storage media including memory devices in computers (hard drives) and any removable/transportable d digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card; or (ii) Transmission media used to exchange information already in electronic storage media. Transmission media include, for example, the internet (wide-open), extranet (using internet technology to link a business with information accessible only to collaborating parties), leased lines, dial-up lines, private networks, and the physical movement of removable/transportable electronic storage media. Certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media, because the information being exchanged did not exist in electronic form before the transmission.

8.“Health Information” means “Protected Health Information” as this term is defined under the HIPAA Privacy Regulations, and includes any information in possession of or derived from a physician or other provider of health care or a health care service plan regarding an individual’s medical history, mental or physical condition or treatment.

9.“Limited Data Set” means Health Information that excludes the following direct identifiers of the individuals or of relatives, employers or household members of the individual: (i) names; (ii) postal address information, other than town or city, State and zip code; (iii) telephone numbers; (iv) fax numbers; (v) electronic mail addresses; (vi) social security numbers; (vii) medical record numbers; (viii) health plan beneficiary numbers; (ix) account numbers; (x) certificate/license numbers; (xi) vehicle identifiers and serial numbers, including license plate numbers; (xii) device identifiers and serial numbers; (xii) device identifiers and serial numbers; (xiii) Web Universal Resource Locators (URLs); (xiv) Internet Protocol (IP) address numbers; (xv) biometric identifiers, including finger and voice prints; and (xvi) full face photographic images and any comparable images.

10.“Personal and Health Information” means any individually identifiable information gathered in connection with an insurance transaction from which judgments can be made about an individual’s character, habits, avocations, finances, occupation, general reputation, credit, health or any other personal characteristics. Individually identifiable information includes the individual’s name, address, electronic mail address, telephone number, social security number and other information, alone or in combination with other publicly available information, which reveals the individual’s identity. Personal information includes the individual’s nonpublic personal financial information.

1. “Security Standards” shall mean the Security Standards for the Protection of Electronic Health Information, 45 CFR Part 160 and Part 164, Subparts A and C.

2. “Unsecured Health Information” shall mean unsecured PHI as set forth in 45 CFR § 164.402, as amended from time to time, and currently means Health Information that has not been rendered unusable, unreadable or indecipherable to unauthorized individuals through the use of a technology or methodology specified by the Secretary of Health and Human Services.

C. PRIVACY OF PERSONAL AND HEALTH INFORMATION.

1. Permitted Uses and Disclosures. Agent is permitted or required to use or disclose Health Information it collects, creates for or receives from the Company only as follows: a) Functions and Activities on the Company’s Behalf. Agent is permitted to use and disclose the minimum necessary Health Information it collects, creates for or receives from the Company in order to provide services to the Company, any Covered Entity for which the Company and/or Agent are Business Associates, or another Business Associate of such a Covered Entity. b) Agent’s Operations. Agent may use and disclose the minimum necessary Health Information or Personal and Health Information it collects, creates for or receives from the Company as necessary in order to perform Agent’s proper management and administration, or to carry out Agent’s legal responsibilities. If Agent discloses such Health Information to an agent, a subcontractor or other third party, then Agent shall obtain reasonable assurances from the agent, subcontractor or other third party to which Agent discloses such Health Information that agent, subcontractor or other third party shall: (i) hold such Health Information in confidence and use or further disclose it only for the purposes for which Agent disclosed it to the agent, subcontractor or other third party or as required by law; and (ii) notify Agent (who shall in turn promptly notify the Company) of any instances of which the agent, subcontractor or other third party becomes aware that the confidentiality of such Health Information w was breached.

2. Prohibition on Unauthorized Use or Disclosure. Agent shall neither use nor disclose Health Information it collects, creates for or receives from the Company, except as permitted or required by this Agreement, or as permitted or required by law.

3. Compliance with the Company’s Confidentiality/Privacy Policies. Agent shall comply with the Company’s Confidentiality, Privacy, and Security Policies that it, from time to time, may adopt as a Business Associate.

4. De-Identification of Information/Creation of Limited Data Set. Agent shall not De-Identify Health Information it creates or receives for or from the Company, and shall not use or disclose such de-identified information, unless such de-identification is expressly permitted under the terms and conditions of this Agreement for services to be provided by Agent to the Company related to the Company’s activities for purposes of “treatment,” “payment” or “health care operations,” as those terms are defined under the HIPAA Privacy Regulations. Agent further agrees that it will not create a Limited Data Set using Health Information it creates or receives for or from the Company, nor use or disclose such Limited Data Set unless: (i) such creation, use or disclosure is expressly permitted under the terms and conditions of this Agreement; and (ii) such creation, use or disclosure is for services provided by Agent that relate to the Company’s activities for purposes of “payment” or “health care operations,” as those terms are defined under the HIPAA Privacy Regulations.

5. Information Safeguards. Agent shall develop, implement, maintain and use appropriate administrative, technical and physical safeguards, in compliance with applicable state and federal laws, to preserve the confidentiality of and to prevent unauthorized disclosures of Health Information collected, created or received for or from the Company. Agent shall document and keep such safeguards current and, upon the Company’s reasonable request, shall provide the Company with a copy of policies and procedures related to such safeguards.

6. Minimum Necessary. In all cases, Agent shall only use or disclose the “Minimum Necessary” amount of Health Information required for it to perform the services detailed in its Agreement with Company. “Minimum Necessary” shall have the meaning set forth for such term in the Privacy Regulations.

D. PERSONAL AND HEALTH INFORMATION ACCESS, AMENDMENT AND DISCLOSURES.

1. Access. Agent shall, upon the Company’s reasonable request permit and at the Company’s direction, within ten (10) business days of receipt of request, an individual (or the individual’s personal representative) to inspect and obtain copies of any Health Information about the individual which Agent collected, created or received for or from the Company and that is in Agent’s custody or control.

2. Amendment. Agent shall, upon receipt of notice from the Company and at the Company’s direction, promptly amend or permit the Company access to amend any portion of an individual’s Health Information which Agent collected, created or received for or from the Company and that is in Agent’s custody or control.

3. Disclosures. Agent shall document each disclosure it makes of an individual’s Health Information to a third party. Moreover, for purposes of this Section, “disclosure” includes: 1) any legal disclosure; 2) any illegal, inadvertent, wrongful, or negligent disclosure; and 3) any instance in which access was provided to an unauthorized third party to an individual’s Health Information. For the purposes of this Agreement, “legal disclosure” includes, but is not limited, any disclosures to law enforcement or other governmental authority pursuant to law and in response to a facially valid administrative or judicial order, such as a search warrant or subpoena.

4. Disclosure Reporting. a) Legal. On the last day of each month, Agents shall forward to the Company a report of such disclosures, as required by 45 CFR §164.528; however, this requirement shall not apply If Agent has not made any such disclosures during the month. Such report shall include the applicable individual’s name, the person to whom the Health Information was disclosed, what was disclosed, why the information was disclosed, and the date of such disclosure. b) Illegal, Inadvertent or Wrongful Disclosure. Agent shall report to the Company any use or disclosure of Health Information not permitted by this Agreement or that would be in violation of the Privacy Regulations if made by Company. Business Associate shall make the report to the Company not more than twenty-four (24) hours after Agent learns of such non-permitted use or disclosure. Agent shall report such disclosure in accordance with Section D of this Agreement, even if such disclosure may not fit the definition of “Breach.” c) Termination of Agreement. Upon termination of this Agreement, Agent shall provide to the Company one final report of any and all disclosures made of all individuals’ Health Information.

5. Inspection of Books and Records. Agent shall make its internal practices, books and records, relating to its use and disclosure of the Personal and Health Information it collects, creates or receives for or from the Company, available to the U.S. Department of Health and Human Services to determine the Company’s compliance, as a Business Associate, with the provisions of the HIPAA Privacy Regulations, whichever is applicable.

6. Designated Record Set. Agent agrees that all Health Information received by or created for the Company shall be included in an individual’s Designated Record Set. Agent shall maintain such Designated Record Set with respect to services provided to an individual under this Agreement, and shall allow such individual to access the Designated Record Set as provided in the HIPAA Privacy Regulations.

E. BREACH.

1. Generally. In furtherance of Agent’s obligation under Sections D.3. and D.4 above, Agent shall report to the Company any Breach of Unsecured Health Information and any other use or disclosure of Health Information not permitted by this Agreement. Agent’s report shall contain, at a minimum, the following information, to the extent available at the time initial notice under this Section E.1 is provided, or promptly thereafter as such information becomes available: a) The nature of the Breach or non-permitted use or disclosure; b) The Health Information used or disclosed; c) The name of the person who made the Breach or non-permitted use or received the non-permitted disclosure; d) The corrective actions Agent took or shall take to prevent further Breaches or non-permitted uses or disclosures; e) The actions Agent took or shall take to mitigate any deleterious effect of the Breach or non-permitted use or disclosure; and f) Any such other information, including a written report, as the Company may reasonably request. Any report required under this Section E.1. shall be made within five (5) days of Agent becoming aware of any such Breach or other wrongful use or disclosure.

2. Termination of Agreement. This Agreement shall terminate automatically in the event that Agent ceases performing services for or on behalf of Company or in the event that Agent otherwise ceases to be a Business Associate of either the Company or a Covered Entity with respect to whom the Company is a Business Associate. The Company may also, in addition to other available remedies, terminate this Agreement if Business Associate has materially breached any provision(s) of this Agreement and has failed to cure or take any actions to cure such material breach within five (5) calendar days of the Company informing Agent of such material breach. The Company shall exercise this right to terminate by providing Agent written notice of termination, which termination shall include the reason for the termination. Any such termination shall be effective immediately (following any applicable cure period) or at such other date specified in the Company’s notice of termination. a) Obligations upon Termination. Upon termination, cancellation, expiration or other conclusion of this Agreement or any other agreements for any reason, Agent shall comply with applicable Privacy Regulations requirements regarding the return or destruction of Health Information. b) Continuing Privacy Obligation. Agent’s obligation to protect the privacy of the Health Information be continuous and survive termination, cancellation, expiration or other conclusion of this Agreement.

F. SECURITY OF ELECTRONIC PROTECTED HEALTH INFORMATION.

To the extent that Agent receives, uses, creates, maintains and/or discloses any Electronic Health Information (“E-PHI”) in the course of providing services for or on behalf of Company, Agent additionally agrees: (i) to implement administrative, physical and technical Safeguards to protect the confidentiality, integrity, and availability of the E-PHI that it creates, receives, maintains, or transmits on behalf of the Company, as required by the Security Standards; (ii) to notify the Company if the Agent becomes aware of a security incident involving the Company’s E-PHI; and (iii) to ensure that any agent, including a subcontractor, to whom it provides such E-PHI agrees to implement reasonable and appropriate safeguards to protect the Company’s E-PHI.

G. GENERAL PROVISIONS

1. Injunctive Relief. In the event that Agent breaches any material term of this Agreement, Agent agrees that the Company has a right to obtain injunctive relief to prevent further disclosure of such Health Information. In addition to injunctive relief, the Company may also pursue any other remedy under applicable law or equity available to it.

2. Independent Relationship. None of the provisions of this Agreement are intended to create, nor will they be deemed to create any relationship between the Parties other than that of independent parties contracting with each other as independent contractors solely for the purposes of effecting the provisions of this Agreement.

3. Rights of Third Parties. This Agreement is between the Company and Agent and shall not be construed, interpreted, or deemed to confer any rights whatsoever to any third party or parties.

4. Assignment. Agent may not assign its respective rights and obligations under this Agreement without the prior written consent of the Company.

5. Indemnification and Hold Harmless. Agent shall indemnify and hold harmless the Company, and the Company’s officers, directors, employees and agents from and against any claim, cause of action, liability, damage, cost or expense, including attorneys’ fees and court or proceeding costs, arising out of or in connection with any non-permitted use or disclosure of Health Information or other breach of this Agreement by Agent or any Business Associate subcontractor, agent, representative, person or entity. This Section G.5. shall survive the termination of this Agreement.

6. Waiver. No change, waiver or discharge of any liability or obligation hereunder on any one or more occasions shall be deemed a waiver of performance of any continuing or other obligation, or shall prohibit enforcement of any obligation on any other occasion.

7. Assistance in Litigation or Administrative Proceedings. Agent shall make itself, and any subcontractors, employees or agents assisting Agent in the performance of its obligations under this Agreement, available to the Company, at no cost to the Company, to testify as witnesses, or otherwise, in the event of litigation or administrative proceedings being commenced against the Company, its directors, officers or employees based upon a claimed violation of any of the provisions of the Privacy Regulations or other laws relating to security and privacy, except where Agent or its subcontractor, employee or agent is a named adverse party.

8. Expenses. Unless otherwise stated in this Agreement, each party shall bear its own costs and expenses related to compliance with the above provisions.

9. Governing Law. The laws of the United States and the State of Ohio shall govern the interpretation, validity, performance and enforcement of this Agreement. Jurisdiction and venue for any action under this Agreement shall be in the State or Federal courts located in Hamilton County in the State of Ohio.

10. Headings. The headings of paragraphs contained in this Agreement are for reference purposes only and shall not affect in any way the meaning or interpretation of this Agreement.

11. Interpretation. The Parties agree that any ambiguity in this Agreement will be resolved in favor of an interpretation that protects the Health Information and facilitates Agent’s and the Company’s compliance with applicable terms and requirements of the Privacy Regulations.

12. Entire Agreement. This Agreement constitutes the entire agreement and understanding between the Parties with respect to the subject matter of this Agreement and supersedes and replaces any and all prior written or verbal privacy agreements. If any provision of this Agreement conflicts with any of the provisions of the Privacy Regulations and other applicable law, the said Privacy Regulations or applicable law, to the extent of such conflict, shall control. The Company’s failure to insist upon or enforce strict performance of any provision of this Agreement shall not be construed as a waiver of any provision or right. Neither the course of conduct nor trade practice between the Parties shall act to modify any provision of this Agreement.

13. Conflicts. In the event that Agent has entered into one or more agreement with the Company other than this Agreement, the terms and conditions of this Agreement shall prevail if this Agreement conflicts with any provision of any other of the Company’s agreements.

14. Severability. In the event that any provision of this Agreement is held by a court of competent jurisdiction to be invalid or unenforceable, the remainder of the provisions of this Agreement will remain in full force and effect.

SIGNATURE FOLLOWS

Data Integrity Policy

Cordata takes data integrity very seriously. As stewards and partners of Cordata customers, we strive to ensure 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 Cordata mission of data protection.

Applicable Standards from the HITRUST Common Security Framework

• 10.b - Input Data Validation

Applicable Standards from the HIPAA Security Rule

• 164.308(a)(8) - Evaluation

Data integrity Policy

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

Disabling non-essential services

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

Monitoring Log-in Attempts

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

Prevention of malware on Production Systems

• All Production Systems have Anti-Malware tools running and set to scan system every 2 hours at a minimum, and at reboot to ensure not malware is present. Detected malware is evaluated and removed.
• All Production Systems are to only be used for Cordata business needs.

Patch Management

• Patches, application, and system OS versions are kept up to date at all times. New versions are tested.
• Client IT Administrators are kept up-to-date regarding the latest Cordata software releases via email

Intrusion Detection and Vulnerability Scanning

• Production Systems are monitored using Intrusion Detection Systems. Suspicious activity is logged and alerts are generated.
• Vulnerability scanning of Production Systems must occur on a predetermined, regular basis, no less than annually. Currently it is weekly. Scans are reviewed by Security Officer, with defined steps for risk mitigation, and retained for future reference.

Production System Security

• System, network, and server security is managed and maintained by a combination of ClearDATA, the Cordata Product Engineering team, and the Security Officer.
• Up to date system lists and architecture diagrams are kept for all Production environments.
• Access to Production Systems is controlled using centralized tools and two-factor authentication.

Production Data Security

• Reduce the risk of compromise of Production Data.
• Implement and/or review controls designed to protect Production Data from improper alteration or destruction.
• Ensure that Confidential data is stored in a manner that supports user access logs and automated monitoring for potential security incidents.
• Ensure Cordata customer Production Data is segmented and only accessible to customer authorized to access data.
• All Production Data at rest is stored on encrypted volumes.

Transmission Security

• All data transmission is encrypted end to end. Encryption is not terminated at the network end point, and is carried through to the application.
• Encryption keys and machines that generate keys are protected from unauthorized access.
• Cordata provided APIs, provide mechanisms to ensure the actor sending or receiving data is authorized to send and save data.
• System logs all transmissions of Production Data access. These logs must be available for audit.

ClearDATA# Data Management Policy

Cordata inherits the ClearDATA controls through the PaaS partnership. ClearDATA has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI). The policy and procedures will ensure that complete, accurate, retrievable, and tested backups are available for all systems used by Cordata.

Data backup is an important part of the day-to-day operations of ClearDATA. To protect the confidentiality, integrity, and availability of ePHI, both for ClearDATA and Cordata customers, complete backups are done daily to ensure that data remains available when needed and in case of disaster.

Applicable Standards from the HITRUST Common Security Framework

• 01.v - Information Access Restriction

Applicable Standards from the HIPAA Security Rule

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

Backup Policy and Procedures

1. Perform daily snapshot backups of all systems that process, store, or transmit ePHI for Cordata customers, including PaaS customers that utilize the ClearDATA Backup Service
2. Cordata Infrastructure Team, lead by the manager of infrastructure operations, is designated to be in charge of backups and leverages the ClearDATA Backup Service.
3. Backup log stores:
   • Name of the system
   • Date & time of backup
   • Where backup stored (or to whom it was provided)
4. Securely encrypt stored backups in a manner that protects them from loss or environmental damage.
5. Test backups and document that files have been completely and accurately restored.

Data Retention Policy

Despite not being a requirement within HIPAA, Cordata and our partner ClearDATA understand and appreciates the importance of health data retention. Acting as a subcontractor, and at times a business associate, ClearDATA is not directly responsible for health and medical records retention as set forth by each state. Despite this, ClearDATA has created and implemented the following policy to make it easier for Cordata customers to support data retention laws.

State Medical Record Laws

• Listing of state requirements for medical record retention

Data Retention Policy

• Current Cordata customers have data stored by ClearDATA as a part of the ClearDATA Service.
• Once a customer ceases to be a customer, as defined below, the following steps are
  1. Cordata is sent a notice via email of change of standing, and given the option to reinstate account.
  2. If no response to notice in #1 above within 7 days, or if customer responds they do not want to reinstate account, Cordata is sent directions for how to download their data from ClearDATA and/or to have ClearDATA continue to store the data at a rate of $25/month for up to 100GB. If there is more than 100GB of data, ClearDATA will work with Cordata to determine storage costs.

Disaster Recovery Policy

Cordata inherits the ClearDATA Contingency Plan that establishes procedures to recover Cordata following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the ClearDATA Security Officer and Privacy Officer.

The following objectives have been established for this plan:

1. Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:
   • Notification/Activation phase to detect and assess damage and to activate the plan;
   • Recovery phase to restore temporary IT operations and recover damage done to the original system;
   • Reconstitution phase to restore IT system processing capabilities to normal operations.
2. Identify the activities, resources, and procedures needed to carry out ClearDATA processing requirements during prolonged interruptions to normal operations.
3. Identify and define the impact of interruptions to ClearDATA and Cordata systems.
4. Assign responsibilities to designated personnel and provide guidance for recovering Cordata during prolonged periods of interruption to normal operations.
5. Ensure coordination with other ClearDATA 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 Cordata 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 Cordata 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 Cordata Contingency Plan also complies with the following federal and departmental policies:

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

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

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

Applicable Standards from the HITRUST Common Security Framework

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

Applicable Standards from the HIPAA Security Rule

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

Line of Succession

The following order of succession to ensure that decision-making authority for the Cordata Contingency Plan is uninterrupted. The Chief Executive Officer, Gary Winzenread and Security Officer, Jon Stonis, are responsible for ensuring the safety of personnel and the execution of procedures documented within this Cordata Contingency Plan. If the Security Officer and CEO are unable to function as the overall authority or chooses to delegate this responsibility to a successor, the Privacy Officer shall function as that authority. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below.

Gary Winzenread gary.winzenread@cordatahealth.com 513.605.1550

Jon Stonis jon.stonis@cordatahealth.com 513.605.1550

Responsibilities

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

1. The Infrastructure Team is responsible for recovery of the Cordata hosted environment, network devices, and all servers. Members of the team include personnel who are also responsible for the daily operations and maintenance of Cordata. The team leader is the Manager of Infrastructure Operations and directs the Infrastructure Team.
2. The Engineering 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 Engineering Team.

Testing and Maintenance

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

Tabletop Testing

Tabletop Testing is conducted in accordance with the CMS Risk Management Handbook, Volume 2 (http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH_VII_4-5_Contingency_Plan_Exercise.pdf). 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:

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

Technical Testing

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

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

1. Notification and Activation Phase

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

The notification sequence is listed below:

• The first responder is to notify the Security Officer. All known information must be relayed to the Security Officer.
• The Director of Client Services is to contact the ClearDATA team and inform them of the event. ClearDATA and Cordata are to begin assessment procedures.
• The ClearDATA CTO is to notify team members and direct them to complete the assessment procedures outlined below to determine the extent of damage and estimated recovery time. If damage assessment cannot be performed locally because of unsafe conditions, the CTO is to following the steps below.
  • Damage Assessment Procedures:
  • The CTO and Manager of Infrastructure are to logically assess damage, and begin to formulate a plan for recovery.
  • Alternate Assessment Procedures:
  • Upon notification from the CSO, the VP of Engineering is to follow the procedures for damage assessment with combined Infrastructure and Engineering Teams.
• The Cordata Contingency Plan is to be activated if one or more of the following criteria are met:
  • Cordata will be unavailable for more than 48 hours.
  • Hosting facility is damaged and will be unavailable for more than 24 hours.
  • Other criteria, as appropriate and as defined by Cordata.
  • If the plan is to be activated, the CSO is to notify and inform team members of the details of the event and if relocation is required.
  • Upon notification from the CSO, group leaders and managers are to notify their respective teams. Team members are to be informed of all applicable information and prepared to respond and relocate if necessary.
  • The CSO is to notify remaining personnel and executive leadership on the general status of the incident.
  • Notification can be message, email, or phone.

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 Cordata 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 Cordata 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 - Client Services
2. Assess damage - Engineering
3. Begin replication of new environment using automated and tested scripts.
4. Test new environment using pre-written tests - Engineering
5. Test logging, security, and alerting functionality - Infrastructure
6. Ensure systems are appropriately patched and up to date. - Infrastructure
7. Deploy environment to production - Engineering
8. Update DNS to new environment. - Infrastructure

Cordata Disposable Media Policy

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

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

Applicable Standards from the HITRUST Common Security Framework

• 0.9o - Management of Removable Media

Applicable Standards from the HIPAA Security Rule

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

Disposable Media Policy

1. All removable media is restricted, and is encrypted.
2. Cordata 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 Cordata’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 Cordata 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 case of a Cordata customer terminating a contract with Cordata and no longer utilizing Cordata Services, the following actions will be taken depending on the Cordata Services in use. In all cases it is solely the responsibility of the Cordata Customer to maintain the safeguards required of HIPAA once the data is transmitted out of Cordata Systems.
   • In the case of PaaS customer termination, ClearDATA will provide the customer with 30 days from the date of termination to export data.

Employees Policy and Security Awareness Training

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

Applicable Standards from the HITRUST Common Security Framework

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

Applicable Standards from the HIPAA Security Rule

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

Employment Policies and Training

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 outlining the type of training completed, responsible supervisor, and date of training.
   • Ongoing security training is conducted annually.
   • Cordata training is made available to all employees, at all times on the Cordata Employeee Sharepoint site.
2. All workforce members are granted access to formal organizational policies, which include the sanction policy for security violations.
3. The Cordata Employee Handbook clearly states the responsibilities and acceptable behavior regarding information system usage, including rules for email, Internet, mobile devices and social media usage.
4. All workforce members are educated about the approved set of tools to be installed on workstations.
5. All new workforce members are given HIPAA training within 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 Cordata and its customers and partners.
6. All remote (teleworking) workforce members are trained on the risks, the controls implemented, their responsibilities, and sanctions associated with violation of policies. Additionally, remote security is maintained through the use of VPN tunnels for all access to production systems with access to ePHI data.
7. All Cordata-purchased and -owned computers are to display this message at login and when the computer is unlocked: This computer is owned by Cordata. By logging in, unlocking, and/or using this computer you acknowledge you have seen, and follow, the use policies outlined in the Employee Handbook. Please contact us if you have problems with this - hipaa@cordatahealth.com.

ClearDATA# Facility Access Policy

Cordata does not physically house any systems used by its Platform in Cordata facilities. Physical security of our Platform servers is outlined here for ClearDATA / AWS hosted software.

Applicable Standards from the HITRUST Common Security Framework

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

Applicable Standards from the HIPAA Security Rule

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

Cordata Office Policies

1. Fire extinguishers and detectors are installed according to applicable laws and regulations.
2. Electronic and physical media containing covered information is securely destroyed (or the information securely removed) prior to disposal.
3. The organization securely disposes media with sensitive information.
4. 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 Cordata are the property of Cordata and are distributed to users by the company.

ClearDATA# HIPAA Mappings to Cordata Controls

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

HITECH Act and Omnibus Rule: IT Security Provisions

These were updates made to strengthen the Privacy, Security, and Breach Notifications rules within HIPAA. These updates went into effect in 2013 and were the driving force for many existing IaaS vendors to begin signing BAAs.

Notification in the Case of Breach - 13402(a) and 13402(b)

Cordata has a formal breach notification policy that addresses the requirements of notifying affected individuals and customers of a suspected breach of ePHI. These policies outline the relevant and responsible parties in case of a breach, forensics work to discover extent of breach, reason for breach, correction of infrastructure to prevent future breach, and requirements of notifying customers of a breach within 24 hours. Cordata is a defined Business Associate or subcontractor according to HIPAA regulations and the specific customer relationship.

Timeliness of Notification - 13402(d)(1)

Cordata has a breach notification policy that addresses the requirements of notifying the affected individuals or customers within 24 hours of a breach.

Content of Notification - 13402(f)(1)

Cordata has Breach Notification policies in place and they include a brief description of the breach, including the date of the breach and the date of the discovery of the breach, if known. Cordata breach notification policies include 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 PII were involved) and what the source of the breach was. Our breach notification policies include steps the individual should take to protect themselves from potential harm resulting from the breach. Our policies also provide the contact procedures for individuals to ask questions or learn additional information, which includes a toll-free telephone number, an e-mail address, Web site, or postal address.

ClearDATA# IDS Policy

In order to preserve the integrity of data that Cordata stores, processes, or transmits for Customers, Cordata’s PaaS partner, ClearDATA implements strong intrusion detection tools and policies to proactively track and retroactively investigate unauthorized access.

Applicable Standards from the HITRUST Common Security Framework

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

Applicable Standards from the HIPAA Security Rule

• 164.312(b) - Audit Controls

Intrusion Detection Policy

• ClearDATA provides our Intrusion Detection capabilities. These processes are described in the following link: ClearDATA IDP Link
• ClearDATA MDR is used to monitor and correlate log data from different systems on an ongoing basis.
• ClearDATA MDR generates alerts to analyze and investigate suspicious activity or suspected violations.
• ClearDATA MDR monitors file system integrity and sends real time alerts when suspicious changes are made to the file system.
• Automatic monitoring is done to identify patterns that might signify the lack of availability of certain services and systems (DOS attacks).
• ClearDATA 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.
• All new firewall rules and configuration changes are tested before being pushed into production.

ClearDATA# Incident Response Policy

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

The incident response process addresses:

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

Applicable Standards from the HITRUST Common Security Framework

• 02.f - Disciplinary Process
• 06.f - Prevention of Misuse of Information Assets
• 11.a - Reporting Information Security Events
• 11.c - Responsibilities and Procedures
• 11.a - Reporting Information Security Events

Applicable Standards from the HIPAA Security Rule

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

Incident Management Policies

The Cordata incident response process follows industry best practices. Process flows are a direct representation of these industry best practices.

Identification Phase

1. Immediately upon observation Cordata members report suspected and known Precursors, Events, Indications, and Incidents in one of the following ways:
   1. Direct report to management, the Security Officer, Privacy Officer, or other;
   2. Email;
   3. Phone call;
   4. Online incident response form located [here]
   5. Secure Chat.
   6. Anonymously through workforce members desired channels.
   7. The individual receiving the report facilitates completion of an Incident Identification form and notifies the Security Officer (if not already done).
   8. The Security Officer determines if the issue is a Precursor, Incident, or Event.
   9. If the issue is an event, indication, or precursor the Security Officer forwards it to the appropriate resource for resolution.
      1. Non-Technical Event (minor infringement): the Security Officer completes a SIR Form and investigates the incident.
      2. Technical Event: Assign the issue to an IT resource for resolution. This resource may also be a contractor or outsourced technical resource, in the event of a small office or lack of expertise in the area.
   10. If the issue is a security incident the Security Officer activates the Security Incident Response Team (SIRT) and notifies senior management.
       1. If a non-technical security incident is discovered the SIRT completes the investigation, implements preventative measures, and resolves the security incident.
       2. Once the investigation is completed, progress to Phase V, Follow-up.
       3. If the issue is a technical security incident, commence to Phase II: Containment.
       4. The Containment, Eradication, and Recovery Phases are highly technical. It is important to have them completed by a highly qualified technical security resource with oversight by the SIRT.
       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 facilitates initiation of a Security Incident Report (SIR) Form (See Appendix 2 for sample format) or an Incident Survey Form (See Appendix 4). The intent of the SIR form is to provide a summary of all events, efforts, and conclusions of each Phase of this policy and procedures.
   11. The Security Officer, Privacy Officer, or Cordata representative appointed notifies any affected customers and partners. If no customers and partners are affected, notification is at the discretion of the Security and Privacy Officer.
   12. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to Cordata and potentially external.

Containment Phase (Technical)

In this Phase, Cordata's’s IT department (in conjunction with ClearDATA if applicable) attempts to contain the security incident. It is extremely important to take detailed notes during the security incident response process. This provides that the evidence gathered during the security incident can be used successfully during prosecution, if appropriate.

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

Eradication Phase (Technical)

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

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

Recovery Phase (Technical)

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

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

Follow-up Phase (Technical and Non-Technical)

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

1. Responders to the security incident (SIRT 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 Cordata using the documents provided by the SIRT and the technical security resource.
   2. Determine what could be improved.
   3. Communicate these findings to Senior Management for approval and for implementation of any recommendations made post-review of the security incident.
   4. Carry out recommendations approved by Senior Management; sufficient budget, time and resources should be committed to this activity.
   5. Close the security incident.

Periodic Evaluation

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

Security Incident Response Team (SIRT)

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

• Security Officer
• Privacy Officer
• Senior Management
• VP of Engineering

ClearDATA# Key Definitions

• Application: An application hosted by ClearDATA, either maintained and created by ClearDATA, or maintained and created by Cordata or Partner.

• Application Level: Controls and security associated with an Application. In the case of PaaS customers, Cordata does not have access to and cannot ensure compliance with security standards and policies at the Application Level.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Disaster Recovery Service: A disaster recovery service for disaster recovery in the case of system unavailability. This includes both the technical and the non-technical (process) required to effectively stand up an application after an outage.

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

• Customers: Contractually bound users of the Cordata Platform.

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

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

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

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

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

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

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

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

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

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

• IDS Service: An Intrusion Detection Service for providing IDS notification to customers in the case of suspicious activity.

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

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

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

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

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

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

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

• Platform: The overall technical environment of Cordata.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Vendors: Persons from other organizations marketing or selling products or services, or providing services to Cordata and ClearDATA.

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

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

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

Cordata HIPAA Compliance Policies by Cordata Inc., are licensed under a
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Organizational Requirements (see 164.314)

These requirements simply outline the need for business associate agreements (BAAs) between covered entities and business associates. This requirement has recently been extended to require business associate agreements between business associates and all subcontractors. That linking, chaining together of BAAs, has created for new and interesting legal and business questions. Basically, each layer in the chain of BAAs takes on certain responsibilities and certain risks as part of HIPAA, and there needs to be consistency. Case in point, at Cordata we have several customers that have moved over from compliant IaaS providers because those providers had breach notification timelines that were not acceptable for large healthcare enterprises. We’ve taken a proactive approach to BAAs to mitigate risk for our customers and ensure consistency along the chain of BAAs.

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

Cordata has a formalized policy and process is in place concerning BAA's. BAA templates are in place and BA contracts are reviewed for consistency. All covered entities on the Cordata platform have BAAs in place. Cordata has a formal policy and process in place for performing due diligence with any third party or vendor before engaging them.  Additionally, contracts are retained that detail the responsibility of safeguarding any information to which the provider may have access, as well as creating consistency for Cordata and Cordata customers.

Physical Safeguards (see 164.310)

Cordata defines physical safeguards as, physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion. Our Data Center and Office facilities are separate and secured entirely differently. The following describes Physical security of our Office facility.

 All production Cordata systems are hosted with AWS and protected by ClearDATA. ClearDATA provides hosting, security and recovery services.

Cordata headquarters are protected by RFID keyfob access. Visitors must request access and are escorted throughout the premises. 

Cordata has policies in place that define the acceptable uses of workstations. These policies define the acceptable and authorized uses of provided workstations with access to systems potentially interacting with ePHI. These policies are enforced on all workstations. All internal email uses HIPAA-compliant vendors. 

Cordata provides all employees with our acceptable use policy. This policy outlines all required procedures and security software necessary for daily use of a workstation. 
  

Cordata has a formal Workstation and Portable Media Security Policy that identifies the specific requirements of each device. The policies define the requirements for using and/or restricting specific actions while engaged with any ePHI. Additionally, workstations are secured appropriately to limit exposure to breaches. Firewalls and hard disk encryption are used on all workstations. Actions and events are monitored and controlled, with user restrictions on downloading or copying any ePHI without documented approval and business justification. Additionally, all file storage internally at Cordata utilizes HIPAA-compliant cloud-based vendors.

Cordata has polcies and procedures for all workstations that interact with and may potentially become exposed to ePHI. These policies have requirements for secure media disposal so that ePHI cannot be recovered from these systems.

Cordata has Media Re-use requirements for the workstations, despite the fact that these workstations do not have access to and interaction with ePHI.

All users within the Cordata environment are issued a unique user name and password. All accounts are local and unique. General/shared accounts are not in place and root access is restricted and monitored.

Cordata has procedures and a process for obtaining access to ePHI should an emergency or disaster occur.

Cordata systems settings on all its servers have session timeout features enabled and configured to terminate sessions after a period of 30 minutes or less.

Cordata encrypts all stored data in its environment using 256-bit AES encryption or better. Additionally, all data in transit is encrypted end to end (more below).

Cordata has policies in place addressing audit trail requirements. Systems log to a centralized logging solution within AWS, , which is monitoring system level events and contains user id, timestamp, event, origination, and type of event. All servers are constantly monitored for suspicious events and alerts are generated to any type of behavior that is suspicious. 

Cordata has employed a centralized access control system for authenticating and accessing internal systems where ePHI resides. Currently, Cordata employees utilize a VPN connection to access internal systems. Accounts on the internal database are restricted to a limited number of personnel, with logging in place to track all transactions.

Cordata has a formal policy that describes the process of verifying a person's identity before unlocking their account, resetting their password, and/or providing access to ePHI.

All data in transit with Cordata is sent over internet connections through an SSLv3/TLS1.3 encrypted mechanism. Additionally, none of the internal application servers, database servers, and log and monitoring servers are accessible via public internet. All internal servers must be accessed via a VPN.  

Cordata has a formalized Policy Management program that ensures that policies are developed, implemented, and updated according to best practice and organization requirements. In the words of our auditors, this is a policy about our policies.

Cordata retains the necessary policies and documentation for a minimum of 6 years. All policies and procedures are available and distributed to personnel on the company Sharepoint site. Cordata has an update and review process for reviewing all policies and procedures and updating them as necessary. Additionally, Cordata tracks and maintains revision history and timestamps to ensure policies are reviewed and updated according to organization requirements.