DATA PROCESSOR AGREEMENT

[CONTROLLER]/ AliveCor

THE PARTIES:

  1. [CONTROLLER], having its registered office at [ADDRESS] (“Controller”); and

  2. AliveCor, Inc., incorporated in the State of Delaware USA with its headquarters located at 189 Bernardo Ave. Ste. 100, Mountain View, California 94043 USA and its wholly owned subsidiary AliveCor LTD, a private limited company incorporated in England and Wales with company number 08476285 having its principal place of business at Herschel House, 58 Herschel Street, Slough, United Kingdom, SL1 1PG and any other of its Affiliates, (collectively “Processor”);

Controller and Processor to be referred to collectively hereinafter as “Parties” and individually as “Party”,

WHEREAS

  1. On even date herewith, Controller and Processor executed the KardiaPro API Terms of Service (“Agreement”).

  2. Under the Agreement, Processor may be required to Process certain Personal Data from Controller.

  3. This Data Processor Agreement sets out the terms and respective rights and obligations of the Parties in respect of such Processing of Personal Data.

IT IS AGREED AS FOLLOWS:

  1. Definitions and interpretations

    1. In this Processor Agreement the capitalised terms below shall be assigned the following meanings:

    2. Controller enters into this Processor Agreement for its own benefit and for the benefit of its Affiliates, on behalf of whom Controller shall be entitled to enforce any and all of the provisions of this Processor Agreement. For the purpose hereof “Controller” shall also mean each of its Affiliates, unless explicitly stated otherwise. Controller's Affiliates are entitled to enforce the provisions of this Processor Agreement as though those Affiliates were the Controller.

    3. In the event of a conflict between this Processor Agreement and the Agreement, the terms of this Processor Agreement shall prevail. In the event of a conflict between Articles 1 to 13 of this Processor Agreement and an Appendix thereto, the strictest provision shall prevail.

  2. Processing of Personal Data

    1. Processor shall perform its activities pursuant to the Agreement, acting as Processor on behalf of Controller. Controller shall remain the Controller for all Personal Data that are Processed under the Agreement.

    2. Controller retains all right, title and interest in and to the Personal Data.

    3. The types of Personal Data, categories of Data Subjects and the purposes of the Processing by Processor are described in Appendix 1 (Personal Data and Processing activities) and are further detailed in the Agreement.

  3. Obligations of Controller

    1. As Controller, Controller shall comply with its obligations under Applicable Regulations and this Processor Agreement.

    2. Controller shall instruct Processor to Process the Personal Data on Controller's behalf and in accordance with Applicable Regulations. The Processing instructions of Controller are documented in Appendix 1 (Personal Data and Processing activities) and are further detailed in the Agreement.

    3. Controller may issue additional instructions with regard to Processor’s Processing activities, or amend such instructions, if necessary, at the Controller’s sole discretion, provided that such instructions are (i) consistent with the terms of the Agreement and this Processor Agreement, (ii) reasonable, and (iii) are required by Applicable Regulations. The Processor will promptly notify the Controller if, in its opinion, the Controller's instructions do not comply with the Applicable Regulations.

    4. Controller shall issue any such additional or amended instructions in writing or by electronic mail to Processor, and Processor shall have a reasonable period of time, not less than 45 days, to implement the additional instructions. Additional instructions not required by Applicable Regulations will require prior written agreement between the Parties.

  4. Obligations of Processor

    1. As Processor, Processor shall comply with its obligations under Applicable Regulations and as set forth this Processor Agreement.

    2. Processor shall ensure that it and each of its Processor Employees (a) only Processes Personal Data on behalf of Controller and in accordance with Controller’s instructions; (b) refrains from Processing the Personal Data for its own purposes or for purposes of third parties when not permitted under Applicable Regulations; and (c) Processes the Personal Data only in so far as necessary to perform its activities under the Agreement; unless Processor is required to do otherwise by applicable EU, Member State or UK law and, unless the applicable EU, Member State or UK law prohibits the Processor from so notifying the Controller, it promptly notifies Controller thereof in accordance with Article 4.5.b. Processor shall document the (additional) instructions given by Controller.

    3. During the term of this Processor Agreement, if Processor receives any request from a Data Subject relating to his or her Personal Data, Processor shall promptly refer that Data Subject to Controller to submit his or her requests. Controller shall be responsible for responding to any such request. Processor shall provide such assistance as Controller may reasonably specify to enable Controller to meet its obligations to respond to requests for exercising the rights of Data Subjects pursuant to Applicable Regulations, including, but not limited, requests from Data Subjects to access, correct or delete their Personal Data. For the purpose of clarity and without limiting Processor’s obligation to provide assistance in accordance with this clause 4.3, Processor may provide software tools within the API (“Tools”) if such is licensed under the Agreement for Controller to perform its obligations as Controller to a Data Subject; prior to requesting assistance from Processor under this paragraph, Controller shall make reasonable and concerted efforts to meet its GDPR obligations to the Data Subject using the Tools if such Tools are provided under the Agreement. For the purpose of clarity, Controller organizations do not have such Tools, so the obligations of Controller related to using Tools under this Section 4.3 do not apply to Controller organizations.

    4. Processor shall provide such assistance as Controller may reasonably specify to enable Controller to (a) carry out a data protection impact assessment and a possible subsequent prior consultation with a Supervisory Authority and (b) to respond to or defend against enquiries, requests or investigations from a Supervisory Authority.

    5. Processor shall promptly inform Controller in any of the following events if:

      1. Processor has reason to believe that it cannot comply with this Processor Agreement;

      2. applicable EU, Member State or UK law prevents Processor from fulfilling the instructions received from Controller, unless that law prohibits Processor from providing such information;

      3. Processor or a Processor Employee has acted in breach of this Processor Agreement or if a Subprocessor has acted in breach of the written agreement between Processor and such Subprocessor; or

      4. Processor has received a warning or a reprimand from a Supervisory Authority that the Processing activities are likely to infringe, or have infringed, Applicable Regulations.

    6. The Processor shall ensure under contract that the Processor Employees:

      1. are informed of the confidential nature of the Personal Data and are bound by confidentiality obligations and use restrictions in respect of the Personal Data;

      2. have undertaken training on the Applicable Regulations relating to handling Personal Data and how it applies to their particular duties; and

      3. are aware both of the Processor's duties and their personal duties and obligations under the Applicable Regulations and the Agreement.

  5. Subprocessors

    1. Processor shall not subcontract any of its obligations under the Agreement to a Subprocessor without Controller’s prior written consent, which consent Controller may not unreasonably withhold or delay. Controller may attach reasonable conditions to its consent. The Subprocessors listed in Appendix 3 (Approved Subprocessors) are hereby approved for the areas of work specified therein.

    2. Processor may only engage a Subprocessor by way of a written agreement with such Subprocessor which imposes at least the same obligations on the Subprocessor as are imposed on Processor under this Processor Agreement, in particular, in relation to requiring appropriate technical and organisational data security measures, and, upon the Controller’s written request, provides the Controller with copies of the relevant excerpts from such contracts.

    3. Processor shall restrict the Subprocessor’s access to Personal Data to the minimum necessary for the Subprocessor to perform its assigned activities under the Agreement.

    4. Processor shall prohibit the Subprocessor from accessing or using Personal Data for any purpose not related to the performance of its assigned activities under the Agreement.

    5. Processor shall remain responsible for its compliance with its obligations under the Agreement and this Processor Agreement and for any acts or omissions of the Subprocessor that cause Processor to breach any of its obligations under the Agreement or this Processor Agreement.

  6. Confidentiality

    1. Processor shall keep the Personal Data confidential. Processor shall not disclose the Personal Data to any third party or an Affiliate, other than (a) as explicitly authorised under the Agreement; (b) with Controller’s specific prior written consent, in each case in accordance with Article 5 of this Processor Agreement; or (c) in accordance with Article 10.

    2. Processor shall restrict the dissemination of the Personal Data to those authorised Processor Employees who are assigned to Process Personal Data under the Agreement and only on a need-to-know basis.

    3. Processor represents and warrants that each Processor Employee is bound by confidentiality obligations that are consistent with the confidentiality obligations in this Processor Agreement, for example, by means of a non-disclosure agreement, which shall remain in force after termination of such Processor Employee’s employment contract.

  7. Security and Security Breaches

    1. Processor shall implement appropriate administrative, organisational, physical and technical safeguards to protect the confidentiality, integrity and availability of the Personal Data consistent with Applicable Regulations, including, without limitation, to protect the Personal Data against destruction, loss, unauthorised disclosure or access, or any other form of unlawful processing, modification or copying. To clarify, Processor shall consider the state of the art and implementation costs when considering the appropriateness of such administrative, organisational, physical and technical safeguards, and ensure that such measures offer an appropriate level of security given the risks associated with Processing and the nature of the Personal Data to be protected.

    2. Appendix 2 (Security Measures) describes the measures that Processor shall implement and maintain in any event. Processor may update or modify the Security Measures set out in Appendix 2 from time to time, provided that such updates and modifications do not result in any degradation of the level of security. Processor shall notify Controller of the updates or modifications and shall send an amended version of Appendix 2, within ten (10) days after any such changes.

    3. The Processor must implement such measures to ensure a level of security appropriate to the risk involved, including as appropriate:

      1. the pseudonymisation and encryption of personal data;

      2. the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

      3. the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; and

      4. a process for regularly testing, assessing and evaluating the effectiveness of the security measures.

    4. Processor shall, without undue delay and, where feasible, but no later than twenty-four (24) hours after discovery, notify Controller of any actual or reasonably suspected (i) accidental or unlawful destruction, loss, alteration, corruption, damage, unusability, disclosure, processing of, or access to, part or all of the Personal Data; or (ii) a breach of the security measures as referred to in this Article 7 or as implemented by a Subprocessor (a “Security Breach”), regardless whether this Security Breach takes place at Processor or Subprocessor. Processor shall also notify Controller if a Security Breach takes place at a Subprocessor. Processor shall employ appropriate measures to detect, respond to and recover from Security Breaches, including employment of appropriate remedial measures.

    5. The notification of a Security Breach shall at least:

      1. describe the nature of the Security Breach, including, where possible, the categories and approximate number of Data Subjects concerned and the categories and approximate number of Personal Data records concerned;

      2. describe whether the Personal Data are encrypted, anonymised or otherwise made incomprehensible;

      3. communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;

      4. describe the likely consequences of the Security Breach; and

      5. describe the measures that the Suppler has taken, or proposes taking, to address the Security Breach, including, where appropriate, measures to mitigate its possible adverse effects.

    6. Immediately following any accidental, unauthorised or unlawful Personal Data processing or Security Breach, the parties will co-ordinate with each other to investigate the matter. At Controller’s request, Processor shall provide all required cooperation to handling the Security Breach, such as informing Supervisory Authorities and Data Subjects (if required).

    7. The Processor agrees that the Controller has the right to determine whether to (i) provide notice of the accidental, unauthorised or unlawful processing and/or the Security Breach to any Data Subjects, the Supervisory Authority, other in-scope regulators, law enforcement agencies or others, as required by law or regulation or in the Controller’s discretion, including the contents and delivery method of the notice, and (ii) offer any type of remedy to affected Data Subjects, including the nature and extent of such remedy.

  8. Compliance

    1. At Controller’s request and at reasonable intervals, not to exceed once per every two years following the Effective Date, unless such request would be required by Controller in order to comply with Applicable Regulations, Processor shall provide Controller with all requested information about Processor’s Processing activities under the Agreement and this Processor Agreement, and about each Subprocessor’s Processing activities under the agreement between Subprocessor and Processor, necessary to enable Controller to verify Processor’s and each Subprocessor’s compliance with the provisions of this Processor Agreement.

    2. At a frequency not exceeding once every two (2) years following the last signature on this Processing Agreement or following the last audit Controller made at its option request, Processor shall permit an audit by an independent auditor selected by Controller and approved by Processor, where such approval shall not be unreasonably withheld. The audit shall assess the Processor's organisation, Processing systems and facilities to establish that Processor is complying with its obligations under this Processor Agreement. The auditor shall be bound by confidentiality obligations at least as stringent as those in this Processor Agreement. The audit shall be performed upon one (1) month written notice, during normal business hours and in such manner as not to interfere unreasonably with the normal business activities of Processor. The costs of such audit shall be borne by Controller. If the audit reveals any material non-compliance by the Processor under this Processor Agreement, Processor shall use all reasonable endeavours to remedy the relevant non-compliance at its own cost within a period of 12 months from the date of such audit, and certify to Controller what corrections have been made to address such material non-compliance.

    3. AliveCor shall complete an annual DSPT (data security protection took kit) per Controller regulations.

  9. Transfer of Personal Data outside the EEA or UK (as applicable)

    1. The Parties acknowledge that the Applicable Regulations contain restrictions on transferring Personal Data from an EU Member State or UK (where applicable) to countries or organisations outside the EEA or UK which do not ensure an adequate level of protection, which includes making such Personal Data accessible from any such country or organisation (“Transfer”).

    2. Processor shall not Transfer Personal Data other than (a) as explicitly authorised under the Agreement, (b) with the specific prior written consent of Controller (which may be conditional); unless it is required to do so by EU law, Member State law or UK law (as applicable) to which it is subject and it promptly informs Controller thereof in accordance with Article 4.5.b, unless prohibited to notify the Controller in accordance with such laws. It is understood and agreed that Processor uses third-party (a sub-Processor) customer support services (“Support Service”) of Zendesk to aid Controller-patients in the use of services provided by the Processor, where the patient/Support Service interaction and data provided and Transfer thereof is described in Appendices 1 and 3. Zendesk has appropriate Standard Contractual Clauses and safeguards in place to permit it to Transfer data to the USA.

    3. Where the Processor will undertake a Transfer with the consent of the Controller, the Processor will first conduct a Transfer risk assessment in accordance with the guidance issued under the UK Regulations, in order to ensure appropriate safeguards are in place to adequately protect the Personal Data being Transferred and ensure the Data Subject benefits from the same protections as afforded to it under the Applicable Regulations.

    4. If during the term Agreement, the Applicable Regulations no longer allow Transferring Personal Data pursuant to Standard Contractual Clauses or these Transfer mechanisms are invalidated, adjusted or replaced by a court or a Supervisory Authority, then Parties will without undue delay enter into good faith negotiations to implement an alternative data transfer mechanism that complies with the Regulations. If Parties do not reach agreement on the alternative transfer mechanism or the implementation thereof within two (2) months, then Controller may immediately terminate the Agreement by providing written notice. This right of Controller is without prejudice to any other rights of Controller under the Agreement, this Processor Agreement or at law.

  10. Inspection Requests

