Employee Records

In this definition, the following terms have the following meanings:

Controller

Shall have the meaning given to it in the UK GDPR.

Data Subject

Shall have the meaning given to it in the UK GDPR.

Data Exporter

Has the meaning given to it in the International Data Transfer Agreement.

Data Importer

Has the meaning given to it in the International Data Transfer Agreement.

Data Protection Laws

Any applicable law relating to the processing of Personal Data including the Data Protection Act 2018, the UK GDPR and any such laws that replace, extend, re-enact, consolidate or amend any of the foregoing.

Data Protection Losses

All liabilities, including all:

  1. Costs (including legal costs), claims, demands, actions, settlements, interest, charges, procedures, expenses, losses and damages (including relating to material or non-material damage);
  2. To the extent permitted by Data Protection Laws:
  3. Administrative fines, penalties, sanctions, liabilities or other remedies imposed by a Supervisory Authority;
  4. Compensation which is ordered by a Supervisory Authority to be paid to a Data Subject; and
  5. The reasonable costs of compliance with investigations by a Supervisory Authority.

Group Processors

Harri (US) LLC, a company registered in New York, trading from 611 Broadway Suite 3019, New York 10012 USA; and Harri Ramallah, a company registered in Palestine, trading from CGC Building, 6th Floor Al-Madaen Street, Ramallah.

International Data Transfer Agreement or IDTA

The Standard Data Protection Clauses issued by the UK Information Commissioner under S119 A(1) of the Data Protection Act 2018.

Job Seeker

Any user on the Harri Platform who inputs Personal Data into the Harri Platform for the purposes of seeking employment with the Customer or another employer.

Personal Data

Shall have the meaning given to it in the UK GDPR.

Personal Data Breach

Shall have the meaning given to it in the UK GDPR.

Processing

Shall have the meaning given to it in the UK GDPR.

Processor

Shall have the meaning given to it in the UK GDPR.

Project

The project, as described in the Statement of Work in Schedule 1.

Recruitment Profile

The profile created by the Job Seeker on the Harri Platform.

Sub-Processor

Any agent, subcontractor or other third party engaged by the Supplier or the Customer (as applicable) for carrying out any processing activities in respect of the Recruitment Profile or any other Personal Data of the Job Seeker or an employee of the Customer.

Supervisory Authority

Any regulator, authority or body responsible for administering Data Protection Laws.

Third Party Product

Any programme, application or software not developed or owned by the Supplier.

UK GDPR

The UK General Data Protection Regulation, Retained Regulation ((EU) 2016/679).

1. Controller and Processor

  1. 1.1 The parties agree that the Supplier is the Controller for the Recruitment Profile at all times.
  2. 1.2 The parties agree that the Supplier is the Processor and the Customer is the Controller for the Personal Data inputted into the Harri Solution and the Harri Platform by the Customer.

2. Customer Data

  1. 2.1 The Customer undertakes that:
    1. All data sourced by the Customer for use in connection with the Agreement, prior to such data being provided to or accessed by the Supplier for the performance of the Agreement, shall comply in all respects, including in terms of its collection, storage and processing (which shall include the Customer providing all of the required fair processing information to, and obtaining all necessary consents from, Data Subjects), with Data Protection Laws;
    2. All instructions given by it to the Supplier in respect of Personal Data shall at all times be in accordance with Data Protection Laws; and
    3. It has undertaken due diligence in relation to the Supplier’s processing operations, and it is satisfied that:
      1. The Supplier’s processing operations are suitable for the purposes for which the Customer proposes to use the services in the Agreement and engage the Supplier to process the Personal Data; and
      2. The Supplier has sufficient expertise, reliability and resources to implement technical and organisational measures that meet the requirements of Data Protection Laws.

3. Instructions and details of processing

  1. 3.1 The Supplier shall process the Personal Data only on and in accordance with the Customer’s documented instructions as set out in the Agreement, Section 1 of Part B of this Agreement and in the International Data Transfer Agreement (together, the Processing Instructions), as updated from time to time.
  2. 3.2 If Data Protection Laws require the Supplier to process Personal Data other than in accordance with the Processing Instructions, it shall notify the Customer of any such requirement before processing the Personal Data (unless Data Protection Laws prohibit such information on important grounds of public interest).
  3. 3.3 The Supplier shall immediately notify the Customer if, in the Supplier’s opinion, an instruction by the Customer infringes Data Protection Laws.

4. Security

  1. 4.1 The Supplier undertakes that it shall at all times implement and maintain, and shall each ensure that its own Sub-Processors shall implement and maintain, taking into account the state of the art, the costs of implementation, and the nature, scope and context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, appropriate technical and organisational measures to ensure a level of security of the Personal Data appropriate to the risk.
  2. 4.2 Such technical and organisational measures shall be at least equivalent to the technical and organisational measures set out in Section 2 of Part B of this Data Sharing Agreement and shall reflect the nature of the Personal Data.
  3. 4.3 If either party is in breach of its obligations under this Data Sharing Agreement, the other party may suspend the transfer of Personal Data to that party until the breach is remedied.

5. Sub-processing

  1. 5.1 The Customer gives the Supplier general written authorisation to appoint Sub-Processors, as required, in order to perform the services under the Agreement. The list of Sub-Processors can be found here:
  2. 5.2 The Supplier shall inform the Customer of any intended changes concerning the addition or replacement of other Sub-Processors, thereby giving the Supplier the opportunity to object to such changes, and such consent from the Customer will not be unreasonably withheld.
  3. 5.3 If the Customer has a reasonable objection to any new or replacement Sub-Processor, it shall notify the Supplier of such objections in writing within ten (10) days of the notification and the parties will seek to resolve the matter in good faith.
  4. 5.4 If the Supplier is reasonably able to provide the service to the Customer in accordance with the Schedule without using the Sub-Processor and decides in its discretion to do so, then the Customer will have no further rights under this clause in respect of the proposed use of the sub-processor.
  5. 5.5 If the Supplier requires use of the Sub-Processor in its discretion and is unable to satisfy the Customer as to the suitability of the Sub-Processor or the documentation and protections in place between the Supplier and the Sub-Processor within ninety (90) days from the Customer’s notification of objections, the Customer may within thirty (30) days following the end of the ninety (90) day period referred to above, terminate the part of the Schedule with at least thirty (30) days written notice, solely with respect to the service(s) to which the proposed new Sub-Processor’s processing of Personal Data relates.
  6. 5.6 If the Customer does not provide a timely objection to any new or replacement Sub-Processor in accordance with this clause, the Customer will be deemed to have consented to the Sub-Processor and waived its right to object.
  7. 5.7 The Supplier may use a new or replacement Sub-Processor whilst the objection procedure in this clause is in process.
  8. 5.8 Prior to the relevant Sub-Processor carrying out any processing activities in respect of the Personal Data, the Supplier shall appoint each Sub-Processor under a written contract containing materially the same obligations as under this Data Sharing Agreement.
  9. 5.9 The Supplier shall remain fully liable for all the acts and omissions of each Sub-Processor as if they were its own.
  10. 5.10 The Supplier shall ensure that all persons authorised by it (or by any Sub-Processor) to process Personal Data are subject to a binding written contractual obligation to keep the Personal Data confidential (except where disclosure is required in accordance with Data Protection Laws, in which case the Supplier shall, where practicable and not prohibited by Data Protection Laws, notify the Customer of any such requirement before such disclosure).

6. Personnel

  1. 6.1 The Supplier will ensure that access to Personal Data is limited to authorised persons who need access to it to the extent necessary to enable the Supplier to carry out its obligations under the Agreement, and only where they are subject to appropriate duties to keep such Personal Data secure and confidential.
  2. 6.2 The Supplier shall ensure that all personnel involved with the processing of Personal Data in accordance with this Data Sharing Agreement are reliable and adequately trained in Data Protection Law and compliant data handling processes as regards to their job role.

7. Data Transfers

  1. 7.1 Customer agrees that the Supplier may transfer Personal Data to countries outside the UK provided that all transfers by the Supplier of Personal Data shall be effected by way of appropriate safeguards and in accordance with Data Protection Laws. The provisions of this Data Sharing Agreement shall constitute the Customer’s instructions with respect to transfers in accordance with the Processing Instructions.
  2. 7.2 The Supplier warrants that:
    1. On or before the date of the Agreement it has (as Data Exporter) entered into the International Data Transfer Agreement with each of the Group Processors (as Data Importers) which covers the Personal Data processed in relation to the Agreement; and
    2. It shall not, and it shall procure that its Group Processors do not, terminate or otherwise cease to be bound by the International Data Transfer Agreement during the term of the Agreement.

8. Assistance

The Supplier shall:

  1. Without delay provide such information and assistance (including by taking all appropriate technical and organisational measures) as the Customer may reasonably require in relation to the fulfilment of the Customer’s obligations to respond to requests from Data Subjects for access to, rectification or erasure of Personal Data or any request to restrict or object to any processing of Personal Data;
  2. Provide to the other party or the relevant Supervisory Authority (as applicable) all information or assurances reasonably necessary to demonstrate compliance with its obligations under this Data Sharing Agreement and the Data Protection Laws.;
  3. Assist the Customer with any Data Protection Impact Assessments as may be reasonably required by the Customer in relation to the fulfilment of the Customer’s obligations under Data Protection Laws; and
  4. Provide the Customer with all information or assurances reasonably required to demonstrate compliance with its technical and organisational security measures under Data Protection Laws.

