Haku
Book a demo
Data Processing Agreement

Annex II — Technical and Organisational Security Measures

Haku Labs Ltd · Company number 16248507 ← Back to the DPA

This Annex forms part of, and is incorporated into, the Data Processing Agreement between the Controller and the Processor (the "DPA"). It describes the technical and organisational measures implemented by the Processor pursuant to clause 5.3 of the DPA to ensure a level of security appropriate to the risk. Terms defined in the DPA have the same meaning in this Annex.

In accordance with clause 5.3, the Processor may modify or update these measures provided that no such change results in a material degradation of the overall security of the Services.

1. Access Control and Authentication

1.1 Authentication is centralised on a dedicated identity provider operated by the Processor. All access to the Services requires authentication.

1.2 Multi-factor authentication is enforced for all administrative access, and is available to all Authorised Users. Automated protection against credential brute-force attack is enabled.

1.3 Role-based access control separates platform administrators, organisation administrators, managers and standard users. Data access is scoped to the Authorised User's organisation at the data access layer, so that a user of one organisation cannot address the data of another.

1.4 Support impersonation of an Authorised User is restricted to platform administrators, is cryptographically signed, is limited in duration, and is recorded in an audit trail identifying the administrator, the impersonated user and the period of access. Credentials and session tokens are never written to application logs.

1.5 Access to production infrastructure and to the production database is restricted to named personnel on a least-privilege basis, is granted only for as long as the role requires it, and is revoked on role change or departure.

1.6 Production credentials, vendor API keys and signing secrets are held in protected environment configuration on the deployment host. They are not committed to source control and are not present in application logs or error reports.

2. Encryption

2.1 All traffic between Authorised Users and the Services is encrypted in transit using TLS 1.3.

2.2 All traffic between the Services and Sub-processors is encrypted in transit using TLS.

2.3 Traffic between the application and the primary database is encrypted in transit using TLS with full server certificate verification.

2.4 Data at rest in the primary database and in backups is encrypted using AES-256 at the storage layer.

2.5 In addition to storage-layer encryption, secrets held within the database are encrypted at field level using AES-256 with a key held in application configuration and never within the database. This applies to sending mailbox credentials and to access tokens for the Controller's connected customer relationship management systems, such that disclosure of the database alone does not yield usable credentials.

2.6 Identifiers held on the data subject suppression list are stored only as keyed HMAC-SHA256 digests, with the key held in application configuration and never within the database. Disclosure of that table therefore reveals nothing about the identity of the data subjects concerned.

3. Data Segregation and Minimisation

3.1 All Controller Personal Data is segregated by organisation identifier, and access is scoped to the authenticated Authorised User's organisation.

3.2 Exclusion lists derived from the Controller's customer relationship management system, which identify the companies the Controller already does business with, are applied within the Services and are not transmitted to any data provider.

3.3 Personal Data is excluded from application logs and operational telemetry. Log output is restricted to record identifiers and non-identifying operational fields.

3.4 Where a data subject is present on the suppression list, they are excluded before any chargeable enrichment or sourcing operation is performed, and are checked again at record creation and immediately before any outbound communication is sent. A failed suppression lookup withholds the communication and does not alter the record.

3.5 The volume of Personal Data disclosed to any Sub-processor is limited to that necessary for the purpose for which the Sub-processor is engaged, as described in Annex III.

3.6 Call recording. Recording of telephone calls placed through the Services is disabled by default. It is enabled only at organisation level, and only where the Controller has confirmed that it has established a lawful basis and will give any notice or obtain any consent required by the Data Protection Laws of the jurisdictions in which it calls. Recordings and any transcripts derived from calls are retained in accordance with Annex I and are accessible only to Authorised Users of the Controller's own organisation.

4. Resilience, Backup and Recovery

4.1 The primary database is backed up daily. Backups are encrypted at rest and are retained on a 35-day rolling basis, after which they are destroyed as part of the ordinary data lifecycle referred to in clause 8.3 of the DPA.

4.2 Restoration from backup is tested at least once every six months, and the outcome of each test is recorded.

4.3 Application services are deployed in containers and can be rebuilt and redeployed from source without reference to the state of any individual host.