1.  If Processor or a Subprocessor receives a request or order from a Supervisory Authority to provide access to Personal Data (“Order”), Processor shall promptly notify Controller of that fact. When responding to or otherwise addressing the Order, Processor shall observe all of Controller’s instructions (including the instruction to leave all or part of the handling of the Order to Controller) and provide all reasonably required cooperation.

2.  If the Order prohibits Processor from complying with such obligations, Processor shall promote Controller’s reasonable interests. To that end, in any event, Processor shall at Controller’s expense and subject to Article 10.3:

    1.  perform a legal review to determine the extent to which (i) Processor is required by law to comply with the request or Order; and (ii) Processor is de facto prohibited from complying with its obligations set out in this Article 10;

    2.  only cooperate with the Order if this is required by applicable law and, where possible, object (at law or otherwise) to the Order enjoining it from not informing Controller in this respect or from following its instructions;

    3.  refrain from providing any more or any other Personal Data than are strictly necessary to comply with the Order;

    4.  if Personal Data are transferred to a non-EEA country: if reasonably possible, comply with the data transfer rules of the Regulations;

    5.  inform Controller promptly once this is permitted.

3.  Controller shall reimburse Processor for the full costs with regard to meeting the obligations described in Article 10.2(a) and 10.2(b), provided that these costs are reasonable, specified and exceed the normal costs of compliance that may be expected from a professional supplier vendor like Processor.
  1. Complaints, Data Subject Requests and Third-Party Rights