9. Records and audit

  1. 9.1 The Supplier shall maintain complete, accurate and up to date written records of all processing activities carried out with regards to the Personal Data inputted by the Customer into the Harri Platform and shall make such records available to the Customer and/or Supervisory Authority as appropriate.
  2. 9.2 The Supplier shall make available to the Customer such information as is reasonably necessary to demonstrate the Supplier’s compliance with its obligations under Article 28 of the UK GDPR (and under any Data Protection Laws equivalent to that Article 28), and allow for and contribute to audits, including inspections, by the Customer (or another auditor mandated by Customer) for this purpose, subject to the Customer:
    1. Giving the Supplier reasonable prior notice of such information request, audit and/or inspection being required by the Supplier;
    2. Ensuring that all information obtained or generated by the Customer or its auditor(s) in connection with such information requests, inspections and audits is kept strictly confidential (save for disclosure to the Supervisory Authority or as otherwise required; and
    3. Ensuring that such audit or inspection is undertaken during normal business hours, with minimal disruption to the Supplier’s business or the Sub-Processors’ business.
  3. 9.3 The Supplier may object to any third party auditor appointed by the Customer to conduct any audit if the auditor is, in the Supplier’s reasonable opinion, not suitably qualified or independent, a competitor of the Supplier or otherwise manifestly unsuitable. Any such objection by the Supplier will require the Customer to appoint another auditor or conduct the audit itself.
  4. 9.4 Nothing in this Data Sharing Agreement will require the Supplier either to disclose to the Customer or its third party auditor, or to allow the Customer or its third party auditor to access:
    1. Any data of any other customer of the Supplier; or
    2. Any of the Supplier’s internal accounting or financial information; or any trade secret of the Supplier.

10. Breach

  1. 10.1 The Supplier will notify the Customer without undue delay and, in any event, within 24 hours of becoming aware of any Personal Data Breach that involves the Personal Data inputted by the Customer for which the Supplier is a Processor.
  2. 10.2 The Supplier shall provide the following minimum details about a Personal Data Breach to the Customer:
    1. A description of the nature of the Personal Data breach including where possible, the categories and approximate number of Data Subjects affected and the categories and approximate number of Personal Data records concerned;
    2. Where possible, likely consequences of the Personal Data breach; and
    3. A description of the measures taken or proposed to be taken by that party to address the Personal Data breach, including measures to mitigate its adverse effect.

11. Deletion or return of Personal Data and copies

  1. 11.1 Upon termination or expiry of this Agreement, the Supplier shall, at the Customer’s written request, return all Personal Data to the Customer in a commonly used electronic format or, where no such request is made, securely delete the Personal Data, in each case within six (6) months of termination or expiry and subject to clause 11.2.
  2. 11.2 The Supplier may retain Personal Data to the extent required to comply with any applicable law or regulation, provided that the Supplier shall:
    1. Retain such Personal Data only for the period and to the extent required for such purpose;
    2. Ensure that such Personal Data remains subject to the confidentiality and security obligations set out in this Agreement and is not otherwise processed for any purpose; and
    3. Securely delete such Personal Data promptly following expiry of the applicable retention period.

12. Liability

  1. 12.1 The Supplier’s total liability to the Customer, whether in contract, tort (including negligence), for breach of statutory duty, or otherwise, arising under or in connection with this Data Sharing Agreement shall be limited to its liability under the Agreement.
  2. 12.2 The Customer shall indemnify and keep indemnified the Supplier in respect of all Data Protection Losses suffered or incurred by, awarded against or agreed to be paid by, the Supplier and any Sub-Processor arising from or in connection with any:
    1. Non-compliance by the Customer with the Data Protection Laws;
    2. Processing carried out by the Supplier or any Sub-Processor pursuant to any Processing Instruction that infringes any Data Protection Law; or
    3. Breach by the Customer of any of its obligations under this Data Sharing Agreement.
  3. 12.3 The Supplier shall be liable for Data Protection Losses (howsoever arising, whether in contract, tort (including negligence) or otherwise) under or in connection with this Data Sharing Agreement:
    1. Only to the extent caused by the processing of Personal Data under this Agreement and directly resulting from the Supplier’s breach; and
    2. In no circumstances to the extent that any Data Protection Losses (or the circumstances giving rise to them) are contributed to or caused by any breach of this Agreement by the Customer.
  4. 12.4 If a party receives a compensation claim from a person relating to processing of Personal Data, it shall promptly provide the other party with notice and full details of such claim. The party with conduct of the action shall:
    1. Make no admission of liability nor agree to any settlement or compromise of the relevant claim without the prior written consent of the other party (which shall not be unreasonably withheld or delayed); and
    2. Consult fully with the other party in relation to any such action, but the terms of any settlement or compromise of the claim will be exclusively the decision of the party that is responsible under this Data Sharing Agreement for paying the compensation.
  5. 12.5 The parties agree that the Customer shall not be entitled to claim back from the Supplier any part of any compensation paid by the Customer, in accordance with this clause.

Data processing and security details – Part B

Section 1—Data processing details

Processing of the Personal Data by the Supplier under this Data Sharing Agreement shall be for the subject-matter, duration, nature and purposes and involve the types of Personal Data and categories of Data Subjects set out in this Section 1.

Subject-matter of processing:

Personal data of natural persons who wish to create a recruitment profile using the Harri platform and apply for vacancies with the Customer or another employer.

The Personal Data will be processed by the Customer using the Harri software-as-a-service solution for the purposes of recruitment and talent management.

Duration of the processing:

The duration of the processing will be at the discretion of the Customer.

The Supplier will retain the recruitment profile of the Job Seeker for as long as he or she wishes.

Nature and purpose of the processing:

Harri (US) LLC is a provider of a software-as-a service talent recruitment and management solution which processes personal data upon the instructions of the Customer in accordance with the terms of the Services Agreement.

Type of Personal Data:

  1. First and last name
  2. Title
  3. Position
  4. Employer
  5. Contact information (home address, home phone, mobile phone, email)
  6. Education data
  7. Professional life data
  8. Employment data
  9. Personal life data
  10. Connection data
  11. Location data
  12. Criminal record data

Special categories of data

The personal data transferred concern the following special categories of data:

  1. Racial or ethnic origin
  2. Political opinions
  3. Religious or philosophical beliefs
  4. Trade union membership
  5. Genetic data
  6. Biometric data for the purpose of uniquely identifying a natural person
  7. Physical or mental health
  8. Sex life or sexual orientation
  9. Criminal convictions and offences

Categories of Data Subjects:

  1. Employees of the Customer
  2. Potential Employees of the Customer
  3. Former Employees of the Customer

Section 2—Minimum technical and organisational security measures

  1. 1. Without prejudice to its other obligations, the Supplier shall implement and maintain at least the following technical and organisational security measures to protect the Personal Data:
    1. 1.1 In accordance with the Data Protection Laws, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of the processing of the Personal Data to be carried out under or in connection with this Data Sharing Agreement, as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons and the risks that are presented by the processing, especially from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to the Personal Data transmitted, stored or otherwise processed, the Supplier shall implement appropriate technical and organisational security measures appropriate to the risk, including as appropriate those matters mentioned in Articles 32(1)(a) to 32(1)(d) (inclusive) of the UK GDPR.

International Data Transfer Agreement

VERSION A1.0, in force 21 March 2022

This IDTA has been issued by the Information Commissioner for Parties making Restricted Transfers. The Information Commissioner considers that it provides Appropriate Safeguards for Restricted Transfers when it is entered into as a legally binding contract.

Part 1: Tables

Table 1: Parties and signatures

Start date The start date of the Agreement
The Parties Exporter (who sends the Restricted Transfer) Importer (who receives the Restricted Transfer)
Parties’ details The Customer The Supplier

Table 2: Transfer Details

UK country’s law that governs the IDTA: England and Wales
Primary place for legal claims to be made by the Parties England and Wales
The status of the Exporter In relation to the Processing of the Transferred Data: Exporter is a Controller
The status of the Importer In relation to the Processing of the Transferred Data: Importer is the Exporter’s Processor or Sub-Processor
Whether UK GDPR applies to the Importer UK GDPR applies to the Importer’s Processing of the Transferred Data
Linked Agreement If the Importer is the Exporter’s Processor or Sub-Processor – the agreement(s) between the Parties which sets out the Processor’s or Sub-Processor’s instructions for Processing the Transferred Data: Name of agreement: Agreement Date of agreement: As set out in the Agreement Parties to the agreement:As set out in the Agreement Reference (if any):
Term The Importer may Process the Transferred Data for the duration of the Agreement
Ending the IDTA before the end of the Term The Parties cannot end the IDTA before the end of the Term unless there is a breach of the IDTA or the Parties agree in writing.
Ending the IDTA when the Approved IDTA changes Which Parties may end the IDTA as set out in Section ‎29.2: Importer Exporter
Can the Importer make further transfers of the Transferred Data? The Importer MAY transfer on the Transferred Data to another organisation or person (who is a different legal entity) in accordance with Section 16.1(Transferring on the Transferred Data).
Specific restrictions when the Importer may transfer on the Transferred Data The Importer MAY ONLY forward the Transferred Data in accordance with Section 16.1: there are no specific restrictions.
Review Dates The Parties must review the Security Requirements each time there is a change to the Transferred Data, Purposes, Importer Information, TRA or risk assessment

Table 3: Transferred Data

Transferred Data The personal data to be sent to the Importer under this IDTA consists of: The categories of Transferred Data will update automatically if the information is updated in the Linked Agreement referred to.
Special Categories of Personal Data and criminal convictions and offences The Transferred Data includes data relating to: racial or ethnic origin political opinions religious or philosophical beliefs trade union membership genetic data biometric data for the purpose of uniquely identifying a natural person physical or mental health sex life or sexual orientation criminal convictions and offences The categories of special category and criminal records data will update automatically if the information is updated in the Linked Agreement referred to.
Relevant Data Subjects The Data Subjects of the Transferred Data are: The categories of Data Subjects will update automatically if the information is updated in the Linked Agreement referred to.
Purpose The Importer may Process the Transferred Data for the purposes of providing the services as described in the Agreement and any other purposes which are compatible with the purposes set in the Agreement. The purposes will update automatically if the information is updated in the Linked Agreement referred to.

Table 4: Security Requirements

Security of Transmission Data is encrypted at rest and in transit. Harri sends data over HTTPS (TLSv1 and above) encrypted connections as data transits to and from our services. VPN secure socket layer and other in encryption technologies are used for defined points of connectivity. Server certificate based authentication is used as part of the SSL / TLS encryption with a trusted certificate authority.
Security of Storage In particular, regarding file storage encryption, we encrypt the data-sensitive files by using the industry standard AES-256 with managed keys. All our data sources (including relational and non-relational DBs) are encrypted using the industry standard AES-256 with managed keys. Harri retains data for 35 days by default after which the data is deleted without additional archiving. Harri leverages AWS backup features by taking automated online backups that are seamless and do not require any downtime. There are multiple backup policies depending upon the nature and criticality of the data, varying from point- in-time recovery to schedule backups, and all is done without affecting the performance of the system. Harri uses Amazon S3 to store customer data. S3 provides a highly durable storage infrastructure as well as data retention through versioning. Harri also utilises cross region replication and can fallback to a different region in case of a full region failure including all its availability zones. For database needs, Harri uses Amazon RDS features in both the preparation phase and recovery phase for DR. Amazon RDS gives the ability to scale in multiple availability zones and to snapshot data as well as having read replicas in multiple availability zones. In addition, Harry uses Amazon DynamoDB for non-relational databases during their recovery phrase, Harri can scale up easily in a matter of minutes with just a single click.
Security of Processing Harri uses Amazon Machine Images along with prepared configuration scripts so that Harri can launch servers as part of their recovery procedure. Moreover, Harri makes sure that servers are running in distinct locations (called availability zones) to protect microservices from the failure of a single location. In terms of networking, failing over to another site when dealing with a disaster is seamless. Harri uses Amazon Route 53, a Domain Name System (DNS) web service to route their users to their services. Also, Harri achieves greater fault tolerance in their application and services by means of using elastic load balancing by providing load balancing capacity that is needed in response to incoming traffic, which can simplify the execution of their DR plan. Harri uses virtual networking using Amazon PrivateCloud service to isolate their resources into subnets, enabling a complete control over the networking environment, including selection ofIP addresses, creation of subnets and route table configuration.
Organisational security measures IT policies and procedures exist that describe physical security,logical access, computer operations, change control and data communication standards. All teams are expected to adhere to Harri policies and procedures that define how services should be delivered these are located on Harri’s internet and can be accessed by any team member Harri is ISO 27001 and SOC 2 certified, in order to gain this certification Harri has the following policies in place to ensure internal IT and IT security: Information security policy Information security objectives Information Security risk assessment and risk treatment plans Management reviews Asset inventory Acceptable usage policy Operating procedures for IT management Vendor security policy Logs of user activities, exceptions and security events
Technical security minimum requirements Measures of pseudonymisation and encryption of personal data VPN secure socket layer and other in encryption technologies are used for defined points of connectivity. Server certificate based authentication is used as part of the SSL / TLS encryption with a trusted certificate authority. Customer data is encrypted whilst both at rest and in transit. Measures for ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and service Computer operations – backups Harri leverages AWS backup features by taking automated online backups that are seamless and do not require any downtime. There are multiple backup policies depending upon the nature and criticality of the data, varying from point- in-time recovery to schedule backups, and all is done without affecting the performance of the system. Particularly, the following types of backups are used: RDS (relational DBs) Frequency: daily Type of backup: storage volume full back up for the whole RDS on S3 which is managed by AWS RDS Retention:35 days DynamoDB (non-relational DBs) Type of backup: support both on-demand and continuous backups. S3 (file storage): Harri utilises a highly durable storage as well as data retention through versioning in S3. The backups are enabled through the cross-region replication. Computer operations- availability Harri’s platform is fault tolerant by design. Harri uses AWS, a cloud computing provider, and its infrastructure to build and run our services. AWS support the features required for handling the cases of disaster recovery (DR). Harri considers the use of services and features that support data migration and durable storage, which enables the ability to restore backed up and ensure critical data when a disaster occurs. Harri reacts to a disaster by either quickly commissioning compute resources to run our services or orchestrating the failover to already running resources. Harri is designed and built to be highly available. This includes data centre, compute resources and customer data. AWS implement high availability taking into consideration perimeter, infrastructure, data and environmental layers. There are multiple layers and services that aid in the preparation and execution for DR implemented in Harri. These can be categorised as follows. Compute and infrastructure availability: Harri is a multi-tiered system whose components are built using both server and serverless computing technologies. The services that Harri provides are designed based on microservices architectural pattern. This helps increasing availability by separating failures into multiple domains, which will reduce the probability of total system failure. All Harri microservices are designed for both vertical and horizontal scaling using many AWS EC2 features including load balancers,auto scaling groups and auto recovery of failed nodes. To ensure high availability on infrastructure, multiple availability zones for all kinds of compute nodes are used. Within minutes, the user has the ability to create AWS EC2 instances, which is critical in the context ofDR. Harri uses Amazon Machine Images along with prepared configuration scripts so that Harri can launch servers as part of their recovery procedure. Moreover, Harri makes sure that servers are running in distinct locations (called availability zones) to protect microservices from the failure of a single location. In terms of networking, failing over to another site when dealing with a disaster is seamless. Harri uses Amazon Route 53, a Domain Name System (DNS) web service to route their users to their services. Also, Harri achieves greater fault tolerance in their application and services by means of using elastic load balancing by providing load balancing capacity that is needed in response to incoming traffic, which can simplify the execution of their DR plan. Harri uses virtual networking using Amazon PrivateCloud service to isolate their resources into subnets, enabling a complete control over the networking environment, including selection of IP addresses, creation of subnets and route table configuration. Data availability: The data sources of Harri are also distributed in multiple availability zones and implement both asynchronous replication to multiple sources. This includes both relational and non relational database systems. Harri also implements daily backups for its systems and point-in-time recovery for the most critical components and data where AWS supports. Harri uses Amazon S3 to store customer data. S3 provides a highly durable storage infrastructure as well as data retention through versioning. Harri also utilises cross region replication and can fallback to a different region in case of a full region failure including all its availability zones. For database needs, Harri uses Amazon RDS features in both the preparation phase and recovery phase for DR. Amazon RDS gives the ability to scale in multiple availability zones and to snapshot data as well as having read replicas in multiple availability zones. In addition, Harry uses Amazon DynamoDB for non-relational databases during their recovery phrase, Harri can scale up easily in a matter of minutes with just a single click. Measures for ensuring the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident A business continuity and disaster recovery plan is documented to identify and reduce risks, limit the consequences of damaging incidents and ensure the timely resumption of essential operations the disaster recovery plan is tested on an annual basis. The business continuity and disaster recovery plan and procedures are updated based on disaster recovery plan test results. Processes for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures in order to ensure the security of the processing A third party performs penetration testing annually to identify vulnerabilities within the environment and remedial actions are taken when necessary . Harri conducts security penetration testing through Whitehat security where they can identify whether their applications are vulnerable to web attacks and implement the required countermeasures to reduce vulnerability. This testing is done by performing business logic assessments. These assessments uncover flaws in application business logic including: clickjacking,cross site scripting,cross site request forgery, embedded Flash and Silverlight modules, Structured Query Language (SQL) injection and information leakage. Measures for user identification and authorisation Harri support user-based and role-based access controls. Harri has a permissions platform that oversees managing users and permissions. Particularly, it facilitates creating users, roles and groups as well as assigning permissions. A Harri user (either jobseeker employer) is authenticated by entering a valid email and password in order to log into their Harri profiles. The DevOps team is responsible for creating accounts for Harri’s employees on AWS. Employees sign in into AWS using basic authentication with multi-factor authentication (MFA). Harri manages employees’ access to AWS accounts and services by using AWSidentity and access management (IAM) service where Harri securely controls access to AWS resources. Harry uses AWS IAM to control who is authenticated and authorised to use resources. Some developers have a programmatic access to AWS using KeyID and Secret Key.The employees are required to rotate their keys every three months. Employees accessing Harri’s private resource from outside the office are required to connect to Harri’s virtual private network (VPN) using their VPN credentials. In order for them to connect to the VPN, their Internet Protocol (IP) address must first be added into theVPNs firewall inbound list. Whenever an employee terminates employment with the company, Harri deactivates all the employee’s profiles and/or delete all of the employee’s permissions. Measures for the protection of data during transmission There is use of encryption technologies to protect customer data both at rest and in transit. Measures for the protection of data during storage There is use of encryption technologies to protect customer data both at rest and in transit. Measures for ensuring physical security of locations at which personal data are processed The wholly occupied company facilities are protected by walls around the entire perimeter. Access to the reception area of the building is unlocked from 7am to 7pn on business days and is locked at all other times. Visitors check in with the receptionist or security guard stationed in the reception area. Visitors must present a valid government issued photo identification card. The visitor’s name, employer and purpose for the visit are recorded in a visitor log. The visitor is issued a temporary IDbadge to be worn throughout the visit Access to the Harry office is restricted by key access before and after business hours. Each employee is given a key upon hire. Upon an employee’s termination of employment, the Human Resources Department will revoke the key from the employee. Measures for ensuring events logging An intrusion detection system is utilised to analyse network events and report possible or actual network security breaches the IDS is configured to notify personnel upon intrusion detection. Anti-virus software is installed on workstations to detect and prevent the transmission of data or files that contain certain virus signatures recognised by the anti-virus software Measures for ensuring system configuration, including default configuration Harri uses Amazon Machine Images along with prepared configuration scripts so that Harri can launch servers as part of their recovery procedure. Management has defined configuration standards in the information security policies and procedures. Measures for internal IT and IT security governance and management IT policies and procedures exist that describe physical security,logical access, computer operations, change control and data communication standards. All teams are expected to adhere to Harri policies and procedures that define how services should be delivered these are located on Harri’s internet and can be accessed by any team member Harri is ISO 27001 and SOC 2 certified, in order to gain this certification Harri has policies in place to ensure internal ITand IT security rating procedures for IT management Vendor securitypolicy Logs of user activities, exceptions and security events Measures for certification/assurance of processes and products Harri has SOC2 and ISO 27001 certification. Measures for ensuring data minimisation The amount of data stored in the Harri systems is dependent upon the client. Measures for ensuring data quality The continuous integration and continuous deployment practices that are followed in Harri enable the quality assurance team to begin testing as soon as a shippable product is ready. This allows developers to fix the bugs as soon as they are reported by the testing team resulting in a product of high quality with almost zero bugs. Measures for ensuring limited data retention Harri uses Amazon S3 to store customer data. S3 provides a highly durable storage infrastructure as well as data retention through versioning. Data is only retained for as long as required to perform the required system functionality, service or use. Measures for ensuring accountability Harri’s assignment of authority and responsibility activities include factors such as how authority and responsibility for operating activities are assigned and how reporting relationships and authorisation hierarchies are established. It also includes policies relating to appropriate business practices, knowledge, and experience of key personnel, and resources provided for carrying out duties. In addition it includes policies and communications directed at ensuring personnel understand the entity’s objectives, know how their individual actions interrelate and contribute to those objectives, and recognise how and for what they will be held accountable Specific control activities that Harri has implemented include organisational charts that are in place to communicate key areas of authority and responsibility, which are communicated to staff and updated. Measures for allowing data portability and ensuring erasure Harri’s systems do not allow for data portability. Erasure tickets — all external users of Harri’s software can submit a ticket to request that their data is deleted. Upon receipt of the ticket the team will delete all data which is not required by to be retained by the client. Sub -processors Harri has data sharing agreements with all sub-processors that require the sub-processor to ;provide assistance to the controller (data exporter).
Updates to the Security Requirements The Security Requirements will update automatically if the information is updated in the Linked Agreement referred to.

Part 2: Extra Protection Clauses

Extra Protection Clauses: Not applicable
(i) Extra technical security protections
(ii) Extra organisational protections
(iii) Extra contractual protections

Part 3: Commercial Clauses

Commercial Clauses Not applicable

Part 4: Mandatory Clauses

Information that helps you to understand this IDTA

1. This IDTA and Linked Agreements

  1. 1.1 Each Party agrees to be bound by the terms and conditions set out in the IDTA, in exchange for the other Party also agreeing to be bound by the IDTA.
  2. 1.2 This IDTA is made up of:
    1. Part one: Tables;
    2. Part two: Extra Protection Clauses;
    3. Part three: Commercial Clauses; and
    4. Part four: Mandatory Clauses.
  3. 1.3 The IDTA starts on the Start Date and ends as set out in Sections 29 or 30.
  4. 1.4 If the Importer is a Processor or Sub-Processor instructed by the Exporter: the Exporter must ensure that, on or before the Start Date and during the Term, there is a Linked Agreement which is enforceable between the Parties and which complies with Article 28 UK GDPR (and which they will ensure continues to comply with Article 28 UK GDPR).
  5. 1.5 References to the Linked Agreement or to the Commercial Clauses are to that Linked Agreement or to those Commercial Clauses only in so far as they are consistent with the Mandatory Clauses.

2. Legal Meaning of Words

  1. 2.1 If a word starts with a capital letter it has the specific meaning set out in the Legal Glossary in Section 36.
  2. 2.2 To make it easier to read and understand, this IDTA contains headings and guidance notes. Those are not part of the binding contract which forms the IDTA.

3. You have provided all the information required

  1. 3.1 The Parties must ensure that the information contained in Part one: Tables is correct and complete at the Start Date and during the Term.
  2. 3.2 In Table 2: Transfer Details, if the selection that the Parties are Controllers, Processors or Sub-Processors is wrong (either as a matter of fact or as a result of applying the UK Data Protection Laws) then:
    1. The terms and conditions of the Approved IDTA which apply to the correct option which was not selected will apply; and
    2. The Parties and any Relevant Data Subjects are entitled to enforce the terms and conditions of the Approved IDTA which apply to that correct option.
  3. 3.3 In Table 2: Transfer Details, if the selection that the UK GDPR applies is wrong (either as a matter of fact or as a result of applying the UK Data Protection Laws), then the terms and conditions of the IDTA will still apply to the greatest extent possible.

4. How to sign the IDTA

  1. 4.1 The Parties may choose to each sign (or execute):
    1. The same copy of this IDTA;
    2. Two copies of the IDTA. In that case, each identical copy is still an original of this IDTA, and together all those copies form one agreement;
    3. A separate, identical copy of the IDTA. In that case, each identical copy is still an original of this IDTA, and together all those copies form one agreement,

Unless signing (or executing) in this way would mean that the IDTA would not be binding on the Parties under Local Laws.

5. Changing this IDTA

  1. 5.1 Each Party must not change the Mandatory Clauses as set out in the Approved IDTA, except only:
    1. To ensure correct cross-referencing: cross-references to Part one: Tables (or any Table), Part two: Extra Protections, and/or Part three: Commercial Clauses can be changed where the Parties have set out the information in a different format, so that the cross-reference is to the correct location of the same information, or where clauses have been removed as they do not apply, as set out below;
    2. To remove those Sections which are expressly stated not to apply to the selections made by the Parties in Table 2: Transfer Details, that the Parties are Controllers, Processors or Sub-Processors and/or that the Importer is subject to, or not subject to, the UK GDPR. The Exporter and Importer understand and acknowledge that any removed Sections may still apply and form a part of this IDTA if they have been removed incorrectly, including because the wrong selection is made in Table 2: Transfer Details;
    3. So the IDTA operates as a multi-party agreement if there are more than two Parties to the IDTA. This may include nominating a lead Party or lead Parties which can make decisions on behalf of some or all of the other Parties which relate to this IDTA (including reviewing Table 4: Security Requirements and Part two: Extra Protection Clauses, and making updates to Part one: Tables (or any Table), Part two: Extra Protection Clauses, and/or Part three: Commercial Clauses); and/or
    4. To update the IDTA to set out in writing any changes made to the Approved IDTA under Section 5.4, if the Parties want to. The changes will apply automatically without updating them as described in Section 5.4;

Provided that the changes do not reduce the Appropriate Safeguards.

  1. 5.2 If the Parties wish to change the format of the information included in Part one: Tables, Part two: Extra Protection Clauses or Part three: Commercial Clauses of the Approved IDTA, they may do so by agreeing to the change in writing, provided that the change does not reduce the Appropriate Safeguards.
  2. 5.3 If the Parties wish to change the information included in Part one: Tables, Part two: Extra Protection Clauses or Part three: Commercial Clauses of this IDTA (or the equivalent information), they may do so by agreeing to the change in writing, provided that the change does not reduce the Appropriate Safeguards.
  3. 5.4 From time to time, the ICO may publish a revised Approved IDTA which:
    1. Makes reasonable and proportionate changes to the Approved IDTA, including correcting errors in the Approved IDTA; and/or
    2. Reflects changes to UK Data Protection Laws.

The revised Approved IDTA will specify the start date from which the changes to the Approved IDTA are effective and whether an additional Review Date is required as a result of the changes. This IDTA is automatically amended as set out in the revised Approved IDTA from the start date specified.

6. Understanding this IDTA

  1. 6.1 This IDTA must always be interpreted in a manner that is consistent with UK Data Protection Laws and so that it fulfils the Parties’ obligation to provide the Appropriate Safeguards.
  2. 6.2 If there is any inconsistency or conflict between UK Data Protection Laws and this IDTA, the UK Data Protection Laws apply.
  3. 6.3 If the meaning of the IDTA is unclear or there is more than one meaning, the meaning which most closely aligns with the UK Data Protection Laws applies.
  4. 6.4 Nothing in the IDTA (including the Commercial Clauses or the Linked Agreement) limits or excludes either Party’s liability to Relevant Data Subjects or to the ICO under this IDTA or under UK Data Protection Laws.
  5. 6.5 If any wording in Parts one, two or three contradicts the Mandatory Clauses, and/or seeks to limit or exclude any liability to Relevant Data Subjects or to the ICO, then that wording will not apply.
  6. 6.6 The Parties may include provisions in the Linked Agreement which provide the Parties with enhanced rights otherwise covered by this IDTA. These enhanced rights may be subject to commercial terms, including payment, under the Linked Agreement, but this will not affect the rights granted under this IDTA.
  7. 6.7 If there is any inconsistency or conflict between this IDTA and a Linked Agreement or any other agreement, this IDTA overrides that Linked Agreement or any other agreements, even if those agreements have been negotiated by the Parties. The exceptions to this are where (and in so far as):
    1. The inconsistent or conflicting terms of the Linked Agreement or other agreement provide greater protection for the Relevant Data Subject’s rights, in which case those terms will override the IDTA; and
    2. A Party acts as Processor and the inconsistent or conflicting terms of the Linked Agreement are obligations on that Party expressly required by Article 28 UK GDPR, in which case those terms will override the inconsistent or conflicting terms of the IDTA in relation to Processing by that Party as Processor.
  8. 6.8 The words “include”, “includes”, “including”, “in particular” are used to set out examples and not to set out a finite list.
  9. 6.9 References to:
    1. Singular or plural words or people, also includes the plural or singular of those words or people;
    2. Legislation (or specific provisions of legislation) means that legislation (or specific provision) as it may change over time. This includes where that legislation (or specific provision) has been consolidated, re-enacted and/or replaced after this IDTA has been signed; and
    3. Any obligation not to do something, includes an obligation not to allow or cause that thing to be done by anyone else.

7. Which laws apply to this IDTA

  1. 7.1 This IDTA is governed by the laws of the UK country set out in Table 2: Transfer Details. If no selection has been made, it is the laws of England and Wales. This does not apply to Section 35which is always governed by the laws of England and Wales.

How this IDTA provides Appropriate Safeguards

8. The Appropriate Safeguards

  1. 8.1 The purpose of this IDTA is to ensure that the Transferred Data has Appropriate Safeguards when Processed by the Importer during the Term. This standard is met when and for so long as:
    1. Both Parties comply with the IDTA, including the Security Requirements and any Extra Protection Clauses; and
    2. The Security Requirements and any Extra Protection Clauses provide a level of security which is appropriate to the risk of a Personal Data Breach occurring and the impact on Relevant Data Subjects of such a Personal Data Breach, including considering any Special Category Data within the Transferred Data.
  2. 8.2 The Exporter must:
    1. Ensure and demonstrate that this IDTA (including any Security Requirements and Extra Protection Clauses) provides Appropriate Safeguards; and
    2. (if the Importer reasonably requests) provide it with a copy of any TRA.
  3. 8.3 The Importer must:
    1. Before receiving any Transferred Data, provide the Exporter with all relevant information regarding Local Laws and practices and the protections and risks which apply to the Transferred Data when it is Processed by the Importer, including any information which may reasonably be required for the Exporter to carry out any TRA (the “Importer Information”);
    2. Co-operate with the Exporter to ensure compliance with the Exporter’s obligations under the UK Data Protection Laws;
    3. Review whether any Importer Information has changed, and whether any Local Laws contradict its obligations in this IDTA and take reasonable steps to verify this, on a regular basis. These reviews must be at least as frequent as the Review Dates; and
    4. Inform the Exporter as soon as it becomes aware of any Importer Information changing, and/or any Local Laws which may prevent or limit the Importer complying with its obligations in this IDTA. This information then forms part of the Importer Information.
  4. 8.4 The Importer must ensure that at the Start Date and during the Term:
    1. The Importer Information is accurate;
    2. It has taken reasonable steps to verify whether there are any Local Laws which contradict its obligations in this IDTA or any additional information regarding Local Laws which may be relevant to this IDTA.
  5. 8.5 Each Party must ensure that the Security Requirements and Extra Protection Clauses provide a level of security which is appropriate to the risk of a Personal Data Breach occurring and the impact on Relevant Data Subjects of such a Personal Data Breach.

9. Reviews to ensure the Appropriate Safeguards continue

  1. 9.1 Each Party must:
    1. Review this IDTA (including the Security Requirements and Extra Protection Clauses and the Importer Information) at regular intervals, to ensure that the IDTA remains accurate and up to date and continues to provide the Appropriate Safeguards. Each Party will carry out these reviews as frequently as the relevant Review Dates or sooner; and
    2. Inform the other party in writing as soon as it becomes aware if any information contained in either this IDTA, any TRA or Importer Information is no longer accurate and up to date.
  2. 9.2 If, at any time, the IDTA no longer provides Appropriate Safeguards the Parties must Without Undue Delay:
    1. Pause transfers and Processing of Transferred Data whilst a change to the Tables is agreed. The Importer may retain a copy of the Transferred Data during this pause, in which case the Importer must carry out any Processing required to maintain, so far as possible, the measures it was taking to achieve the Appropriate Safeguards prior to the time the IDTA no longer provided Appropriate Safeguards, but no other Processing;
    2. Agree a change to Part one: Tables or Part two: Extra Protection Clauses which will maintain the Appropriate Safeguards (in accordance with Section 5); and
    3. Where a change to Part one: Tables or Part two: Extra Protection Clauses which maintains the Appropriate Safeguards cannot be agreed, the Exporter must end this IDTA by written notice on the Importer.

10. The ICO

  1. 10.1 Each Party agrees to comply with any reasonable requests made by the ICO in relation to this IDTA or its Processing of the Transferred Data.
  2. 10.2 The Exporter will provide a copy of any TRA, the Importer Information and this IDTA to the ICO, if the ICO requests.
  3. 10.3 The Importer will provide a copy of any Importer Information and this IDTA to the ICO, if the ICO requests.

The Exporter

11. Exporter’s obligations

  1. 11.1 The Exporter agrees that UK Data Protection Laws apply to its Processing of the Transferred Data, including transferring it to the Importer.
  2. 11.2 The Exporter must:
    1. Comply with the UK Data Protection Laws in transferring the Transferred Data to the Importer;
    2. Comply with the Linked Agreement as it relates to its transferring the Transferred Data to the Importer; and
    3. Carry out reasonable checks on the Importer’s ability to comply with this IDTA, and take appropriate action including under Section 9.2, Section 29 or Section 30, if at any time it no longer considers that the Importer is able to comply with this IDTA or to provide Appropriate Safeguards.
  3. 11.3 The Exporter must comply with all its obligations in the IDTA, including any in the Security Requirements, and any Extra Protection Clauses and any Commercial Clauses.
  4. 11.4 The Exporter must co-operate with reasonable requests of the Importer to pass on notices or other information to and from Relevant Data Subjects or any Third Party Controller where it is not reasonably practical for the Importer to do so. The Exporter may pass these on via a third party if it is reasonable to do so.
  5. 11.5 The Exporter must co-operate with and provide reasonable assistance to the Importer, so that the Importer is able to comply with its obligations to the Relevant Data Subjects under Local Law and this IDTA.

The Importer

12. General Importer obligations

  1. 12.1 The Importer must:
    1. Only Process the Transferred Data for the Purpose;
    2. Comply with all its obligations in the IDTA, including in the Security Requirements, any Extra Protection Clauses and any Commercial Clauses;
    3. Comply with all its obligations in the Linked Agreement which relate to its Processing of the Transferred Data;
    4. Keep a written record of its Processing of the Transferred Data, which demonstrate its compliance with this IDTA, and provide this written record if asked to do so by the Exporter;
    5. If the Linked Agreement includes rights for the Exporter to obtain information or carry out an audit, provide the Exporter with the same rights in relation to this IDTA; and
    6. If the ICO requests, provide the ICO with the information it would be required on request to provide to the Exporter under this Section 12.1 (including the written record of its Processing, and the results of audits and inspections).
  2. 12.2 The Importer must co-operate with and provide reasonable assistance to the Exporter and any Third Party Controller, so that the Exporter and any Third Party Controller are able to comply with their obligations under UK Data Protection Laws and this IDTA.

13. Importer’s obligations if it is subject to the UK Data Protection Laws

  1. 13.1 If the Importer’s Processing of the Transferred Data is subject to UK Data Protection Laws, it agrees that:
    1. UK Data Protection Laws apply to its Processing of the Transferred Data, and the ICO has jurisdiction over it in that respect; and
    2. It has and will comply with the UK Data Protection Laws in relation to the Processing of the Transferred Data.
  2. 13.2 If Section 13.1 applies and the Importer complies with Section 13.1, it does not need to comply with:
    • Section 14 (Importer’s obligations to comply with key data protection principles);
    • Section 15 (What happens if there is an Importer Personal Data Breach);
    • Section 15 (How Relevant Data Subjects can exercise their data subject rights); and
    • Section 21 (How Relevant Data Subjects can exercise their data subject rights – if the Importer is the Exporter’s Processor or Sub-Processor).

14. Importer’s obligations to comply with key data protection principles

  1. 14.1 The Importer does not need to comply with this Section 14 if it is the Exporter’s Processor or Sub-Processor.
  2. 14.2 The Importer must:
    1. Ensure that the Transferred Data it Processes is adequate, relevant and limited to what is necessary for the Purpose;
    2. Ensure that the Transferred Data it Processes is accurate and (where necessary) kept up to date, and (where appropriate considering the Purposes) correct or delete any inaccurate Transferred Data it becomes aware of Without Undue Delay; and
    3. Ensure that it Processes the Transferred Data for no longer than is reasonably necessary for the Purpose.

15. What happens if there is an Importer Personal Data Breach

  1. 15.1 If there is an Importer Personal Data Breach, the Importer must:
    1. Take reasonable steps to fix it, including to minimise the harmful effects on Relevant Data Subjects, stop it from continuing, and prevent it happening again. If the Importer is the Exporter’s Processor or Sub-Processor: these steps must comply with the Exporter’s instructions and the Linked Agreement and be in co-operation with the Exporter and any Third Party Controller; and
    2. Ensure that the Security Requirements continue to provide (or are changed in accordance with this IDTA so they do provide) a level of security which is appropriate to the risk of a Personal Data Breach occurring and the impact on Relevant Data Subjects of such a Personal Data Breach.
  2. 15.2 If the Importer is a Processor or Sub-Processor: if there is an Importer Personal Data Breach, the Importer must:
    1. Notify the Exporter Without Undue Delay after becoming aware of the breach, providing the following information:
      1. A description of the nature of the Importer Personal Data Breach;
      2. (if and when possible) the categories and approximate number of Data Subjects and Transferred Data records concerned;
      3. Likely consequences of the Importer Personal Data Breach;
      4. Steps taken (or proposed to be taken) to fix the Importer Personal Data Breach (including to minimise the harmful effects on Relevant Data Subjects, stop it from continuing, and prevent it happening again) and to ensure that Appropriate Safeguards are in place;
      5. Contact point for more information; and
      6. Any other information reasonably requested by the Exporter,
    2. If it is not possible for the Importer to provide all the above information at the same time, it may do so in phases, Without Undue Delay; and
    3. Assist the Exporter (and any Third Party Controller) so the Exporter (or any Third Party Controller) can inform Relevant Data Subjects or the ICO or any other relevant regulator or authority about the Importer Personal Data Breach Without Undue Delay.
  3. 15.3 If the Importer is a Controller: if the Importer Personal Data Breach is likely to result in a risk to the rights or freedoms of any Relevant Data Subject the Importer must notify the Exporter Without Undue Delay after becoming aware of the breach, providing the following information:
    1. A description of the nature of the Importer Personal Data Breach;
    2. (if and when possible) the categories and approximate number of Data Subjects and Transferred Data records concerned;
    3. Likely consequences of the Importer Personal Data Breach;
    4. Steps taken (or proposed to be taken) to fix the Importer Personal Data Breach (including to minimise the harmful effects on Relevant Data Subjects, stop it from continuing, and prevent it happening again) and to ensure that Appropriate Safeguards are in place;
    5. Contact point for more information; and
    6. Any other information reasonably requested by the Exporter.

If it is not possible for the Importer to provide all the above information at the same time, it may do so in phases, Without Undue Delay.

  1. 15.4 If the Importer is a Controller: if the Importer Personal Data Breach is likely to result in a high risk to the rights or freedoms of any Relevant Data Subject, the Importer must inform those Relevant Data Subjects Without Undue Delay, except in so far as it requires disproportionate effort, and provided the Importer ensures that there is a public communication or similar measures whereby Relevant Data Subjects are informed in an equally effective manner.
  2. 15.5 The Importer must keep a written record of all relevant facts relating to the Importer Personal Data Breach, which it will provide to the Exporter and the ICO on request.

This record must include the steps it takes to fix the Importer Personal Data Breach (including to minimise the harmful effects on Relevant Data Subjects, stop it from continuing, and prevent it happening again) and to ensure that Security Requirements continue to provide a level of security which is appropriate to the risk of a Personal Data Breach occurring and the impact on Relevant Data Subjects of such a Personal Data Breach.

16. Transferring on the Transferred Data

  1. 16.1 The Importer may only transfer on the Transferred Data to a third party if it is permitted to do so in Table 2: Transfer Details Table, the transfer is for the Purpose, the transfer does not breach the Linked Agreement, and one or more of the following apply:
    1. The third party has entered into a written contract with the Importer containing the same level of protection for Data Subjects as contained in this IDTA (based on the role of the recipient as controller or processor), and the Importer has conducted a risk assessment to ensure that the Appropriate Safeguards will be protected by that contract; or
    2. The third party has been added to this IDTA as a Party; or
    3. If the Importer was in the UK, transferring on the Transferred Data would comply with Article 46 UK GDPR; or
    4. If the Importer was in the UK transferring on the Transferred Data would comply with one of the exceptions in Article 49 UK GDPR; or
    5. The transfer is to the UK or an Adequate Country.
  2. 16.2 The Importer does not need to comply with Section 16.1 if it is transferring on Transferred Data and/or allowing access to the Transferred Data in accordance with Section 23 (Access Requests and Direct Access).

17. Importer’s responsibility if it authorises others to perform its obligations

  1. 17.1 The Importer may sub-contract its obligations in this IDTA to a Processor or Sub-Processor (provided it complies with Section 16).
  2. 17.2 If the Importer is the Exporter’s Processor or Sub-Processor: it must also comply with the Linked Agreement or be with the written consent of the Exporter.
  3. 17.3 The Importer must ensure that any person or third party acting under its authority, including a Processor or Sub-Processor, must only Process the Transferred Data on its instructions.
  4. 17.4 The Importer remains fully liable to the Exporter, the ICO and Relevant Data Subjects for its obligations under this IDTA where it has sub-contracted any obligations to its Processors and Sub-Processors, or authorised an employee or other person to perform them (and references to the Importer in this context will include references to its Processors, Sub-Processors or authorised persons).

What rights do individuals have?

18. The right to a copy of the IDTA

  1. 18.1 If a Party receives a request from a Relevant Data Subject for a copy of this IDTA:
    1. It will provide the IDTA to the Relevant Data Subject and inform the other Party, as soon as reasonably possible;
    2. It does not need to provide copies of the Linked Agreement, but it must provide all the information from those Linked Agreements referenced in the Tables;
    3. It may redact information in the Tables or the information provided from the Linked Agreement if it is reasonably necessary to protect business secrets or confidential information, so long as it provides the Relevant Data Subject with a summary of those redactions so that the Relevant Data Subject can understand the content of the Tables or the information provided from the Linked Agreement.

19. The right to Information about the Importer and its Processing

  1. 19.1 The Importer does not need to comply with this Section 19 if it is the Exporter’s Processor or Sub-Processor.
  2. 19.2 The Importer must ensure that each Relevant Data Subject is provided with details of:
    • The Importer (including contact details and the Importer Data Subject Contact);
    • The Purposes; and
    • Any recipients (or categories of recipients) of the Transferred Data;

The Importer can demonstrate it has complied with this Section 19.2 if the information is given (or has already been given) to the Relevant Data Subjects by the Exporter or another party.

The Importer does not need to comply with this Section 19.2 in so far as to do so would be impossible or involve a disproportionate effort, in which case, the Importer must make the information publicly available.

  1. 19.3 The Importer must keep the details of the Importer Data Subject Contact up to date and publicly available. This includes notifying the Exporter in writing of any such changes.
  2. 19.4 The Importer must make sure those contact details are always easy to access for all Relevant Data Subjects and be able to easily communicate with Data Subjects in the English language Without Undue Delay.

20. How Relevant Data Subjects can exercise their data subject rights

  1. 20.1 The Importer does not need to comply with this Section 20 if it is the Exporter’s Processor or Sub-Processor.
  2. 20.2 If an individual requests, the Importer must confirm whether it is Processing their Personal Data as part of the Transferred Data.
  3. 20.3 The following Sections of this Section 20, relate to a Relevant Data Subject’s Personal Data which forms part of the Transferred Data the Importer is Processing.
  4. 20.4 If the Relevant Data Subject requests, the Importer must provide them with a copy of their Transferred Data:
    1. Without Undue Delay (and in any event within one month);
    2. At no greater cost to the Relevant Data Subject than it would be able to charge if it were subject to the UK Data Protection Laws;
    3. In clear and plain English that is easy to understand; and
    4. In an easily accessible form

    Together with

    1. (if needed) a clear and plain English explanation of the Transferred Data so that it is understandable to the Relevant Data Subject; and
    2. Information that the Relevant Data Subject has the right to bring a claim for compensation under this IDTA.
  1. 20.5 If a Relevant Data Subject requests, the Importer must:
    1. Rectify inaccurate or incomplete Transferred Data;
    2. Erase Transferred Data if it is being Processed in breach of this IDTA;
    3. Cease using it for direct marketing purposes; and
    4. Comply with any other reasonable request of the Relevant Data Subject, which the Importer would be required to comply with if it were subject to the UK Data Protection Laws.
  2. 20.6 The Importer must not use the Transferred Data to make decisions about the Relevant Data Subject based solely on automated processing, including profiling (the “Decision-Making”), which produce legal effects concerning the Relevant Data Subject or similarly significantly affects them, except if it is permitted by Local Law and:
    1. The Relevant Data Subject has given their explicit consent to such Decision-Making; or
    2. Local Law has safeguards which provide sufficiently similar protection for the Relevant Data Subjects in relation to such Decision-Making, as to the relevant protection the Relevant Data Subject would have if such Decision-Making was in the UK; or
    3. The Extra Protection Clauses provide safeguards for the Decision-Making which provide sufficiently similar protection for the Relevant Data Subjects in relation to such Decision-Making, as to the relevant protection the Relevant Data Subject would have if such Decision-Making was in the UK.

21. How Relevant Data Subjects can exercise their data subject rights– if the Importer is the Exporter’s Processor or Sub-Processor

  1. 21.1 Where the Importer is the Exporter’s Processor or Sub-Processor: If the Importer receives a request directly from an individual which relates to the Transferred Data it must pass that request on to the Exporter Without Undue Delay. The Importer must only respond to that individual as authorised by the Exporter or any Third Party Controller.

22. Rights of Relevant Data Subjects are subject to the exemptions in the UK Data Protection Laws

  1. 22.1 The Importer is not required to respond to requests or provide information or notifications under Sections 18, 19, 20, 21 and 23 if:
    1. It is unable to reasonably verify the identity of an individual making the request; or
    2. The requests are manifestly unfounded or excessive, including where requests are repetitive. In that case the Importer may refuse the request or may charge the Relevant Data Subject a reasonable fee; or
    3. A relevant exemption would be available under UK Data Protection Laws, were the Importer subject to the UK Data Protection Laws.

If the Importer refuses an individual’s request or charges a fee under Section 22.1.2 it will set out in writing the reasons for its refusal or charge, and inform the Relevant Data Subject that they are entitled to bring a claim for compensation under this IDTA in the case of any breach of this IDTA.

How to give third parties access to Transferred Data under Local Laws

23. Access requests and direct access

  1. 23.1 In this Section ‎23 an “Access Request” is a legally binding request (except for requests only binding by contract law) to access any Transferred Data and “Direct Access” means direct access to any Transferred Data by public authorities of which the Importer is aware.
  2. 23.2 The Importer may disclose any requested Transferred Data in so far as it receives an Access Request, unless in the circumstances it is reasonable for it to challenge that Access Request on the basis there are significant grounds to believe that it is unlawful.
  3. 23.3 In so far as Local Laws allow and it is reasonable to do so, the Importer will Without Undue Delay provide the following with relevant information about any Access Request or Direct Access: the Exporter; any Third Party Controller; and where the Importer is a Controller, any Relevant Data Subjects.
  4. 23.4 In so far as Local Laws allow, the Importer must:
    1. Make and keep a written record of Access Requests and Direct Access, including (if known): the dates, the identity of the requestor/accessor, the purpose of the Access Request or Direct Access, the type of data requested or accessed, whether it was challenged or appealed, and the outcome; and the Transferred Data which was provided or accessed; and
    2. Provide a copy of this written record to the Exporter on each Review Date and any time the Exporter or the ICO reasonably requests.

24. Giving notice

  1. 24.1 If a Party is required to notify any other Party in this IDTA it will be marked for the attention of the relevant Key Contact and sent by e-mail to the e-mail address given for the Key Contact.
  2. 24.2 If the notice is sent in accordance with Section 24.1, it will be deemed to have been delivered at the time the e-mail was sent, or if that time is outside of the receiving Party’s normal business hours, the receiving Party’s next normal business day, and provided no notice of non-delivery or bounceback is received.
  3. 24.3 The Parties agree that any Party can update their Key Contact details by giving 14 days’ (or more) notice in writing to the other Party.

25. General clauses

  1. 25.1 In relation to the transfer of the Transferred Data to the Importer and the Importer’s Processing of the Transferred Data, this IDTA and any Linked Agreement:
    1. Contain all the terms and conditions agreed by the Parties; and
    2. Override all previous contacts and arrangements, whether oral or in writing.
  2. 25.2 If one Party made any oral or written statements to the other before entering into this IDTA (which are not written in this IDTA) the other Party confirms that it has not relied on those statements and that it will not have a legal remedy if those statements are untrue or incorrect, unless the statement was made fraudulently.
  3. 25.3 Neither Party may novate, assign or obtain a legal charge over this IDTA (in whole or in part) without the written consent of the other Party, which may be set out in the Linked Agreement.
  4. 25.4 Except as set out in Section 17.1, neither Party may sub contract its obligations under this IDTA without the written consent of the other Party, which may be set out in the Linked Agreement.
  5. 25.5 This IDTA does not make the Parties a partnership, nor appoint one Party to act as the agent of the other Party.
  6. 25.6 If any Section (or part of a Section) of this IDTA is or becomes illegal, invalid or unenforceable, that will not affect the legality, validity and enforceability of any other Section (or the rest of that Section) of this IDTA.
  7. 25.7 If a Party does not enforce, or delays enforcing, its rights or remedies under or in relation to this IDTA, this will not be a waiver of those rights or remedies. In addition, it will not restrict that Party’s ability to enforce those or any other right or remedy in future.
  8. 25.8 If a Party chooses to waive enforcing a right or remedy under or in relation to this IDTA, then this waiver will only be effective if it is made in writing. Where a Party provides such a written waiver:
    1. It only applies in so far as it explicitly waives specific rights or remedies;
    2. It shall not prevent that Party from exercising those rights or remedies in the future (unless it has explicitly waived its ability to do so); and
    3. It will not prevent that Party from enforcing any other right or remedy in future.

What happens if there is a breach of this IDTA?

26. Breaches of this IDTA

  1. 26.1 Each Party must notify the other Party in writing (and with all relevant details) if it:
    1. Has breached this IDTA; or
    2. It should reasonably anticipate that it may breach this IDTA, and provide any information about this which the other Party reasonably requests.
  2. 26.2 In this IDTA “Significant Harmful Impact” means that there is more than a minimal risk of a breach of the IDTA causing (directly or indirectly) significant damage to any Relevant Data Subject or the other Party.

27. Breaches of this IDTA by the Importer

  1. 27.1 If the Importer has breached this IDTA, and this has a Significant Harmful Impact, the Importer must take steps Without Undue Delay to end the Significant Harmful Impact, and if that is not possible to reduce the Significant Harmful Impact as much as possible.
  2. 27.2 Until there is no ongoing Significant Harmful Impact on Relevant Data Subjects:
    1. The Exporter must suspend sending Transferred Data to the Importer;
    2. If the Importer is the Exporter’s Processor or Sub-Processor: if the Exporter requests, the importer must securely delete all Transferred Data or securely return it to the Exporter (or a third party named by the Exporter); and
    3. If the Importer has transferred on the Transferred Data to a third party receiver under Section 16, and the breach has a Significant Harmful Impact on Relevant Data Subject when it is Processed by or on behalf of that third party receiver, the Importer must:
      1. Notify the third party receiver of the breach and suspend sending it Transferred Data; and
      2. If the third party receiver is the Importer’s Processor or Sub-Processor: make the third party receiver securely delete all Transferred Data being Processed by it or on its behalf, or securely return it to the Importer (or a third party named by the Importer).
  3. 27.3 If the breach cannot be corrected Without Undue Delay, so there is no ongoing Significant Harmful Impact on Relevant Data Subjects, the Exporter must end this IDTA under Section 30.1.

28. Breaches of this IDTA by the Exporter

  1. 28.1 If the Exporter has breached this IDTA, and this has a Significant Harmful Impact, the Exporter must take steps Without Undue Delay to end the Significant Harmful Impact and if that is not possible to reduce the Significant Harmful Impact as much as possible.
  2. 28.2 Until there is no ongoing risk of a Significant Harmful Impact on Relevant Data Subjects, the Exporter must suspend sending Transferred Data to the Importer.
  3. 28.3 If the breach cannot be corrected Without Undue Delay, so there is no ongoing Significant Harmful Impact on Relevant Data Subjects, the Importer must end this IDTA under Section 30.1.

Ending the IDTA

29. How to end this IDTA without there being a breach

  1. 29.1 The IDTA will end:
    1. At the end of the Term stated in Table 2: Transfer Details; or
    2. If in Table 2: Transfer Details, the Parties can end this IDTA by providing written notice to the other: at the end of the notice period stated;
    3. At any time that the Parties agree in writing that it will end; or
    4. At the time set out in Section ‎29.2.
  2. 29.2 If the ICO issues a revised Approved IDTA under Section ‎5.4, if any Party selected in Table 2 “Ending the IDTA when the Approved IDTA changes”, will as a direct result of the changes in the Approved IDTA have a substantial, disproportionate and demonstrable increase in:
    1. Its direct costs of performing its obligations under the IDTA; and/or
    2. Its risk under the IDTA,

And in either case it has first taken reasonable steps to reduce that cost or risk so that it is not substantial and disproportionate, that Party may end the IDTA at the end of a reasonable notice period, by providing written notice for that period to the other Party before the start date of the revised Approved IDTA.

30. How to end this IDTA if there is a breach

  1. 30.1 A Party may end this IDTA immediately by giving the other Party written notice if:
    1. The other Party has breached this IDTA and this has a Significant Harmful Impact. This includes repeated minor breaches which taken together have a Significant Harmful Impact, and
      1. The breach can be corrected so there is no Significant Harmful Impact, and the other Party has failed to do so Without Undue Delay (which cannot be more than 14 days of being required to do so in writing); or
      2. The breach and its Significant Harmful Impact cannot be corrected;
    2. The Importer can no longer comply with Section 8.3, as there are Local Laws which mean it cannot comply with this IDTA and this has a Significant Harmful Impact.

31. What must the Parties do when the IDTA ends?

  1. 31.1 If the parties wish to bring this IDTA to an end or this IDTA ends in accordance with any provision in this IDTA, but the Importer must comply with a Local Law which requires it to continue to keep any Transferred Data then this IDTA will remain in force in respect of any retained Transferred Data for as long as the retained Transferred Data is retained, and the Importer must:
    1. Notify the Exporter Without Undue Delay, including details of the relevant Local Law and the required retention period;
    2. Retain only the minimum amount of Transferred Data it needs to comply with that Local Law, and the Parties must ensure they maintain the Appropriate Safeguards, and change the Tables and Extra Protection Clauses, together with any TRA to reflect this; and
    3. Stop Processing the Transferred Data as soon as permitted by that Local Law and the IDTA will then end and the rest of this Section 29 will apply.
  2. 31.2 When this IDTA ends (no matter what the reason is):
    1. The Exporter must stop sending Transferred Data to the Importer; and
    2. If the Importer is the Exporter’s Processor or Sub-Processor: the Importer must delete all Transferred Data or securely return it to the Exporter (or a third party named by the Exporter), as instructed by the Exporter;
    3. If the Importer is a Controller and/or not the Exporter’s Processor or Sub-Processor: the Importer must securely delete all Transferred Data.
    4. The following provisions will continue in force after this IDTA ends (no matter what the reason is):
      • Section 1 (This IDTA and Linked Agreements);
      • Section 2 (Legal Meaning of Words);
      • Section 6 (Understanding this IDTA);
      • Section 7 (Which laws apply to this IDTA);
      • Section 10 (The ICO);
      • Sections 11.1 and 11.4 (Exporter’s obligations);
      • Sections 12.1.2, 12.1.3, 12.1.4, 12.1.5 and 12.1.6 (General Importer obligations);
      • Section 13.1 (Importer’s obligations if it is subject to UK Data Protection Laws);
      • Section 17 (Importer’s responsibility if it authorised others to perform its obligations);
      • Section 24 (Giving notice);
      • Section 25 (General clauses);
      • Section 31 (What must the Parties do when the IDTA ends);
      • Section 32 (Your liability);
      • Section 33 (How Relevant Data Subjects and the ICO may bring legal claims);
      • Section 34 (Courts legal claims can be brought in);
      • Section 35 (Arbitration); and
      • Section 36 (Legal Glossary).

How to bring a legal claim under this IDTA

32. Your liability

  1. 32.1 The Parties remain fully liable to Relevant Data Subjects for fulfilling their obligations under this IDTA and (if they apply) under UK Data Protection Laws.
  2. 32.2 Each Party (in this Section, “Party One”) agrees to be fully liable to Relevant Data Subjects for the entire damage suffered by the Relevant Data Subject, caused directly or indirectly by:
    1. Party One’s breach of this IDTA; and/or
    2. Where Party One is a Processor, Party One’s breach of any provisions regarding its Processing of the Transferred Data in the Linked Agreement;
    3. Where Party One is a Controller, a breach of this IDTA by the other Party if it involves Party One’s Processing of the Transferred Data (no matter how minimal)

In each case unless Party One can prove it is not in any way responsible for the event giving rise to the damage.

  1. 32.3 If one Party has paid compensation to a Relevant Data Subject under Section 32.2, it is entitled to claim back from the other Party that part of the compensation corresponding to the other Party’s responsibility for the damage, so that the compensation is fairly divided between the Parties.
  2. 32.4 The Parties do not exclude or restrict their liability under this IDTA or UK Data Protection Laws, on the basis that they have authorised anyone who is not a Party (including a Processor) to perform any of their obligations, and they will remain responsible for performing those obligations.

33. How Relevant Data Subjects and the ICO may bring legal claims

  1. 33.1 The Relevant Data Subjects are entitled to bring claims against the Exporter and/or Importer for breach of the following (including where their Processing of the Transferred Data is involved in a breach of the following by either Party):
    • Section 1 (This IDTA and Linked Agreements);
    • Section 3 (You have provided all the information required by Part one: Tables and Part two: Extra Protection Clauses);
    • Section 8 (The Appropriate Safeguards);
    • Section 9 (Reviews to ensure the Appropriate Safeguards continue);
    • Section 11 (Exporter’s obligations);
    • Section 12 (General Importer Obligations);
    • Section 13 (Importer’s obligations if it is subject to UK Data Protection Laws);
    • Section 14 (Importer’s obligations to comply with key data protection laws);
    • Section 15 (What happens if there is an Importer Personal Data Breach);
    • Section 16 (Transferring on the Transferred Data);
    • Section 17 (Importer’s responsibility if it authorises others to perform its obligations);
    • Section 18 (The right to a copy of the IDTA);
    • Section 19 (The Importer’s contact details for the Relevant Data Subjects);
    • Section 20 (How Relevant Data Subjects can exercise their data subject rights);
    • Section 21 (How Relevant Data Subjects can exercise their data subject rights– if the Importer is the Exporter’s Processor or Sub-Processor);
    • Section 23 (Access Requests and Direct Access);
    • Section 26 (Breaches of this IDTA);
    • Section 27 (Breaches of this IDTA by the Importer);
    • Section 28 (Breaches of this IDTA by the Exporter);
    • Section 30 (How to end this IDTA if there is a breach);
    • Section 31 (What must the Parties do when the IDTA ends); and
    • Any other provision of the IDTA which expressly or by implication benefits the Relevant Data Subjects.
  2. 33.2 The ICO is entitled to bring claims against the Exporter and/or Importer for breach of the following Sections: Section 10 (The ICO), Sections 11.1 and 11.2 (Exporter’s obligations), Section 12.1.6 (General Importer obligations) and Section 13 (Importer’s obligations if it is subject to UK Data Protection Laws).
  3. 33.3 No one else (who is not a Party) can enforce any part of this IDTA (including under the Contracts (Rights of Third Parties) Act 1999).
  4. 33.4 The Parties do not need the consent of any Relevant Data Subject or the ICO to make changes to this IDTA, but any changes must be made in accordance with its terms.
  5. 33.5 In bringing a claim under this IDTA, a Relevant Data Subject may be represented by a not-for-profit body, organisation or association under the same conditions set out in Article 80(1) UK GDPR and sections 187 to 190 of the Data Protection Act 2018.

34. Courts legal claims can be brought in

  1. 34.1 The courts of the UK country set out in Table 2: Transfer Details have non-exclusive jurisdiction over any claim in connection with this IDTA (including non-contractual claims).
  2. 34.2 The Exporter may bring a claim against the Importer in connection with this IDTA (including non-contractual claims) in any court in any country with jurisdiction to hear the claim.
  3. 34.3 The Importer may only bring a claim against the Exporter in connection with this IDTA (including non-contractual claims) in the courts of the UK country set out in the Table 2: Transfer Details
  4. 34.4 Relevant Data Subjects and the ICO may bring a claim against the Exporter and/or the Importer in connection with this IDTA (including non-contractual claims) in any court in any country with jurisdiction to hear the claim.
  5. 34.5 Each Party agrees to provide to the other Party reasonable updates about any claims or complaints brought against it by a Relevant Data Subject or the ICO in connection with the Transferred Data (including claims in arbitration).

35. Arbitration

  1. 35.1 Instead of bringing a claim in a court under Section 34, any Party, or a Relevant Data Subject may elect to refer any dispute arising out of or in connection with this IDTA (including non-contractual claims) to final resolution by arbitration under the Rules of the London Court of International Arbitration, and those Rules are deemed to be incorporated by reference into this Section ‎35.
  2. 35.2 The Parties agree to submit to any arbitration started by another Party or by a Relevant Data Subject in accordance with this Section ‎‎35.
  3. 35.3 There must be only one arbitrator. The arbitrator (1) must be a lawyer qualified to practice law in one or more of England and Wales, or Scotland, or Northern Ireland and (2) must have experience of acting or advising on disputes relating to UK Data Protection Laws.
  4. 35.4 London shall be the seat or legal place of arbitration. It does not matter if the Parties selected a different UK country as the ‘primary place for legal claims to be made’ in Table 2: Transfer Details.
  5. 35.5 The English language must be used in the arbitral proceedings.
  6. 35.6 English law governs this Section ‎‎35. This applies regardless of whether or not the parties selected a different UK country’s law as the ‘UK country’s law that governs the IDTA’ in Table 2: Transfer Details.

36. Legal Glossary

Word or Phrase Legal definition (this is how this word or phrase must be interpreted in the IDTA)
Access Request As defined in Section 23, as a legally binding request (except for requests only binding by contract law) to access any Transferred Data.
Adequate Country A third country, or: · a territory; · one or more sectors or organisations within a third country; · an international organisation; which the Secretary of State has specified by regulations provides an adequate level of protection of Personal Data in accordance with Section 17A of the Data Protection Act 2018.
Appropriate Safeguards The standard of protection over the Transferred Data and of the Relevant Data Subject’s rights, which is required by UK Data Protection Laws when you are making a Restricted Transfer relying on standard data protection clauses under Article 46(2)(d) UK GDPR.
Approved IDTA The template IDTA A1.0 issued by the ICO and laid before Parliament in accordance with s119A of the Data Protection Act 2018 on 2 February 2022, as it is revised under Section 5.4.
Commercial Clauses The commercial clauses set out in Part three.
Controller As defined in the UK GDPR.
Damage All material and non-material loss and damage.
Data Subject As defined in the UK GDPR.
Decision-Making As defined in Section 20.6, as decisions about the Relevant Data Subjects based solely on automated processing, including profiling, using the Transferred Data.
Direct Access As defined in Section 23 as direct access to any Transferred Data by public authorities of which the Importer is aware.
Exporter The exporter identified in Table 1: Parties & Signature.
Extra Protection Clauses The clauses set out in Part two: Extra Protection Clauses.
ICO The Information Commissioner.
Importer The importer identified in Table 1: Parties & Signature.
Importer Data Subject Contact The Importer Data Subject Contact identified in Table 1: Parties & Signature, which may be updated in accordance with Section 19.
Importer Information As defined in Section 8.3.1, as all relevant information regarding Local Laws and practices and the protections and risks which apply to the Transferred Data when it is Processed by the Importer, including for the Exporter to carry out any TRA.
Importer Personal Data Breach A ‘personal data breach’ as defined in UK GDPR, in relation to the Transferred Data when Processed by the Importer.
Linked Agreement The linked agreements set out in Table 2: Transfer Details (if any).
Local Laws Laws which are not the laws of the UK and which bind the Importer.
Mandatory Clauses Part four: Mandatory Clauses of this IDTA.
Notice Period As set out in Table 2: Transfer Details.
Party/Parties The parties to this IDTA as set out in Table 1: Parties & Signature.
Personal Data As defined in the UK GDPR.
Personal Data Breach As defined in the UK GDPR.
Processing As defined in the UK GDPR. When the IDTA refers to Processing by the Importer, this includes where a third party Sub-Processor of the Importer is Processing on the Importer’s behalf.
Processor As defined in the UK GDPR.
Purpose The ‘Purpose’ set out in Table 2: Transfer Details, including any purposes which are not incompatible with the purposes stated or referred to.
Relevant Data Subject A Data Subject of the Transferred Data.
Restricted Transfer A transfer which is covered by Chapter V of the UK GDPR
Review Dates The review dates or period for the Security Requirements set out in Table 2: Transfer Details, and any review dates set out in any revised Approved IDTA.
Significant Harmful Impact As defined in Section 26.2 as where there is more than a minimal risk of the breach causing (directly or indirectly) significant harm to any Relevant Data Subject or the other Party.
Special Category Data As described in the UK GDPR, together with criminal conviction or criminal offence data.
Start Date As set out in Table 1: Parties and signature.
Sub-Processor A Processor appointed by another Processor to Process Personal Data on its behalf. This includes Sub-Processors of any level, for example a Sub-Sub-Processor.
Tables The Tables set out in Part one of this IDTA.
Term As set out in Table 2: Transfer Details.
Third Party Controller The Controller of the Transferred Data where the Exporter is a Processor or Sub-Processor If there is not a Third Party Controller this can be disregarded.
Transfer Risk Assessment or TRA A risk assessment in so far as it is required by UK Data Protection Laws to demonstrate that the IDTA provides the Appropriate Safeguards
Transferred Data Any Personal Data which the Parties transfer, or intend to transfer under this IDTA, as described in Table 2: Transfer Details
UK Data Protection Laws All laws relating to data protection, the processing of personal data, privacy and/or electronic communications in force from time to time in the UK, including the UK GDPR and the Data Protection Act 2018.
UK GDPR As defined in Section 3 of the Data Protection Act 2018.
Without Undue Delay Without undue delay, as that phase is interpreted in the UK GDPR.