4.4 Database schema changes are applied by an audited migration runner which produces a dry-run plan before commit, records each applied migration in a ledger, and aborts the deployment on failure so that the prior code and schema remain in service.

5. Sub-processor and Vendor Management

5.1 Each Sub-processor listed in Annex III is engaged under a written agreement imposing data protection obligations substantially equivalent to those imposed on the Processor under the DPA.

5.2 The Processor maintains a register recording, for each Sub-processor, the executed data protection agreement and its date, the categories of Personal Data disclosed, the destination country, the transfer mechanism relied upon and, where applicable, the vendor's Data Privacy Framework certification status.

5.3 Transfers to Sub-processors outside the United Kingdom and the EEA are made under the mechanisms set out in Annex IV. The Processor conducts and documents a transfer risk assessment for each such transfer to a country not the subject of an adequacy decision, and applies supplementary measures where the assessment requires them.

5.4 Where inference services are used in connection with Controller Personal Data, the Processor uses a self-hosted model deployed on infrastructure under its own control within the EEA, so that Controller Personal Data is processed transiently and is not retained by, or used to train the models of, any third-party inference provider.

5.5 New Sub-processors are notified to the Controller in accordance with clause 5.4.2 of the DPA.

6. Personnel

6.1 Personnel with access to Personal Data are subject to written confidentiality obligations that survive the end of their engagement.

6.2 Access is granted on a least-privilege basis on joining or on change of role, is reviewed periodically, and is revoked on departure.

6.3 Personnel receive data protection and security awareness training appropriate to their role, on appointment and periodically thereafter.

6.4 The Processor has appointed a Data Protection Lead with responsibility for compliance with the Data Protection Laws, whose details are set out on the cover page of the DPA.

7. Incident Detection and Response

7.1 Application and infrastructure telemetry is collected and retained for operational monitoring and incident investigation.

7.2 The Processor maintains a documented incident response procedure covering detection, triage, containment, assessment, notification, remediation and post-incident review, and identifying the personnel responsible at each stage.

7.3 Confirmed Personal Data Breaches affecting Controller Personal Data are notified to the Controller in accordance with clause 5.6 of the DPA, without undue delay and in any event within seventy-two (72) hours of confirmation.

7.4 A post-incident review is completed for every confirmed Personal Data Breach, and the resulting remedial actions are tracked to completion.

8. Data Subject Rights and Suppression

8.1 The Processor operates a documented procedure for handling data subject requests, comprising intake, identity resolution, an impact assessment, authorisation by the Data Protection Lead, execution, and confirmation.

8.2 Requests are recorded in a durable ledger which is retained for accountability purposes under Article 5(2) UK GDPR independently of, and for longer than, the data to which the request relates. The plaintext identifiers of the data subject are held only while the request is in progress and are removed on completion, leaving a keyed digest and a masked reference as the permanent record.

8.3 Access requests are fulfilled by producing a complete export of the data subject's Personal Data across every system in which it is held, in a commonly used machine-readable format.

8.4 Erasure and objection requests are executed across every system in which the data subject's Personal Data is held, and the number of records removed from each is recorded in the ledger as evidence of completion.

8.5 On completion of an erasure or objection request, the minimum identifiers necessary to recognise the data subject are placed on a suppression list, so that they are not re-collected, re-enriched or contacted again. Enforcement is described at paragraph 3.4.

8.6 The Processor makes available to the Controller a list of data subjects who have exercised an erasure or objection right in respect of the Services, so that the Controller may give effect to the request within its own systems.

9. Secure Development and Change Management

9.1 All changes to the Services are made on separate branches and are merged only through reviewed pull requests. Direct commits to the production branch are prohibited.

9.2 An automated build and test suite runs on every pull request, and every pull request additionally receives an automated code review.

9.3 Each pull request is deployed to an isolated per-branch environment for verification before merge.

9.4 An end-to-end regression suite runs nightly against a deployed environment, and failures are triaged before the next release.

9.5 Dependencies are monitored for known vulnerabilities and are updated on a risk-assessed basis.

10. Review

10.1 These measures are reviewed at least annually, and on any material change to the Services, the categories of Personal Data processed, or the Sub-processors engaged.