1.  The Processor must take such technical and organisational measures as may be appropriate, and promptly provide such information to the Controller as the Controller may reasonably require, to enable the Controller to comply with:

    1.  the rights of Data Subjects under the Applicable Regulations, including subject access rights, the rights to rectify, port and erase personal data, object to the processing and automated processing of personal data, and restrict the processing of personal data; and

    2.  information or assessment notices served on the Controller by the Supervisory Authority, or other relevant regulator, under the Applicable Regulations.

2.  The Processor must notify the Controller immediately in writing if it receives any complaint, notice or communication that relates directly or indirectly to the processing of the Personal Data or to either party's compliance with the Applicable Regulations.

3.  The Processor must notify the Controller within 2 working days if it receives a request from a Data Subject for access to their Personal Data or to exercise any of their other rights under the Applicable Regulations,

4.  The Processor will give the Controller its its full co-operation and assistance in responding to any complaint, notice, communication or Data Subject request.
  1. Warranties

    1. The Processor warrants and represents that:

      1. its employees, subcontractors, agents and any other person or persons accessing the Personal Data on its behalf are reliable and trustworthy and have received the required training on the Applicable Regulations;

      2. it and anyone operating on its behalf will process the Personal Data in compliance with the Applicable Regulations and other laws, enactments, regulations, orders, standards and other similar instruments;

      3. it has no reason to believe that the Applicable Regulations prevents it from providing any of the Agreement's contracted services; and

      4. considering the current technology environment and implementation costs, it will take appropriate technical and organisational measures to prevent the unauthorised or unlawful processing of Personal Data and the accidental loss or destruction of, or damage to, Personal Data, and ensure a level of security appropriate to:

        1. the harm that might result from such unauthorised or unlawful processing or accidental loss, destruction or damage;

        2. the nature of the Personal Data protected; and

        3. comply with all Applicable Regulations and its information and security policies, including the security measures required in Article 7.

    2. The Controller warrants and represents that the Processor’s expected use of the Personal Data for the purposes of fulfilling its obligations under the Agreement, and as specifically instructed by the Controller will comply with the Applicable Regulations.

  2. Indemnification

