Data Processing Agreement

Version 1.1 — September 29, 2026

This Data Processing Agreement (“DPA”) governs the processing of personal data by Third Frontier Ventures Ltd. trading as Arcla (“Arcla”, “we”, “us”), a company registered in England and Wales, on behalf of the organisation that has subscribed to the Arcla service (“Customer”, “you”).

This DPA forms part of, and is incorporated into, the Arcla Terms and Conditions. Where this DPA and those terms conflict on the subject of personal data processing, this DPA prevails.

You do not need to sign this DPA for it to apply. It takes effect automatically when you use the Arcla service. If your procurement process requires a countersigned copy, or requires changes to these terms, contact us at support@arcla.com and we will work through it with you.

1. Roles of the parties

For personal data contained in or derived from calls processed through Arcla, including audio, transcripts, participant details and derived insights (“Customer Personal Data”):

• You are the controller. You decide which calls are processed, whose data is captured, and for what purpose. You are responsible for the lawful basis for that processing and for any notice or consent required from call participants.
• Arcla is the processor. We process Customer Personal Data on your documented instructions and for no purpose of our own.

For data about your account itself — the identity of your users, billing records, and how your team uses the product — Arcla acts as a controller, and our Privacy Policy governs that processing. This DPA does not cover it.

2. Scope and duration of processing

The subject matter, nature, purpose, duration, and categories of data and data subjects are set out in Annex A. Processing continues for as long as your subscription is active, and thereafter only as set out in section 9.

3. Our obligations as processor

We will:

• Process only on your instructions. We process Customer Personal Data only on your documented instructions, including for international transfers, unless required otherwise by law. Your instructions comprise this DPA, the Terms and Conditions, and your configuration and use of the service. If we believe an instruction infringes data protection law, we will tell you.
• Not use your data for our own purposes. In particular, we do not train artificial intelligence models on Customer Personal Data, and we do not permit our sub-processors to do so. Arcla operates no models of its own; all speech recognition and language models are operated by the providers listed in Annex C. Where we analyse usage to improve the product, we use aggregated usage patterns and our own internal test data, not your call content.
• Not sell or share your data, and not use it for advertising or profiling.
• Impose confidentiality. Personnel authorised to process Customer Personal Data are bound by confidentiality obligations and are granted access only where necessary.
• Secure the data by implementing the technical and organisational measures set out in Annex B, appropriate to the risk.
• Assist you with your obligations in respect of data subject rights (section 8), security, breach notification, and data protection impact assessments, taking into account the nature of processing and the information available to us.
• Make available the information necessary to demonstrate compliance with this DPA, and submit to audits as set out in section 10.

4. Sub-processors

You give general authorisation for us to engage sub-processors. The current list is published and maintained at arcla.com/subprocessors, which names each sub-processor, what it does, the categories of data it handles, and the region in which it processes.

Where we engage a sub-processor we impose data protection obligations no less protective than those in this DPA, and we remain fully liable to you for its performance.

Notice of change. We will give at least 30 days’ notice before adding a new sub-processor that processes Customer Personal Data, by updating the sub-processor page and notifying the administrative contact on your account. You may object on reasonable data protection grounds within that period. If we cannot resolve your objection, you may terminate the affected part of the service without penalty and receive a pro-rata refund of prepaid fees.

Current status of sub-processor terms. For most sub-processors we rely on their published standard data processing terms. For a minority, that documentation is still being completed. We will confirm the position for any specific provider on request.

5. International transfers

Our primary database is in the United Kingdom (London). Live call processing, speech-to-text and AI inference run on United States infrastructure. This is a deliberate engineering choice: the answer path is co-located with our inference providers because transatlantic round-trips would make real-time coaching unusable. Analytics and error monitoring are processed in the European Union.

We do not currently offer region locking. You cannot contractually require that your data remains in a particular region. EU-resident call processing is on our roadmap. If regional residency is a procurement requirement for you, contact us at security@arcla.com to discuss timing.

Where Customer Personal Data is transferred outside the UK or EEA, the transfer is made under the UK International Data Transfer Agreement, or the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914, module two, controller to processor) together with the UK Addendum where applicable, which are incorporated into this DPA by reference. Completing that documentation with every provider on the sub-processor page is work in progress, and we will report the position for any provider on request.

6. Security

We implement and maintain the technical and organisational measures described in Annex B. We may update those measures, provided the level of protection is not reduced.