Annex II - Technical and Organisational Security Measures — Haku
Data Processing Agreement

Annex II — Technical and Organisational Security Measures

Haku Labs Ltd · Company number 16248507 ← Back to the DPA

This Annex forms part of, and is incorporated into, the Data Processing Agreement between the Controller and the Processor (the "DPA"). It describes the technical and organisational measures implemented by the Processor pursuant to clause 5.3 of the DPA to ensure a level of security appropriate to the risk. Terms defined in the DPA have the same meaning in this Annex.

In accordance with clause 5.3, the Processor may modify or update these measures provided that no such change results in a material degradation of the overall security of the Services.

1. Access Control and Authentication

1.1 Authentication is centralised on a dedicated identity provider operated by the Processor. All access to the Services requires authentication.

1.2 Multi-factor authentication is enforced for all administrative access, and is available to all Authorised Users. Automated protection against credential brute-force attack is enabled.

1.3 Role-based access control separates platform administrators, organisation administrators, managers and standard users. Data access is scoped to the Authorised User's organisation at the data access layer, so that a user of one organisation cannot address the data of another.

1.4 Support impersonation of an Authorised User is restricted to platform administrators, is cryptographically signed, is limited in duration, and is recorded in an audit trail identifying the administrator, the impersonated user and the period of access. Credentials and session tokens are never written to application logs.

1.5 Access to production infrastructure and to the production database is restricted to named personnel on a least-privilege basis, is granted only for as long as the role requires it, and is revoked on role change or departure.

1.6 Production credentials, vendor API keys and signing secrets are held in protected environment configuration on the deployment host. They are not committed to source control and are not present in application logs or error reports.

2. Encryption

2.1 All traffic between Authorised Users and the Services is encrypted in transit using TLS 1.3.

2.2 All traffic between the Services and Sub-processors is encrypted in transit using TLS.

2.3 Traffic between the application and the primary database is encrypted in transit using TLS with full server certificate verification.

2.4 Data at rest in the primary database and in backups is encrypted using AES-256 at the storage layer.

2.5 In addition to storage-layer encryption, secrets held within the database are encrypted at field level using AES-256 with a key held in application configuration and never within the database. This applies to sending mailbox credentials and to access tokens for the Controller's connected customer relationship management systems, such that disclosure of the database alone does not yield usable credentials.

2.6 Identifiers held on the data subject suppression list are stored only as keyed HMAC-SHA256 digests, with the key held in application configuration and never within the database. Disclosure of that table therefore reveals nothing about the identity of the data subjects concerned.

3. Data Segregation and Minimisation

3.1 All Controller Personal Data is segregated by organisation identifier, and access is scoped to the authenticated Authorised User's organisation.

3.2 Exclusion lists derived from the Controller's customer relationship management system, which identify the companies the Controller already does business with, are applied within the Services and are not transmitted to any data provider.

3.3 Personal Data is excluded from application logs and operational telemetry. Log output is restricted to record identifiers and non-identifying operational fields.

3.4 Where a data subject is present on the suppression list, they are excluded before any chargeable enrichment or sourcing operation is performed, and are checked again at record creation and immediately before any outbound communication is sent. A failed suppression lookup withholds the communication and does not alter the record.

3.5 The volume of Personal Data disclosed to any Sub-processor is limited to that necessary for the purpose for which the Sub-processor is engaged, as described in Annex III.

3.6 Call recording. Recording of telephone calls placed through the Services is disabled by default. It is enabled only at organisation level, and only where the Controller has confirmed that it has established a lawful basis and will give any notice or obtain any consent required by the Data Protection Laws of the jurisdictions in which it calls. Recordings and any transcripts derived from calls are retained in accordance with Annex I and are accessible only to Authorised Users of the Controller's own organisation.

4. Resilience, Backup and Recovery

4.1 The primary database is backed up daily. Backups are encrypted at rest and are retained on a 35-day rolling basis, after which they are destroyed as part of the ordinary data lifecycle referred to in clause 8.3 of the DPA.

4.2 Restoration from backup is tested at least once every six months, and the outcome of each test is recorded.

4.3 Application services are deployed in containers and can be rebuilt and redeployed from source without reference to the state of any individual host.

