Data Processing Agreement

1. Parties and background

This Data Processing Agreement (the "DPA") is between:

• the entity that accepted the TPSClear Terms of Service or signed an order form with Voll Studios Ltd (the "Customer", the data controller); and
• Voll Studios Ltd, a company registered in England and Wales (company number 09302803), registered office 5 Brayford Square, London, England, E1 0SG, trading as TPSClear, ICO registration ZC135838 (the "Processor", the data processor).

The Processor operates TPSClear (tpsclear.co.uk), a UK Telephone Preference Service (TPS) and Corporate TPS (CTPS) screening service, delivered as a REST API and as native CRM integrations. The Customer submits telephone numbers to the service for screening against the TPS and CTPS registers or, for Australian numbers, the Australian Do Not Call Register; TPSClear returns a verdict for each number. This DPA governs the processing of personal data carried out by the Processor on the Customer's behalf in delivering that service, and forms part of, and is subject to, the agreement under which the Customer uses TPSClear (the TPSClear Terms of Service or a separately executed services agreement, the "Main Agreement").

This DPA is entered into to satisfy the requirements of Article 28 of the UK GDPR.

This DPA applies automatically, and forms part of the Main Agreement, from the Customer's acceptance of the Terms of Service or signature of an order form. A countersigned copy is available on request from privacy@tpsclear.co.uk.

2. Definitions

2.1 "UK GDPR" means the retained EU law version of the General Data Protection Regulation (Regulation (EU) 2016/679) as it forms part of the law of the United Kingdom, read together with the Data Protection Act 2018.

2.2 "Personal Data", "Controller", "Processor", "Data Subject", "Processing", "Personal Data Breach" and "Supervisory Authority" have the meanings given to them in the UK GDPR. The Supervisory Authority is the Information Commissioner's Office (ICO).

2.3 "Customer Personal Data" means the Personal Data described in Annex 1 that the Processor processes on the Customer's behalf under the Main Agreement.

2.4 "Sub-processor" means a third party engaged by the Processor to process Customer Personal Data.

2.5 "Service" means the TPSClear screening service (the REST API, the native CRM integrations, and associated infrastructure).

2.6 "UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the ICO under section 119A of the Data Protection Act 2018, and "IDTA" means the ICO's International Data Transfer Agreement.

3. Subject matter, duration, nature and purpose of processing