1.  Processor indemnify, keep indemnified and defend at its own expense, the Controller against any costs, claims, damages, or expenses, incurred  by the Controller, or for which the Controller may become liable due to any failure by Processor (or the Processor Employees, subcontractors or agents),  to comply any of its obligations under this Processing Agreement or the Applicable RegulationsIn no event shall Processor’s aggregate liability arising out of or related to this Processor Agreement exceed $1,000,000.
  1. Term and Termination

    1. This Processor Agreement constitutes an integral part of the Agreement and shall automatically terminate upon expiry or termination of the Agreement for any reason whatsoever.

    2. In the event that Processor is in breach of any material obligation of this Processor Agreement, Controller may, without prejudice to any of its other rights under the Agreement, terminate this Processor Agreement with immediate effect by notifying Processor in writing.

    3. Upon termination of the Agreement or after the end of the provision of Processing activities (whichever is earlier, and collectively “Termination Event”), Processor shall comply with instructions from Controller, such instructions to be provided no more than thirty (30) days from the date of the Termination Event, to delete or destroy Personal Data and/or delete all copies of such Personal Data (“Deletion Request”), where Controller shall provide all reasonable assistance to Processor needed to comply with the Deletion Request. Processor shall not be required to perform any other tasks with the Personal Data outside complying with the Deletion Request or with Application Regulations, for example and not by way of limitation Processor shall not be required to archive or transfer any Personal Data.

  2. Miscellaneous

    1. The Processor will keep detailed, accurate and up-to-date written records regarding any processing of the Personal Data, including but not limited to, the access, control and security of the Personal Data, approved subcontractors, the processing purposes, categories of processing, any transfers of Personal Data to a third country and related safeguards, and a general description of the technical and organisational security measures referred to in Article 7 (“Records”). The Processor will ensure that the Records are sufficient to enable the Controller to verify the Processor’s compliance with its obligations under this Agreement and the Processor will provide the Controller with copies of the Records upon request.

    2. This Processor Agreement will be construed in accordance with and governed by the law of the jurisdiction where Controller has its principal place of business and each Party agrees to submit to the exclusive jurisdiction of such jurisdiction, this not withstanding the applicable law designated in the Agreement, if different.