Annex B describes what is in place today, and says where a measure is our infrastructure providers’ default rather than something we configure. We have deliberately not listed controls we do not yet operate.

7. Personal data breaches

We will notify you without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Customer Personal Data. The notification will describe, so far as we know it at the time: 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.

Where we cannot provide all of that information at once, we will provide it in phases without further undue delay. We will assist you in meeting your own notification obligations to a supervisory authority or to data subjects.

Report a suspected security issue to security@arcla.com. Our vulnerability disclosure policy is at arcla.com/security.

8. Data subject rights

You are responsible for responding to requests from data subjects, including the call participants whose data you process through Arcla.

We will assist you by appropriate technical and organisational measures, insofar as possible, and will not respond directly to a data subject’s request concerning Customer Personal Data except on your instruction or where legally required. If we receive such a request directly, we will refer the data subject to you and tell you promptly.

What the platform does today. Administrators can locate a call and delete it, which removes it from your workspace immediately; removal from our underlying storage follows within 30 days. Where you need data located, exported or erased for a specific data subject, contact support@arcla.com and we will action it within 30 days.

Encrypted backups, including a separate off-site copy kept for disaster recovery, may hold a copy for up to a further 35 days before they age out on their normal cycle. Those backups are not accessible in the ordinary course of running the service.

9. Deletion and return of data

On termination or expiry of your subscription, or at any time on your written instruction, we will delete Customer Personal Data, unless we are required by law to retain it.

We will complete deletion within 90 days of the instruction or of termination, and confirm completion in writing on request. Until automated erasure ships, this is carried out as a managed process.

Before deletion, you may request a copy of your Customer Personal Data in a commonly used format. Request it before termination or within 30 days after, as we cannot return data we have deleted.

Backups and system logs may retain residual copies for up to a further 35 days; these are not accessible in the ordinary course and are overwritten on the normal cycle.

10. Audit

We will make available to you the information reasonably necessary to demonstrate compliance with this DPA. This includes the material published in our sub-processor register, our Privacy Policy, and Annex B of this DPA.

You may audit our compliance, or appoint an independent auditor to do so, on at least 30 days’ written notice, no more than once in any 12-month period unless required by a supervisory authority or following a personal data breach. Audits are conducted during business hours, subject to confidentiality, and in a manner that does not disrupt our operations. You bear your own costs.

Certification. Arcla does not currently hold SOC 2 or ISO 27001 certification. SOC 2 readiness preparation is complete and we are selecting a compliance provider to engage; no observation window has opened. We will update this section when the position changes.

Documents available on request. In place of an audit report we maintain, and will share with a Customer under a non-disclosure agreement: our risk register, which rates each risk to Customer Personal Data and records its owner and treatment; and our business continuity and disaster recovery plan, which sets a recovery time and recovery point objective for each system holding Customer Personal Data. Our full control set is published at arcla.com/security-posture and needs no agreement to read.

11. Liability and precedence

Each party’s liability under this DPA is subject to the limitations and exclusions in the Terms and Conditions.

In the event of a conflict, the order of precedence is: (1) the UK IDTA or EU Standard Contractual Clauses, (2) this DPA, (3) the Terms and Conditions.

12. Changes to this DPA

We may update this DPA where required by law or to reflect a change in how the service processes personal data. Material changes will be notified to the administrative contact on your account at least 30 days in advance, and the version and date at the top of this page will change. Changes will not reduce the protections given to Customer Personal Data.

Annex A — Details of processing

Subject matter. Provision of the Arcla real-time sales coaching and conversation intelligence platform.

Duration. For the term of the Customer’s subscription, plus the deletion period in section 9.

Nature and purpose. Recording or receiving call audio; converting speech to text; detecting questions asked during a call; retrieving relevant material from the Customer’s knowledge base; generating suggested answers and coaching prompts in real time; producing post-call summaries, analysis and insights; and storing the above so the Customer can review it.

Categories of personal data:

Categories of data subjects:

• The Customer’s personnel who use Arcla (sales representatives, managers, administrators).
• Third parties on calls — prospects, leads, customers and other participants whose voice and personal data are captured. These individuals typically have no direct relationship with Arcla, and their rights are addressed in section 9 of our Privacy Policy.
• Any individual whose personal data appears in knowledge base content the Customer uploads.

Special category data. Arcla is not designed for and should not be used to process special category data as defined in Article 9 UK GDPR. Because we transcribe unscripted conversation, we cannot prevent a participant from mentioning such information. We do not process it deliberately and do not derive it.