4.4 Database schema changes are applied by an audited migration runner which produces a dry-run plan before commit, records each applied migration in a ledger, and aborts the deployment on failure so that the prior code and schema remain in service.

5. Sub-processor and Vendor Management

5.1 Each Sub-processor listed in Annex III is engaged under a written agreement imposing data protection obligations substantially equivalent to those imposed on the Processor under the DPA.

5.2 The Processor maintains a register recording, for each Sub-processor, the executed data protection agreement and its date, the categories of Personal Data disclosed, the destination country, the transfer mechanism relied upon and, where applicable, the vendor's Data Privacy Framework certification status.

5.3 Transfers to Sub-processors outside the United Kingdom and the EEA are made under the mechanisms set out in Annex IV. The Processor conducts and documents a transfer risk assessment for each such transfer to a country not the subject of an adequacy decision, and applies supplementary measures where the assessment requires them.

5.4 Where inference services are used in connection with Controller Personal Data, the Processor uses a self-hosted model deployed on infrastructure under its own control within the EEA, so that Controller Personal Data is processed transiently and is not retained by, or used to train the models of, any third-party inference provider.

5.5 New Sub-processors are notified to the Controller in accordance with clause 5.4.2 of the DPA.

6. Personnel

6.1 Personnel with access to Personal Data are subject to written confidentiality obligations that survive the end of their engagement.

6.2 Access is granted on a least-privilege basis on joining or on change of role, is reviewed periodically, and is revoked on departure.

6.3 Personnel receive data protection and security awareness training appropriate to their role, on appointment and periodically thereafter.

6.4 The Processor has appointed a Data Protection Lead with responsibility for compliance with the Data Protection Laws, whose details are set out on the cover page of the DPA.

7. Incident Detection and Response

7.1 Application and infrastructure telemetry is collected and retained for operational monitoring and incident investigation.

7.2 The Processor maintains a documented incident response procedure covering detection, triage, containment, assessment, notification, remediation and post-incident review, and identifying the personnel responsible at each stage.

7.3 Confirmed Personal Data Breaches affecting Controller Personal Data are notified to the Controller in accordance with clause 5.6 of the DPA, without undue delay and in any event within seventy-two (72) hours of confirmation.

7.4 A post-incident review is completed for every confirmed Personal Data Breach, and the resulting remedial actions are tracked to completion.

8. Data Subject Rights and Suppression

8.1 The Processor operates a documented procedure for handling data subject requests, comprising intake, identity resolution, an impact assessment, authorisation by the Data Protection Lead, execution, and confirmation.

8.2 Requests are recorded in a durable ledger which is retained for accountability purposes under Article 5(2) UK GDPR independently of, and for longer than, the data to which the request relates. The plaintext identifiers of the data subject are held only while the request is in progress and are removed on completion, leaving a keyed digest and a masked reference as the permanent record.

8.3 Access requests are fulfilled by producing a complete export of the data subject's Personal Data across every system in which it is held, in a commonly used machine-readable format.

8.4 Erasure and objection requests are executed across every system in which the data subject's Personal Data is held, and the number of records removed from each is recorded in the ledger as evidence of completion.

8.5 On completion of an erasure or objection request, the minimum identifiers necessary to recognise the data subject are placed on a suppression list, so that they are not re-collected, re-enriched or contacted again. Enforcement is described at paragraph 3.4.

8.6 The Processor makes available to the Controller a list of data subjects who have exercised an erasure or objection right in respect of the Services, so that the Controller may give effect to the request within its own systems.

9. Secure Development and Change Management

9.1 All changes to the Services are made on separate branches and are merged only through reviewed pull requests. Direct commits to the production branch are prohibited.

9.2 An automated build and test suite runs on every pull request, and every pull request additionally receives an automated code review.

9.3 Each pull request is deployed to an isolated per-branch environment for verification before merge.

9.4 An end-to-end regression suite runs nightly against a deployed environment, and failures are triaged before the next release.

9.5 Dependencies are monitored for known vulnerabilities and are updated on a risk-assessed basis.

10. Review

10.1 These measures are reviewed at least annually, and on any material change to the Services, the categories of Personal Data processed, or the Sub-processors engaged.