Appendix 1 – Personal data and Processing activities

  1. Subject matter: The Processing of Personal Data as further described in this Processor Agreement.

  2. Duration: The Personal Data will be Processed during the term of the Agreement.

  3. Nature and purpose: There are four scenarios to be implemented by Controller to which this DPA will apply.

    One or more of the below Scenarios will apply.

          In Scenario 1 Controller purchases portable KardiaMobile® ECG sensors for use by its healthcare professionals (“HCP”) to have patients record a single-lead ECG in the presence of the healthcare provider. The ECG data from KardiaMobile is wirelessly transmitted to the HCP’s mobile device running Processor’s app (Kardia™ App) that displays the ECG rhythm strip and provides an instant analysis of this rhythm strip for review by the HCP. In Scenario 1 the HCP, as an agent of Controller, downloads KardiaApp and sets up a Kardia App account (“Account”) with Processor. Controller is the Data Controller on the basis that the HCP sets up the Account on behalf of and as an “agent” of the Controller. Controller’s SOP instructs the HCP to disable Kardia App from storing ECG recordings on the mobile device and in Processor’s backend. The patient records his ECG under the HCP’s instructions in ‘guest mode’, where that ECG data is transmitted to the HCP’s mobile device, where Kardia App displays the rhythm strip and analyzes the data in ‘guest mode’. This recorded data is not stored on the mobile device or in Processor’s backend.

          In Scenario 2 the Controller purchases portable KardiaMobile® ECG sensors that the HCP provides to and for use by Controller’s patients (“Controller-Patient”) under the directions of Controller HCP to have the Controller-Patient record a single-lead ECG. The Controller-Patient, at the HCP’s direction, downloads Kardia App to his mobile device and sets up a Kardia App account (“Account”) with Processor. The Account set up requires the Controller-Patient to agree to Processor’s ToS and Privacy Notice (“PN”) for using the Kardia App, where the ToS and PN make it clear to the Controller-Patient that the Controller is the Data Controller under UK GDPR. The ECG data from KardiaMobile is wirelessly transmitted to the Controller-Patient’s mobile device running Processor’s app (“Karadia™ App”) that displays the ECG rhythm strip and provides an instant analysis of this rhythm strip on the mobile device. The Controller-patient emails their ECG rhythm strip and instant analysis results to an HCP-provided email. The ECG data and instant analysis thereof are stored on the mobile device and in Processor’s AWS servers in Germany for any future reference desired by the Controller-Patient or the Controller if the Controller-Patient grants access permission to the HCP. Controller is the Data Controller on the basis that the HCP (as an “agent” of the Controller) directs the Controller-Patient to download and use the KardiaMobile ECG sensor and the Kardia App.

          In Scenario 3 the Controller purchases KardiaMobile® ECG sensors and provides them to and for use by Controller patients (“Controller-Patient”) under the directions of the Controller HCP to have the Controller-Patient record a single-lead ECG. The Controller-Patient at the HCP’s direction, downloads Kardia App to their mobile device and sets up a Kardia App account (“Account”) with Processor that requires the Controller-Patient to agree to Processor’s ToS and Privacy Notice (“PN”) for using the Kardia App, where the ToS and PN make it clear to the Controller-Patient that the Controller is the Data Controller under UK GDPR. The ECG data from KardiaMobile is wirelessly transmitted to the Controller-Patient’s mobile device running Processor’s app (“Karadia™ App”) that displays the ECG rhythm strip and provides an instant analysis of this rhythm strip on the mobile device. Data collected by Kardia App is stored in an Processor AWS-instance located in Germany. The Controller, separately, has a KardiaPro account to permit the Controller-HCP’s to review ECG recordings done remotely by the Controller-Patients. The HCP sets up a patient record in KardiaPro by entering patient information (e.g., MRN + email) where KardiaPro generates a unique referral-code (“Code”) for the Controller-Patient to enter into their KardiaApp account under directions from the Controller-HCP, permitting the Controller-HCP to access the Controller-Patient’s ECG data via KardiaPro. The Controller-HCP can also enter notes into the Controller-Patient’s record in KardiaPro to which the Controller-Patient will not have access. All the data entered into KardiaPro is kept/saved entirely separated/segregated from the data stored by Kardia App, where KardiaPro permits the Controller-HCP to access the ECG data collected, processed and stored by the Kardia App. All this data is stored in AWS in Germany and is not transmitted outside the EEA except back to the UK. Controller is the Data Controller on the basis that the HCP (as an “agent” of the Controller) directs the Controller-Patient to download and use the KardiaMobile ECG sensor and the Kardia App and the HCP enters all patient information in KardiaPro.

          In Scenario 4 the Controller purchases KardiaMobile® ECG sensors for the Controller healthcare professionals (“HCP”) to record an ECG of Controller patients (“Controller-Patient). The ECG data from KardiaMobile is wirelessly transmitted to the KardiaStation app (“KardiaStation App”) installed and running on a mobile device (“Tablet”) controlled by the Controller-HCP, which displays the ECG rhythm strip and provides an instant analysis of this rhythm strip for immediate review. The KardiaStation App access credentials are set by the Controller when it signs up for the service, and the KardiaStation App will prompt the Controler to enter unique patient information (e.g., MRN) prior to recording a patient’s ECG. Data collected by KardiaStation App is stored in a Processor AWS-instance located in Germany. In addition, the Controller has a KardiaPro account with Controller generated access credentials. Within KardaPro, the Controller-HCP generates a unique Controller-Patient record with information selected by the NHS, where ECG recordings for that Controller-Patient are stored in that patient’s electronic record within the KardiaPro database (AWS in Germany). All the data entered or transmitted by the Tablet, KardiaStation App and KardiaPro is stored in AWS in Germany and is not transmitted outside the EEA except back to the UK. NHS is Data Controller.

  4. Categories of Data Subjects: patients of Controller

  5. Types of Personal Data: see Description for Scenarios 1-4 above.