3.1 Subject matter. The screening of UK telephone numbers supplied by the Customer against the TPS and CTPS registers, and of Australian telephone numbers against the Australian Do Not Call Register (section 14.4), and the return (or write-back to the Customer's CRM) of the resulting verdicts.

3.2 Duration. Processing continues for the term of the Main Agreement, plus the wind-down period needed to complete return or deletion under section 12.

3.3 Nature and purpose. Receipt of telephone numbers via authenticated API request or CRM integration; normalisation to E.164 format; lookup against TPS and CTPS register data supplied through the Processor's licensed data partners, or against the Australian Do Not Call Register (section 14.4); short-term caching of verdicts (see Annex 1); creation of per-request audit records; return of verdicts to the Customer or write-back to the Customer's CRM records. The Processor does not use Customer Personal Data for any other purpose, and does not sell it or use it for marketing.

3.4 Full processing details are set out in Annex 1.

4. Categories of data subjects and personal data

4.1 Data subjects: the Customer's contacts and leads; that is, the individuals (including sole traders and partnerships) whose telephone numbers appear in the CRM records or API payloads the Customer submits for screening.

4.2 Personal data: UK and Australian telephone numbers submitted for screening; the screening verdicts and timestamps associated with them; CRM record identifiers and optional request or campaign references supplied by the Customer. The Service does not require, request, or rely on names, email addresses, or any other personal data attached to the numbers being screened; the screening operation works on the number alone.

4.3 Special category data: none. The Customer must not submit special category data, criminal offence data, or data relating to children to the Service.

5. Roles and processing on documented instructions

5.1 The Customer is the Controller of Customer Personal Data. Voll Studios Ltd is the Processor.

5.2 The Processor shall process Customer Personal Data only on the Customer's documented instructions, including with regard to international transfers, unless required to do otherwise by the laws of England and Wales; in that case the Processor shall inform the Customer of the legal requirement before processing, unless the law prohibits this on important grounds of public interest.

5.3 The Customer's documented instructions are: (a) to process Customer Personal Data as necessary to provide the Service as described in the Main Agreement and Annex 1; and (b) any further written instructions agreed between the parties. The Processor shall immediately inform the Customer if, in its opinion, an instruction infringes the UK GDPR.

6. Confidentiality of authorised persons

6.1 The Processor shall ensure that every person it authorises to process Customer Personal Data is committed to confidentiality, whether under a written contractual obligation or a statutory duty.

6.2 Exactly one named individual (the founder and director of the Processor) holds privileged access to production systems. There are no shared accounts and no additional persons with access to Customer Personal Data. Access by that individual is bound by his duties as a director of the Processor and by the confidentiality obligations in the Main Agreement.

7. Security measures

7.1 The Processor shall implement and maintain appropriate technical and organisational measures to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as required by Article 32 of the UK GDPR.

7.2 The measures currently in place are set out in Annex 2. The Processor may update them from time to time, provided the changes do not materially reduce the overall level of protection.

8. Sub-processing

8.1 The Customer grants the Processor general written authorisation to engage the Sub-processors listed in Annex 3.

8.2 The Processor shall inform the Customer in writing (email to the Customer's registered contact is sufficient) of any intended addition or replacement of a Sub-processor at least 30 days before the change takes effect. The Customer may object on reasonable data protection grounds within that period; the parties shall then work in good faith to find a solution, and if none can be found the Customer may terminate the affected part of the Service without penalty.

8.3 The Processor shall impose on each Sub-processor, by written contract, data protection obligations materially equivalent to those in this DPA, and shall remain fully liable to the Customer for the performance of each Sub-processor's obligations.

9. Assistance with data subject rights

9.1 Taking into account the nature of the processing, the Processor shall assist the Customer, by appropriate technical and organisational measures and insofar as this is possible, in fulfilling the Customer's obligation to respond to data subject requests under Chapter III of the UK GDPR (access, rectification, erasure, restriction, portability, objection).

9.2 If a data subject contacts the Processor directly about Customer Personal Data, the Processor shall not respond substantively (except to direct the data subject to the Customer) and shall notify the Customer without undue delay.

9.3 In practice, the Customer holds the screened records in its own CRM or systems; the Processor's assistance chiefly concerns the audit records and cached verdicts described in Annex 1, which the Processor shall locate, correct, or delete at the Customer's request.

10. Assistance with Articles 32 to 36

10.1 The Processor shall assist the Customer in ensuring compliance with its obligations under Articles 32 to 36 of the UK GDPR (security of processing, breach notification to the Supervisory Authority and to data subjects, data protection impact assessments, and prior consultation), taking into account the nature of the processing and the information available to the Processor.

10.2 This includes providing the information reasonably necessary for the Customer to complete a data protection impact assessment concerning the Service.

11. Personal data breach notification

11.1 The Processor shall notify the Customer without undue delay, and in any event within 48 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data.

11.2 The notification shall, so far as the information is available, describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed to address the breach and mitigate its effects. Information may be provided in phases as it becomes available.

11.3 The Processor shall cooperate with the Customer and take reasonable steps to investigate, mitigate, and remediate the breach. The Processor shall not notify the Supervisory Authority or data subjects on the Customer's behalf unless the Customer instructs it to do so or the law requires it.

12. Return or deletion at end of provision

12.1 On termination or expiry of the Main Agreement, the Processor shall, at the Customer's choice, return or delete all Customer Personal Data, and delete existing copies, within 30 days, unless the laws of England and Wales require continued storage; in that case the Processor shall protect the retained data and process it only as those laws require.

12.2 Verdicts already written to the Customer's own CRM or systems are outside the Processor's control and are unaffected by this section.

12.3 If the Customer makes no election within 30 days of termination, the Processor shall delete the Customer Personal Data in line with the retention periods in Annex 1.

13. Audit and information rights

13.1 The Processor shall make available to the Customer all information reasonably necessary to demonstrate compliance with Article 28 of the UK GDPR, and shall allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer.

13.2 Audits are limited to once in any 12-month period (except following a Personal Data Breach affecting the Customer, or where required by a Supervisory Authority), on at least 30 days' written notice, during normal business hours, at the Customer's cost, and conducted so as not to disrupt the Processor's operations or compromise the security or confidentiality of other customers' data.

13.3 The Customer shall first make use of written responses and existing documentation (including this DPA's annexes, the Processor's security overview, and relevant Sub-processor certifications and reports) before requiring an inspection.

14. International transfers

14.1 The Processor shall not transfer Customer Personal Data outside the United Kingdom except (a) to the Sub-processors listed in Annex 3 under the transfer mechanisms identified there, or (b) on the Customer's documented instructions.

14.2 Where a transfer is made to a country not covered by UK adequacy regulations, the Processor relies on the UK Addendum to the EU Standard Contractual Clauses (or the IDTA) as incorporated into its agreement with the relevant Sub-processor, together with such supplementary measures as are appropriate.

14.3 In summary, and as detailed in Annex 3: screening lookups against the TPS and CTPS registers are performed in the UK, by the Processor's own register service or by UK-based licensed data partners, and do not leave the UK, except Australian numbers (section 14.4); the application database is hosted in the EU (covered by the UK's adequacy regulations for the EEA); hosting, DNS, payment, and email infrastructure providers are US-headquartered and process limited categories of data under the UK Addendum.

14.4 Where the Customer uses the Australian add-on or API, Australian telephone numbers are sent to the Do Not Call Register, kept by the Australian Communications and Media Authority (ACMA) in Australia, for checking. The Customer's use of that add-on or API is its documented instruction for this transfer under section 14.1(b). Where the Customer is bound by the Privacy Act 1988 (Cth), sending Australian numbers to the Processor in the United Kingdom may be a cross-border disclosure under Australian Privacy Principle 8.

15. Liability

15.1 Each party's liability arising out of or in connection with this DPA is subject to the exclusions and limitations of liability set out in the Main Agreement. This DPA does not create any liability cap or exclusion additional to, or separate from, the Main Agreement.

15.2 Nothing in this DPA limits either party's liability for anything that cannot be limited or excluded under the laws of England and Wales, or affects a data subject's rights against either party under the UK GDPR.

16. General

16.1 If there is a conflict between this DPA and the Main Agreement concerning the processing of Customer Personal Data, this DPA prevails. A data processing agreement or order form separately executed between the parties prevails over this DPA to the extent of any conflict.

16.2 This DPA takes effect on the date the Main Agreement takes effect and continues for as long as the Processor processes Customer Personal Data.

16.3 Governing law and jurisdiction. This DPA is governed by the laws of England and Wales, and the courts of England and Wales have exclusive jurisdiction over any dispute arising out of or in connection with it.

Annex 1: Processing details

A1.1 Subject matter and nature of processing. Screening of UK telephone numbers against the TPS and CTPS registers, and of Australian telephone numbers against the Australian Do Not Call Register (section 14.4). Numbers are received via authenticated HTTPS API request or via the Customer's CRM integration, normalised to E.164 format, checked against register data supplied through the Processor's licensed data partners (see Annex 3) or against the Australian Do Not Call Register (section 14.4), and the verdict (Clean, TPS-listed, CTPS-listed, or Unknown, or for Australian numbers On the DNCR, Not on the DNCR, or Not a valid AU number, with a timestamp) is returned in the API response or written back to the Customer's CRM record.

A1.2 Purpose. To enable the Customer to comply with regulation 21 of the Privacy and Electronic Communications Regulations 2003 (PECR) and, for Australian numbers, section 11 of the Do Not Call Register Act 2006 (Cth), by identifying numbers registered on those registers before making unsolicited direct marketing calls.

A1.3 Categories of data subjects. The Customer's contacts and leads: individuals, sole traders, and partnership contacts whose telephone numbers the Customer submits for screening.

A1.4 Categories of personal data.

• UK and Australian telephone numbers submitted for screening (raw and E.164-normalised forms).
• Screening verdicts and the timestamp at which each verdict was obtained.
• CRM record identifiers (for integration customers) and optional free-text request or campaign references supplied by the Customer.
• Authentication and account identifiers needed to process the request: API key identifiers, CRM OAuth installation records, customer account IDs.
• Request metadata: salted hashes of requesting IP addresses (raw IP addresses are not stored by the application) and user-agent strings.

A1.5 Special category data. None; the Customer must not submit any (section 4.3).

A1.6 Storage and retention.

• Verdict cache. A definitive verdict is cached against the E.164 number so that repeat screenings of the same number within 27 days do not require a fresh register lookup (TPS registrations become enforceable after 28 days and the register data can be a day behind, so a verdict is safe to reuse within that window). Cached verdicts are deleted no later than 60 days after the underlying check.
• Screening audit records. Each API screening request produces an audit record (referenced by the X-Request-Id returned to the Customer) containing the numbers screened, the verdicts, a result summary, the account and key identifiers, the hashed request IP, and any campaign reference. Audit records are retained for up to 12 months and then deleted, or earlier at the Customer's request or on termination under section 12.
• Verdicts written to the Customer's CRM remain on the Customer's records under the Customer's control; the Processor does not manage their retention.
• Platform operational logs (function invocation logs, error traces) are retained per the hosting platform's defaults, typically around 30 days. Telephone numbers are not written to these telemetry and error logs.
• Account records are retained for the life of the account plus 12 months after closure, unless a longer period is required by law.

A1.7 Location of processing. See Annex 3. UK register screening is performed in the United Kingdom, and Australian numbers are checked in Australia; the application database is hosted in the EU; edge and hosting infrastructure serves UK and EU traffic from EU regions.

Annex 2: Technical and organisational measures

A2.1 Encryption in transit. All connections to the Service use TLS 1.2 or higher. HTTP Strict Transport Security is enforced with a two-year max-age, includeSubDomains, and preload.

A2.2 Encryption at rest. Customer Personal Data held in the application database, and data held on the hosting platform, is encrypted at rest by the respective platform providers (Annex 3).

A2.3 Access control and least privilege. Access is deliberately narrow: exactly one privileged user, no shared accounts, and no offboarding surface. Production access uses per-service scoped credentials (a dedicated database service key, scoped API keys per provider) rather than any master credential. Database tables holding Customer Personal Data have row-level security enabled and are reachable only server-side via the service role; no client-side or anonymous database access path exists.

A2.4 API authentication. Customer API keys are stored only as SHA-256 hashes (with a non-secret prefix for indexed lookup); the plaintext key is never persisted. Key verification uses constant-time comparison. Keys are per-environment (test and live), revocable, and rotatable via a dedicated endpoint. CRM integrations authenticate via OAuth with signed webhook verification.

A2.5 Rate limiting and abuse controls. Weighted per-key lookup budgets enforced atomically in the database (no lost updates under concurrent serverless invocations); per-IP and global submission caps on public forms; per-portal daily screening caps for CRM integrations. Public forms carry a honeypot field, and bot submissions are silently discarded.

A2.6 Input controls. Request body sizes are capped (16 KB on public form endpoints, 64 KB on the screening endpoint), batch size is capped at 1,000 numbers per request, and all inputs are validated server-side with strict field length limits and allowlists.

A2.7 HTTP security headers. Every route serves a baseline security header set: Strict-Transport-Security (as above), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, X-Frame-Options: DENY, a Permissions-Policy denying camera, microphone, geolocation and browsing-topics, and a Content-Security-Policy restricting object-src, base-uri, and frame-ancestors.

A2.8 Data minimisation and pseudonymisation. The Service screens on the telephone number alone and does not require names or other identifiers. Requesting IP addresses are stored only as salted SHA-256 hashes; the raw IP is never written to the application database. Telephone numbers are not written to telemetry or error logs.

A2.9 Verdict integrity. A register-provider failure is never reported as Clean; affected numbers are returned as Unknown so the Customer cannot be misled into calling an unscreened number.

A2.10 Resilience. The application is stateless and serverless; screening verdicts are regenerable from the TPS and CTPS registers, limiting the impact of any data loss on the Customer's compliance position.

A2.11 Vulnerability and dependency management. Dependencies are kept patched; the hosting platform's deployment pipeline blocks releases whose production dependencies carry known high-severity security advisories.

A2.12 Monitoring. Automated daily operational checks verify production availability and payment-webhook delivery, with alerts routed to the operator. Platform logs and error traces support incident investigation.

A2.13 Retention and deletion. The retention periods in Annex 1 are applied, and Customer Personal Data is returned or deleted at end of provision under section 12.

Annex 3: Sub-processors

The Customer's general written authorisation (section 8.1) covers the following Sub-processors. The CRM the Customer connects (HubSpot, Pipedrive or Zoho CRM) is not a Sub-processor: the TPSClear app connects to the Customer's own CRM account, which is the Customer's own CRM environment under the Customer's own agreement with the CRM provider.

Changes to this list are notified in advance under section 8.2. The current list is published at tpsclear.co.uk/subprocessors.