Annex B — Technical and organisational measures

This annex describes measures in place at the version date above. Where a measure is provided by an infrastructure provider rather than configured by us, it says so.

Access control and tenant isolation

• Authentication and session management are provided by Clerk, a specialist identity provider, including multi-factor authentication support.
• Each organisation’s data is separated by an organisation identifier enforced at the database level through PostgreSQL row-level security, rather than by application code alone.
• Live call transcripts are held in per-call storage instances that are isolated by construction.
• Application access is role-gated. Arcla staff hold no standing access to customer organisations; support access is granted per organisation and can be revoked.
• Users can view their signed-in devices and remotely sign out any of them.
• Production infrastructure access is held by at most two named members of the engineering team. No contractor or third party holds production credentials.
• Multi-factor authentication is enforced on every administrative console holding production access. The devices used to administer production run full-disk encryption, lock automatically, and hold credentials in a password manager. We do not operate centralised device management.

Encryption

• In transit: all traffic is served over HTTPS, with HTTP Strict Transport Security enforced on the domains we operate. The minimum accepted TLS version is 1.2; earlier versions are refused at the edge.
• At rest: databases and object storage are encrypted at rest by our infrastructure providers (Supabase, Cloudflare) using their platform defaults. We do not currently operate customer-managed encryption keys.

Network and platform security

• Infrastructure sits behind Cloudflare, providing DDoS mitigation and platform-level protection, with rate limiting on sensitive endpoints.
• Internal service-to-service calls within the call-processing backend are routed over private service bindings and are not publicly reachable endpoints.
• The desktop application ships deny-by-default renderer permissions and a restrictive content security policy.

Edge protection

• All public traffic reaches the service through Cloudflare rather than an origin directly, giving always-on DDoS protection, a managed web application firewall, and bot challenges on the paths that attract automated abuse.
• Rate limiting on our public API is declared as code in our infrastructure repository and applied to the production zone. Firewall and bot-management settings themselves are configured in the provider’s dashboard rather than held as code.

Secrets management

• Secrets and environment configuration are managed in Doppler, with continuous-integration and runtime scopes kept separate. Secrets are injected at deploy time and are not committed to source control.

Secure development and vulnerability management

• Every change reaches production through a pull request. Direct pushes and force pushes to the main branch are blocked and linear history is enforced.
• Three checks must pass before any change can merge: linting, type checking and the automated test suite; linting and type checking also reject unused code. Every review comment must be resolved before merge, and merges are processed through a queue that re-runs the full suite against the merged result.
• Dependency scanning, static analysis, database security advisors and automated security review run on every change and on a daily schedule. These report findings rather than blocking a merge. Findings are verified against the code before being filed, then tracked through to a deployed fix. We do not currently publish remediation time targets.
• Releases to production are deployed manually rather than automatically, only from a revision already validated in staging, and are rolled out to zero live traffic until automated smoke tests pass.
• We operate a published vulnerability disclosure policy with a 90-day coordinated disclosure window.

Monitoring and logging

• Application errors and structured logs are collected and monitored, with automated alerts for anomalous behaviour.
• Logs are keyed by identifiers rather than carrying personal data fields, and log retention is governed by our providers’ dataset retention settings.
• We do not currently maintain a per-record access log showing which staff member viewed which call. Building one is on our roadmap.

Resilience

• The platform runs on managed cloud infrastructure with the durability and availability characteristics of those services. Speech-to-text uses multiple providers with automatic in-session failover so transcription continues if one is unavailable.

Measures we do not yet operate. For completeness, and so this annex is not read as claiming more than it says: we do not hold SOC 2 or ISO 27001 certification, we have not commissioned an independent penetration test, we do not offer regional data residency, we do not maintain a per-record access log of which staff member viewed which call, we do not run background checks on staff, and we do not operate centralised device management.

A fuller account of the controls we operate, how each one is evidenced, and where the gaps are, is published at arcla.com/security-posture.

Annex C — Sub-processors

The current sub-processor list is published at arcla.com/subprocessors and forms part of this DPA. It is maintained there rather than reproduced here so that it stays current between versions of this document, and it records for each sub-processor the company, its purpose, the categories of data it handles, and the region where it processes.

Contact

Questions about this DPA, requests for a countersigned copy, or requests for information under section 10 should be directed to:

Third Frontier Ventures Ltd. trading as Arcla support@arcla.com

Security matters: security@arcla.com