Appendix 2 – Security Measures

  1. Procedures

    1. ENCRYPTION AND DECRYPTION PROCEDURES

      1. Data is encrypted both at rest and in transit.

      2. For employee workstation, AliveCor shall ensure that hard drives are encrypted using native encryption.

      3. For the production software application, AliveCor shall perform the following encryption:

        • AES 256-bit encryption for in-process data for ECG recordings.

        • ECG waveform data will be stored in binary files in the application documents folder on the iOS mobile computing platform (MCP). These files will not contain any patient identifiable information.

        • Local data is only accessible through the AliveCor Kardia application.

        • All data is encrypted using native hardware encryption while the device is locked.

        • ECG files on Android are protected via native file system permissions.

        • Employ transport layer security (TLS 1.2) a strong key exchange (ECDHE RSA with P-256), and a strong cipher (AES 128 GCM) to establish a secure link to a trusted server and encrypt data in transit, such as patient passwords and patient ECG data.

        • PII for the Kardia Application on Heroku uses database column level encryption for data at rest.

      4. The following server-side methods for encryption are provided:

        • Amazon S3

          • Data at rest is encrypted with a unique key employing strong multi-factor encryption. As an additional safeguard, Amazon S3 encrypts the key itself with a master key that it regularly rotates. Amazon S3 server-side encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt data.
        • Heroku

          • HTTPS is enabled for AliveCor’s production application for in-transit customer ECG recordings sent and received from the AliveCor’s cloud servers using AES 256-bit encryption and industry standard Secure Sockets Layer (SSL).
    2. DATA TRANSMISSION SECURITY PROCEDURES

      1. AliveCor shall use the Bitdefender Antivirus Software to protect our systems from malicious software.

      2. Security reminders will be sent to remind employees to update to the latest version of the Bitdefender Antivirus Software.

    3. DATA BACKUP AND STORAGE PROCEDURES

      1. AliveCor’s production database is hosted by Heroku, which is a cloud based postgres database that is built on top of Amazon Web Services (AWS). AliveCor shall also use the Heroku platform to process PHI.

      2. Heroku also provides the following backup services:

        • Automatic back up as part of the deployment process on secure, access controlled, and redundant storage. These backups are used to deploy the application across the Heroku platform and to automatically bring applications back online in the event of an outage.

        • Configuration and meta-information is backed up every minute to the same high-durability, redundant infrastructure used to store database information. These frequent backups allow capturing changes made to the running application configuration added after the initial deployment.

      3. AliveCor shall also design our production database for high availability with the provision of a hot standby follower database; every change to data is written to write-ahead logs, which are shipped to multi-datacenter, high-durability storage. In the unlikely event of unrecoverable hardware failure, these logs can be automatically ‘replayed’ to recover the database to within seconds of its last known state.

      4. The systems that provide critical information we will backup include:

        • Source Code on GitHub

        • Database (Recording and user metadata) on Heroku

        • File Storage of physical ECG files on Amazon S3

        • Regulatory and Quality files on Box

        • Contract Manufacturer files on their FTP Server

      5. AliveCor shall store PHI on Amazon S3.

      6. AliveCor shall store Regulatory and Quality files on Box, which replicates data between its multiple data centers and also backs up data to a third-party public cloud provider for data redundancy.

        • Additionally, if a user accidentally deletes a file on Box, it goes into the trashcan which the Security Officer has configured to keep trash content 30 days in the event someone desires to recover a deleted file.
      7. Our Contract Manufacturer stores production documentation (Device History Files, Production Control Plans, Manufacturing Work Instructions, etc.) in their local FTP server. AliveCor shall backup this FTP server by automatically copying all files into Box nightly.

    4. INFORMATION SYSTEMS ACTIVITY REVIEW PROCEDURES

      1. Maintain activity logs from the following Cloud hosted systems that contain transmitted ePHI:

        • Amazon AWS

        • Heroku

      2. The AliveCor application software shall encrypt all ePHI, per these Information Systems Activity Review procedures.

        • For the Alivecor ECG recordings from customers, the communication between the hardware and software is through the mobile computing platform (MCP) microphone, the software for which is controlled by a microphone application program interface (API). This communication occurs directly and it is impossible for a third-party app or malware to inject data into this pathway without the user maliciously providing application root (superuser) access.

        • The MCP operating systems on which the AliveCor application software is used is designed to prevent applications from interacting with one another. In the event that malicious software was loaded onto the same MCP as the AliveCor application, it should not be able to impact its functionality.

      3. AliveCor shall implement the following cybersecurity measures for its application software:

        • The AliveCor application software shall encrypt the transmitting of the customer passwords.

        • All data stored on the MCP shall be encrypted using native hardware encryption.

        • Metadata, including patient information, shall be stored in a local database which is inaccessible to other users.

        • This local storage database is encrypted if backed up in iTunes or iCloud and while at rest in a locked device.

        • Communication between the MCP and Heroku cloud server shall use transport layer security (TLS 1.1 or 1.2 or better) to establish a secure link with cloud servers and to encrypt data in transit, such as customer passwords and customer ECG data.

        • Analyze security of our site’s SSL certificate configuration biannually (twice per year) using publicly available server testers, such as the Qualys SSL Server Test, https://www.ssllabs.com/ssltest/.

  2. Security standards compliance and certifications

    1. AMAZON WEB SERVICES

      1. AliveCor stores all data collected from Kardia App, KardiaMobile and KardiaPro users on AWS and/or Heroku built on AWS.

      2. All production Heroku servers and databases use Heroku Shield space, compliance details can be found here.

      3. AWS Security Certifications

        • ISO27001

        • ISO 9001

        • AWS Security Compliance

        • SOC1

        • SOC2

        • SOC3

      4. AliveCor’s 2020 Security Road Map

        1. Penetration Testing: AliveCor will conduct penetration testing into its systems in CY 2020. The exact scope and timing are being determined by management. AliveCor will provide the penetration testing report to its customers.

        2. HITRUST Certification and/or SOC2 and/or ISO 27001Compliance/Report: AliveCor will seek HITRUST certification and/or seek SOC2 Compliance and/or seek ISO 27001 Compliance with a report in CY 2020. Management is determining whether to proceed with one, both or all three and if just one which one. The exact timing is being discussed by management.

        3. MDS2: AliveCor may seek completion of the Manufacturer Disclosure Statement for Medical Device Security in CY 2020. Management is determining if this is largely overlapping with HITRUST or SOC2 or ISO 27001 to determine the best path forward in demonstrating we secure our user’s data to the highest standards. A link to the form can be found here.

Appendix 3 – List of Processor Approved Subprocessors

The following Subprocessors are hereby approved for the specified areas of work.