Skip to content
Start free

DocsGPT Cloud

Data Processing Addendum

The terms on which ARC53 LTD processes personal data on your behalf when you use DocsGPT Cloud: what we may and may not do with it, who else processes it and where, the security measures behind it, and what happens when the agreement ends. It applies whenever we act as your processor.

Effective 2026-09-19 · Version 1.0 · ARC53 LTD (SC642841) · privacy@docsgpt.cloud

Last updated:

This Data Processing Addendum (“DPA”) forms part of the DocsGPT Cloud Terms of Service, Master Services Agreement, or other written agreement (the “Agreement”) between ARC53 LTD, a private limited company incorporated in Scotland under company number SC642841, with its registered office at 5 South Charlotte Street, Edinburgh, Scotland, EH2 4AN (“Arc53”, “we”), and the customer named in the Agreement or order form (“Customer”).

It applies when, and to the extent that, Arc53 processes Customer Personal Data on Customer’s behalf in providing DocsGPT Cloud.

01Definitions

Capitalised terms not defined here have the meaning given in the Agreement.

  • “Data Protection Laws” means all data protection laws that apply to the processing of Customer Personal Data under the Agreement, including, as applicable: (a) Regulation (EU) 2016/679 (the “EU GDPR”); (b) the EU GDPR as retained in UK law by the European Union (Withdrawal) Act 2018 (the “UK GDPR”) and the Data Protection Act 2018, each as amended (including by the Data (Use and Access) Act 2025); (c) the Swiss Federal Act on Data Protection of 25 September 2020 (the “FADP”); and (d) any other data protection or privacy laws that apply to the Services, including US state privacy laws where applicable.
  • “Customer Personal Data” means Personal Data in Customer Data that Arc53 processes on Customer’s behalf under the Agreement, as described in Annex I.
  • “Customer Data” means data that Customer or its Authorised Users submit to the Services. This includes prompts, conversation messages, uploaded files and attachments, ingested sources and the chunks and embeddings made from them, memories, notes, agent and workflow configuration, scheduled-run outputs, generated artefacts, and credentials for integrations.
  • “Authorised User” means an individual whom Customer allows to use the Services under Customer’s account or organisation.
  • “Services” means the hosted DocsGPT Cloud service, including the web application, APIs (including the /v1 OpenAI-compatible API and the MCP endpoint), embeddable widgets, agents, tools, connectors, and single-tenant deployments, as described in the Agreement.
  • “Sub-processor” means any third party that Arc53 engages to process Customer Personal Data.
  • “Security Incident” means a breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data that Arc53 or its Sub-processors process.
  • “Restricted Transfer” means a transfer of Customer Personal Data to a country that Data Protection Laws do not recognise as providing adequate protection, where that transfer would be prohibited without a transfer mechanism.
  • “EU SCCs” means the standard contractual clauses approved by European Commission Implementing Decision (EU) 2021/914.
  • “UK Addendum” means the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner under s.119A of the Data Protection Act 2018.
  • “AI Model” means any machine learning model, whether developed by Arc53 or by a third party. It includes generative and foundation models, and the classification, ranking, embedding and extraction models used within the Services for retrieval and ranking, document parsing, tool selection, routing and guardrails.
  • “Inputs” means the prompts, messages, attachments, retrieved content and tool results that the Services send to an AI Model.
  • “Outputs” means the content the Services generate in response to Inputs, including answers, summaries, generated images, artefacts, code and tool results.
  • “Controller”, “Processor”, “Data Subject”, “Personal Data”, “Processing”, and “Supervisory Authority” have the meanings given in the EU GDPR (or the equivalent terms in other Data Protection Laws).

02Scope and roles

2.1Customer as Controller. For Customer Personal Data, Customer is the Controller (or a Processor acting for its own Controller) and Arc53 is the Processor (or Sub-processor). Where Customer is itself a Processor, Customer confirms that its Controller has authorised Customer’s instructions, including the appointment of Arc53.

2.2Arc53 as independent Controller. Arc53 is an independent Controller, not a Processor, for Personal Data it processes for its own legitimate business purposes. This data is covered by the Arc53 Privacy Policy, not by this DPA. These purposes are:

  1. creating and managing accounts, including sign-up, authentication and single sign-on;
  2. billing, invoicing, tax and fraud prevention;
  3. keeping the Services secure and reliable: service logs, abuse detection, and incident investigation;
  4. product analytics based on usage metadata (not the content of Customer Data);
  5. customer support and relationship communications; and
  6. meeting legal obligations.

2.3Customer’s own integrations. The Services let Customer connect third-party services that Customer chooses and configures, for example:

  • a model provider using Customer’s own API key or a custom model endpoint;
  • MCP servers and custom API tools;
  • the Telegram, ntfy and Postgres tools;
  • webhooks and the Chatwoot bridge;
  • OAuth connectors such as Google Drive;
  • remote devices paired by Customer; and
  • websites fetched by the read_webpage tool.

These third parties are not Arc53 Sub-processors. Customer is responsible for its relationship with them. When Customer enables such an integration, it instructs Arc53 to send the relevant Customer Data to that third party.

2.4Customer’s responsibilities. Customer is responsible for:

  1. having a lawful basis for the processing, including for any Personal Data in documents and sources it uploads;
  2. giving any required notices to Data Subjects and obtaining any required consents, including notices to people who talk to agents or widgets that Customer deploys;
  3. making sure its instructions comply with Data Protection Laws; and
  4. not submitting special categories of Personal Data (Art. 9 EU GDPR) or criminal-offence data (Art. 10) unless it has assessed that the Services are appropriate for that data.

03Processing instructions

3.1Arc53 will process Customer Personal Data only on Customer’s documented instructions, unless Union or Member State law (or, for UK data, UK law) requires otherwise. Where the law requires other processing, Arc53 will tell Customer about that requirement before processing, unless the law prohibits this on important grounds of public interest.

3.2Customer’s documented instructions are:

  1. the Agreement and this DPA;
  2. Customer’s and its Authorised Users’ use and configuration of the Services, including their choice of model, tools, connectors, agents, schedules, workflows and sharing settings; and
  3. any other written instructions that Customer gives and Arc53 accepts in writing.

3.3Arc53 will tell Customer promptly if, in its opinion, an instruction infringes Data Protection Laws. Arc53 may suspend the affected processing until the instruction is confirmed or changed.

3.4Fault diagnosis. Reproducing and fixing a defect that affects Customer Data is part of providing and maintaining the Services. Where Customer Data triggers a fault — for example a file that fails to parse or converts incorrectly — Arc53 may retain a copy of the affected material in restricted storage, accessible to named personnel only, solely to reproduce and fix the fault, for no longer than 30 days. Arc53 will not add that material to any training or evaluation dataset.

3.5No training; no sale. Arc53 will not:

  1. use Customer Data to train, fine-tune or otherwise adjust the weights or parameters of any AI Model, whether Arc53’s own or a third party’s, or place Customer Data into a training, fine-tuning or evaluation dataset for any AI Model. Arc53 engages model providers only on terms that prohibit them from doing the same with Customer Data. This applies to all Customer Data, on every plan, and there is no programme, setting or opt-in that varies it;
  2. sell or share Customer Personal Data (as those terms are defined in applicable US state privacy laws); or
  3. combine Customer Personal Data with Personal Data it receives from other sources, except as needed to provide the Services.

3.6Quality review. Assessing how the Services handled a request is part of providing and maintaining them. Arc53 may review Outputs against the corresponding Inputs and the Customer Data they were produced from, in order to assess and correct how the Services behave — retrieval and ranking, document parsing, tool selection, routing, and guardrails. What Arc53 learns from that review is applied by changing rules, thresholds, configuration and the instructions given to AI Models. This review:

  1. is carried out only by personnel Arc53 has named for the purpose, under the confidentiality obligations in clause 4, with access logged;
  2. is limited to what is needed to assess and correct how the Services behave;
  3. does not train, fine-tune or otherwise adjust the weights or parameters of any AI Model, and does not place Customer Data into a training, fine-tuning or evaluation dataset for any AI Model, each of which clause 3.5(a) prohibits;
  4. does not extend to credentials, API keys or OAuth tokens in Customer Data; and
  5. is switched off for Customer’s workspaces, at no charge, on Customer’s written request to privacy@docsgpt.cloud, and wherever Zero Retention Mode applies (clause 3.8).

3.7Service Usage Data and Aggregated Statistics. Arc53 may process metadata about the operation and use of the Services — such as which tools ran, error classes, volumes, timings and resource use — to operate, secure, support and improve the Services, and may produce aggregated and de-identified statistics from it. Those statistics will not identify Customer, any Authorised User, any Data Subject or any Customer Data, and will not allow re-identification by any means reasonably likely to be used. Once in that form they are no longer Customer Personal Data, and Arc53 may retain and use them without restriction.

3.8Zero Retention Mode. Where Customer has purchased Zero Retention Mode under an order form, Arc53 will, for the workspaces it covers and to the extent the order form specifies: route requests to model deployments that offer zero or reduced provider-side retention; disable provider-side storage of Inputs, Outputs and files wherever the provider makes that available for the deployment in use; exclude Customer Data from application logs; and shorten or remove the fault-diagnosis retention in clause 3.4. Zero Retention Mode is not enabled by default. Switching off the quality review in clause 3.6 does not require Zero Retention Mode; clause 3.6(e) applies to every Customer at no charge.

04Confidentiality

Arc53 will make sure that everyone it authorises to process Customer Personal Data has committed to confidentiality or is under an appropriate statutory duty of confidentiality. Arc53 will limit access to personnel who need it to provide, support or secure the Services.

05Security

5.1Arc53 will implement and maintain the technical and organisational measures in Annex II. These measures are designed to give a level of security appropriate to the risk, as required by Art. 32 EU GDPR.

5.2Arc53 may update these measures from time to time, provided the updates do not materially reduce the overall security of the Services.

5.3Customer is responsible for the security of its own account and use of the Services. This includes protecting credentials and API keys, configuring sharing and organisation permissions, and managing Authorised Users (including through SSO and SCIM where enabled).

06Sub-processors

6.1General authorisation. Customer gives Arc53 general written authorisation to engage Sub-processors. The Sub-processors in use for DocsGPT Cloud on the effective date are listed in Annex III.

6.2Obligations. Arc53 will:

  1. put a written agreement in place with each Sub-processor with data protection obligations that are no less protective than those in this DPA, to the extent they apply to the Sub-processor’s services; and
  2. remain liable to Customer for each Sub-processor’s performance of those obligations.

6.3Changes. Arc53 will notify Customer of any intended addition or replacement of a Sub-processor at least 15 days before the change takes effect. Arc53 will do this by updating www.docsgpt.cloud/subprocessors and emailing Customers who have subscribed to updates there.

6.4Objection. Customer may object on reasonable data protection grounds within the notice period. If Customer objects, the parties will discuss the concern in good faith. If they cannot resolve it within 30 days, Customer may terminate the affected Services and receive a pro-rata refund of prepaid fees for the rest of the term.

6.5Emergency replacement. Arc53 may replace a Sub-processor at shorter notice where it needs to for the security or continuity of the Services. In that case, Arc53 will notify Customer as soon as reasonably practicable, and the objection right in clause 6.4 applies.

6.6Model choice. Some Sub-processors (model providers, the code-execution sandbox, and image generation) receive Customer Data only when an Authorised User or agent selects the relevant model or tool. Annex III lists which Sub-processors work this way. Where Customer needs its data to stay in a particular region, Customer and its Authorised Users can limit which models and tools they select.

07International transfers

7.1Transfers. Arc53 and its Sub-processors may process Customer Personal Data in the countries listed in Annex III. Arc53 will make Restricted Transfers only in accordance with Data Protection Laws.

7.2Transfers to Arc53. Arc53 is established in the United Kingdom.

  1. Transfers from the EEA to Arc53 rely on the European Commission’s adequacy decision for the United Kingdom under the EU GDPR.
  2. Transfers from Switzerland rely on the Swiss Federal Council’s recognition of the United Kingdom as providing adequate protection.
  3. If either adequacy finding stops applying, the EU SCCs apply automatically to those transfers, completed as set out in clause 7.4 (and, for Swiss data, clause 7.6).

7.3Onward transfers to Sub-processors. Where a Sub-processor processes Customer Personal Data outside the UK and the EEA, in a country without an adequacy finding, Arc53 will ensure the transfer is covered by one of the following:

  1. the Sub-processor’s certification under the EU-US Data Privacy Framework and its UK Extension (and the Swiss-US Data Privacy Framework, for Swiss data);
  2. the EU SCCs (Module Three) with the UK Addendum; or
  3. the UK International Data Transfer Agreement.

7.4EU SCCs. Where the EU SCCs apply between Customer and Arc53, they are incorporated into this DPA by reference and completed as follows:

  1. Module Two (controller to processor) applies where Customer is a Controller. Module Three (processor to processor) applies where Customer is a Processor.
  2. Clause 7 (docking clause) applies.
  3. Clause 9: Option 2 (general written authorisation) applies, with the notice period in clause 6.3.
  4. Clause 11: the optional wording does not apply.
  5. Clause 13: the competent Supervisory Authority is the one set out in Annex I.C.
  6. Clause 17: Option 1 applies. The governing law is the law of Ireland.
  7. Clause 18: disputes are resolved by the courts of Ireland.
  8. Annexes I, II and III of the EU SCCs are completed by Annexes I, II and III of this DPA.

7.5UK transfers. Arc53 is established in the United Kingdom. Personal Data subject to the UK GDPR is processed in the United Kingdom and the EEA, which UK law treats as providing adequate protection, so those transfers are not Restricted Transfers. Where Arc53 makes an onward transfer of such data to a country without a UK adequacy finding, the transfer is covered by the UK Extension to the EU-US Data Privacy Framework, by the EU SCCs as varied by the UK Addendum, or by the UK International Data Transfer Agreement. The UK Addendum’s tables are completed with the information in clause 7.4 and the Annexes to this DPA. Either party may end the UK Addendum as allowed by its section 19.

7.6Swiss transfers. Where the EU SCCs apply to Personal Data subject to the FADP, they apply with these changes:

  1. the competent Supervisory Authority is the Swiss Federal Data Protection and Information Commissioner;
  2. references to “Member State” are read to include Switzerland, so that Swiss Data Subjects can bring claims where they habitually reside; and
  3. references to the EU GDPR are read as references to the FADP where the FADP applies.

7.7Alternative mechanisms. Arc53 may rely on any other lawful transfer mechanism. If the mechanism Arc53 relies on is invalidated, Arc53 will promptly adopt a lawful alternative.

7.8Transfer risk assessment. For onward transfers to Sub-processors, Arc53 has assessed the laws and practices of the destination countries, as required by Clause 14 of the EU SCCs and by the UK transfer risk assessment requirements. Arc53 will make a summary of that assessment available to Customer on request.

08Government access requests

If a public authority asks Arc53 for access to Customer Personal Data, Arc53 will:

  1. redirect the authority to Customer where reasonably possible;
  2. notify Customer promptly, unless the law prohibits this;
  3. challenge requests that it reasonably considers unlawful, overbroad or inconsistent with Data Protection Laws; and
  4. disclose only the minimum data needed to comply.

Arc53 will keep a record of such requests and will share it with Customer where the law allows.

09Assistance with Data Subject requests

9.1The Services let Customer and its Authorised Users access, correct, export and delete much of Customer Data themselves. For example, they can:

  • delete individual conversations or all conversations;
  • delete sources, chunks, agents, prompts and tools; and
  • deactivate users through SCIM.

9.2If Arc53 receives a request from a Data Subject about Customer Personal Data, Arc53 will not respond to it, other than to direct the Data Subject to Customer. Arc53 will forward the request to Customer without undue delay, where it can identify Customer.

9.3Where Customer cannot fulfil a request itself through the Services, Arc53 will provide reasonable assistance with appropriate technical and organisational measures. This includes deleting or exporting account-level data on Customer’s written request within 30 days.

10Security Incidents

10.1Arc53 will notify Customer without undue delay, and in any case within 48 hours, after becoming aware of a Security Incident that affects Customer Personal Data.

10.2The notice will include, as far as the information is available at the time:

  1. the nature of the incident, including the categories and approximate number of Data Subjects and records concerned;
  2. the likely consequences;
  3. the measures taken or proposed to address the incident and reduce its effects; and
  4. a contact point for more information.

Arc53 may provide information in stages as it becomes available.

10.3Arc53 will promptly take reasonable steps to contain and investigate the incident, and will cooperate with Customer so that Customer can meet its obligations under Art. 33 and 34 EU GDPR.

10.4Notifying Customer is not an admission of fault or liability by Arc53. Unsuccessful attempts or activities that do not compromise the security of Customer Personal Data, such as pings, port scans, or blocked login or denial-of-service attempts, are not Security Incidents.

11DPIAs and prior consultation

Taking into account the nature of the processing and the information available to Arc53, Arc53 will give Customer reasonable assistance with any data protection impact assessment and prior consultation with a Supervisory Authority that Customer must carry out under Art. 35 and 36 EU GDPR. This includes providing information about how the AI features work: model routing, tool execution, memory and retrieval.

12Audits

12.1Arc53 will make available to Customer the information reasonably needed to show compliance with Art. 28 EU GDPR and this DPA. This includes:

  1. this DPA and its Annexes;
  2. answers to reasonable security questionnaires, no more than once in any 12-month period; and
  3. third-party audit reports or certifications, if and when Arc53 holds them, such as SOC 2 or ISO 27001, and summaries of the relevant Sub-processors’ audit reports where their terms allow.

12.2If this information is not enough to show compliance, or if a Supervisory Authority requires it, Customer may carry out an audit, including an inspection, under these conditions:

  1. the audit is on at least 30 days’ written notice;
  2. it takes place no more than once in any 12-month period, unless it follows a Security Incident;
  3. it is carried out during business hours, in a way that does not unreasonably disrupt Arc53’s operations;
  4. the auditor is Customer or an independent auditor bound by confidentiality; and
  5. Customer pays for it, unless the audit reveals a material breach of this DPA.

12.3Audits do not give access to other customers’ data or to Sub-processors’ facilities. Sub-processors are audited through their own audit reports.

13Return and deletion

13.1During the term, Customer can export and delete Customer Data using the features of the Services.

13.2When the Agreement ends, Arc53 will delete Customer Personal Data within 30 days, unless Customer asks in writing before the end of the Agreement for it to be returned. Arc53 will then provide confirmation of deletion on request. Data in backups will be deleted as those backups expire, within 35 days, and operational logs within 90 days. Both are kept isolated and protected until then.

13.3Arc53 may keep Customer Personal Data where Union, Member State or UK law requires it. In that case, clauses 4 and 5 continue to apply to the retained data for as long as Arc53 keeps it.

14Records

Arc53 will keep a record of processing activities carried out on Customer’s behalf, as required by Art. 30(2) EU GDPR. Arc53 will make it available to a Supervisory Authority on request.

15Liability

Each party’s liability arising out of or relating to this DPA, including under the EU SCCs to the extent the law allows, is subject to the limitations and exclusions of liability in the Agreement. Nothing in this DPA limits either party’s liability to Data Subjects under the EU SCCs, or any liability that the law does not allow to be limited.

16General

16.1Order of precedence. If documents conflict, they take priority in this order:

  1. the EU SCCs and the UK Addendum, where they apply;
  2. this DPA, on the processing of Customer Personal Data;
  3. an order form;
  4. the Agreement.

16.2Term. This DPA remains in force for as long as Arc53 processes Customer Personal Data under the Agreement.

16.3Governing law. Except as clause 7 provides otherwise, this DPA is governed by the law and jurisdiction that govern the Agreement.

16.4Changes in law. Arc53 may update this DPA where a change in Data Protection Laws or a decision of a Supervisory Authority or court requires it. Arc53 will give Customer 30 days’ notice. Updates will not reduce the protection given to Customer Personal Data.

Annex I — Details of processing

A. Parties

Data exporter: Customer, as identified in the Agreement.

  • Contact: the data protection contact Customer states in the Agreement or order form. Questions to Arc53 go to privacy@docsgpt.cloud.
  • Activities: using DocsGPT Cloud to build, run and share AI assistants and agents over Customer’s data.
  • Role: Controller (Module Two) or Processor (Module Three).

Data importer: ARC53 LTD (company number SC642841), 5 South Charlotte Street, Edinburgh, Scotland, EH2 4AN, United Kingdom.

B. Description of processing and transfer

Categories of Data Subjects

  • Customer’s Authorised Users: employees, contractors and organisation members.
  • End users who interact with agents, widgets, API keys or shared conversations that Customer deploys.
  • Individuals whose Personal Data appears in content that Customer submits: uploaded documents, ingested websites and repositories, connector sources, prompts, attachments, and data retrieved by tools.

Categories of Personal Data

  • Identity and account data used to provide the Services: Authorised User ID, name, email address, organisation and team membership, roles, SSO or SCIM attributes.
  • Content data: prompts and conversation messages; attachments and their extracted text; uploaded files and ingested sources, including the text chunks, vector embeddings and knowledge-graph entities made from them; memories, notes and to-dos; generated artefacts and images; agent, prompt, workflow and schedule configuration; scheduled-run outputs; wiki pages.
  • Voice data: audio recordings submitted for transcription, and text submitted to be read aloud.
  • Integration data: third-party API keys and OAuth tokens that Customer provides for tools and connectors, and data returned by those integrations.
  • Code execution data: code, files and outputs processed in the sandbox by the code_executor tool.
  • Technical and usage data: IP address and request metadata processed at the network edge; device identifiers and approval patterns for paired remote devices; timestamps; conversation and message IDs; token usage; tool-call records; error logs, which may include short excerpts of queries and file names.

Special categories of data (if any)

Not required by the Services. Customer may choose to submit such data in content, under clause 2.4(d). The safeguards in Annex II apply, including encryption in transit and at rest, access controls, and limited retention.

Frequency of transfer

Continuous, for as long as Customer uses the Services.

Nature of processing

Collection, storage, organisation, structuring, parsing (including OCR), chunking, embedding and indexing, retrieval and search, transmission to model providers for inference, execution of tools and code chosen by Customer, generation of outputs, logging, backup, and deletion.

Purpose of processing

To provide, secure, support and maintain the Services under the Agreement. This includes answering queries over Customer’s sources, running agents, workflows and scheduled tasks, and enforcing usage limits and billing metering.

Retention

  • Content data: kept until Customer or an Authorised User deletes it, or until the Agreement ends (clause 13).
  • Retention windows set in the application:
    • streaming message journal: 14 days;
    • guardrail events: 30 days;
    • scheduled-run outputs: 90 days;
    • code-execution sandboxes: stopped after 15 minutes idle and deleted 60 minutes after stopping.
  • Model providers: inputs and outputs may be kept by the provider for up to 30 days for abuse monitoring and, where used, for stateful response chaining and file inputs. They are not used for training (see Annex III, note 2).
  • Operational logs: Axiom 90 days; Better Stack error records 90 days and log streams 3 days.
  • Database backups: deleted data ages out of the backup window within 35 days.

Transfers to Sub-processors

As described in Annex III, for the same purposes and duration as above.

C. Competent Supervisory Authority

The competent Supervisory Authority is:

  • where Customer is established in the EEA: the Supervisory Authority of the Member State in which Customer is established;
  • where Customer is not established in the EEA but its processing falls within Art. 3(2) EU GDPR: the Supervisory Authority of the Member State in which Customer’s Art. 27 representative is established;
  • for Personal Data subject to the UK GDPR: the Information Commissioner’s Office;
  • for Personal Data subject to the FADP: the Swiss Federal Data Protection and Information Commissioner.

Arc53’s own supervisory authority is the UK Information Commissioner’s Office.

Annex II — Technical and organisational measures

1Hosting and network

  • The Services run in containers on Docker Swarm hosts managed with Dokploy. The primary host is on Microsoft Azure in Germany. A second API origin is on Scaleway (France and the Netherlands) behind a Cloudflare load balancer.
  • All public traffic enters through Cloudflare, which provides TLS termination, WAF and DDoS protection. The origin firewall (Azure NSG) exposes only the ingress ports. Internal services such as Redis are not publicly reachable.
  • Cloudflare connects to the origin servers over TLS on port 443, with certificates validated at the origin (Cloudflare SSL mode Full (strict)).
  • Traffic between hosts goes over an encrypted WireGuard mesh (Tailscale).

2Encryption

  • In transit: TLS 1.2+ between clients and the edge, and TLS to the database, object storage, model providers and other Sub-processors.
  • At rest:
    • The Postgres database, including vector embeddings, is encrypted at rest by the database provider (AES-256).
    • Object storage uses server-side encryption.
    • Third-party credentials that Customer stores for tools, including OAuth tokens for connectors, are also encrypted at the application level with a per-user derived key.

3Access control

  • Authorised Users authenticate through Clerk. SSO (OIDC) and SCIM provisioning are available on Business and Enterprise plans.
  • Organisations, teams and role-based permissions separate tenants and control sharing. Every API query is scoped to the authenticated user or organisation.
  • Agent API keys and device credentials are separate from user sessions and can be revoked.
  • Production access is limited to named Arc53 engineers. It uses SSH keys only, and Postgres access for investigation is read-only by default.
  • Secrets are held in the deployment platform’s environment configuration, not in source code.

4Tenant and data isolation

  • Sources and vector indexes are scoped by owner and access grants.
  • Code runs in isolated, ephemeral Daytona sandboxes with an idle auto-stop, an auto-delete, and a cap on concurrent sandboxes.
  • Single-tenant deployments are available with dedicated application and database services; their hosting, region and any measures that differ from this Annex are agreed with that customer.

5Application security

  • Code review on every change, automated tests, and locked dependency versions.
  • Container images are built in CI.
  • Upload size and type limits, parser resource guards, and prompt-injection and content guardrails with event logging.

6Monitoring and logging

  • Centralised application logging and telemetry (Axiom) and external uptime monitoring (Better Stack).
  • A daily production error review against a known-issue ledger.
  • Logs are designed to record identifiers rather than content. Where content excerpts appear in error logs, access is restricted, retention is short, and staff follow a minimal-quotation rule.

7Availability and resilience

  • Managed Postgres with point-in-time restore.
  • Two API origins for the enterprise endpoint, behind a load balancer.
  • Automatic container restarts.
  • Idempotent background task processing with dead-letter handling.
  • Incident response with a runbook.

8Data minimisation and deletion

  • Self-service deletion of conversations, sources, chunks, agents, prompts and tools.
  • Retention windows for journals, events and run outputs (see Annex I).
  • Sandboxes are deleted automatically.
  • Account deletion removes Customer Data across the database, vector store, object storage and third-party systems.

9Vendor management

  • DPAs are in place with Sub-processors.
  • Model providers are engaged only on terms that do not allow training on Customer Data.
  • Transfer impact assessments are done for non-adequate countries.

10People

  • Staff are bound by confidentiality.
  • Access is given on a need-to-know basis and removed at offboarding.
  • Security and privacy training at least annually.

11Incident management

  • Security Incidents are handled under a documented process that includes Art. 33 assessment and a breach register.

Annex III — Sub-processors

“Always” means the Sub-processor receives Customer Personal Data whenever the Services are used. “On selection” means it receives Customer Personal Data only when a user or agent picks that model or tool.

Transfer mechanisms are stated from Arc53’s position as a UK-based exporter:

  • “EEA”: no mechanism needed. UK law treats the EEA as adequate, and data from the EEA stays in the EEA.
  • “DPF”: the EU-US Data Privacy Framework together with its UK Extension.
  • “SCCs”: the EU SCCs (Module Three) with the UK Addendum, or the UK International Data Transfer Agreement.

Core infrastructure (always)

1Microsoft Azure

  • Entity: Microsoft Ireland Operations Ltd.
  • Purpose: primary compute for the API and background workers; Redis queue/cache; legacy self-hosted embeddings.
  • Data: all Customer Data in transit and in memory, and the cache.
  • Location: EEA (Germany).
  • Transfer mechanism: EEA.

2Scaleway SAS

  • Purpose: secondary API origin (enterprise endpoint), and embedding inference for document and query text.
  • Data: Customer Data in transit and in memory; text chunks sent for embedding.
  • Location: France and the Netherlands.
  • Transfer mechanism: EEA.

3Neon (Databricks)

  • Purpose: primary Postgres database, including vector embeddings.
  • Data: all stored Customer Data except files.
  • Location: AWS eu-central-1 (Frankfurt, Germany).
  • Transfer mechanism: EEA for hosting. DPF or SCCs cover any remote support access from the US.

4Amazon Web Services

  • Purpose: object storage for uploaded files and attachments.
  • Data: uploaded files.
  • Location: United Kingdom (London, eu-west-2).
  • Transfer mechanism: none for UK data (it stays in the UK). EU and Swiss data relies on the UK adequacy findings (clause 7.2).

5Cloudflare, Inc.

  • Purpose: CDN, TLS termination, WAF, DDoS protection and load balancing; R2 object storage for generated images and artefacts, and infrastructure backups.
  • Data: all traffic in transit; generated artefacts; backups.
  • Location: global edge network; R2 object storage in the European Union.
  • Transfer mechanism: DPF / SCCs.

6Clerk, Inc.

  • Purpose: authentication, session management, SSO.
  • Data: Authorised User identity data.
  • Location: USA.
  • Transfer mechanism: DPF / SCCs.

7Axiom, Inc.

  • Purpose: application logs and telemetry.
  • Data: identifiers, request metadata, error messages (may include short content excerpts and file names).
  • Location: USA.
  • Transfer mechanism: SCCs.

8Better Stack

  • Purpose: uptime monitoring; backend error tracking with 3-day log retention.
  • Data: error events, which may include request metadata.
  • Location: EU (Nuremberg, Germany).
  • Transfer mechanism: EEA.

9Functional Software, Inc. (Sentry)

  • Purpose: front-end error monitoring.
  • Data: browser error events, IP address, user-agent.
  • Location: USA (ingest.us.sentry.io).
  • Transfer mechanism: DPF / SCCs.

10PostHog, Inc.

  • Purpose: product analytics.
  • Data: Authorised User identifiers, name and email address, and metadata about feature use.
  • Location: USA.
  • Transfer mechanism: DPF / SCCs.

11Stripe

  • Entity: Stripe Payments Europe Ltd.
  • Purpose: subscription billing and metering.
  • Data: billing contact, customer and organisation identifiers, usage quantities.
  • Location: Ireland / USA.
  • Transfer mechanism: DPF / SCCs. Stripe acts as an independent controller for payment data.

AI and tool providers (on selection)

12Microsoft Azure AI Foundry

  • Entity: Microsoft Ireland Operations Ltd.
  • Purpose: LLM inference (GPT-5.6 family, Kimi, Grok and other models in the picker); file inputs; stateful response chaining.
  • Data: prompts, conversation context, retrieved chunks, attachments, tool results.
  • Location: global.
  • Transfer mechanism: DPF / SCCs.

13DigitalOcean, LLC

  • Purpose: LLM inference (Kimi K3, DeepSeek; the global fallback model).
  • Data: as for item 12.
  • Location: global.
  • Transfer mechanism: DPF / SCCs.

14Cloudflare, Inc. (Workers AI)

  • Purpose: LLM inference (GLM models).
  • Data: as for item 12.
  • Location: global.
  • Transfer mechanism: DPF / SCCs.

15Google LLC / Google Cloud

  • Purpose: Gemini inference, and the web-search tool service (Cloud Run).
  • Data: prompts and context; search queries.
  • Location: Gemini global; search service in europe-west3 (Frankfurt).
  • Transfer mechanism: DPF / SCCs.

16Daytona Platforms, Inc.

  • Purpose: sandboxed code execution.
  • Data: code, files and outputs from the code_executor tool.
  • Location: United States.
  • Transfer mechanism: SCCs.

17AtlasCloud

  • Purpose: image generation (the imagegen tool).
  • Data: image prompts.
  • Location: global.
  • Transfer mechanism: DPF / SCCs.

18OpenAI (speech)

  • Purpose: transcribing voice recordings, and reading answers aloud.
  • Data: the audio recording to be transcribed; the text to be read aloud.
  • Location: USA.
  • Transfer mechanism: DPF / SCCs.

19Additional model providers — OpenAI, Anthropic, Fireworks, Groq, OpenRouter, Novita, Hugging Face

  • Purpose: LLM inference, where an Authorised User or agent selects one of their models.
  • Data: as for item 12.
  • Location: global.
  • Transfer mechanism: DPF / SCCs.

Notes

  1. Model providers receive Customer Data only for the request being processed.
  2. Arc53 uses each provider’s API or enterprise terms, under which inputs and outputs are not used for model training. Abuse-monitoring retention is at most 30 days. Customers who need provider-side retention reduced or removed can purchase Zero Retention Mode (clause 3.8), which Arc53 applies to the extent each provider makes it available for the deployment in use.
  3. The DeepSeek first-party API (api.deepseek.com, People’s Republic of China) is not used. DeepSeek models are served through the providers above.
  4. People Data Labs receives an email domain at sign-up for company lookup. Arc53 is an independent Controller for that processing under clause 2.2, so People Data Labs is not a Sub-processor under this DPA and is described in the Privacy Policy instead.
  5. Managed and other single-tenant instances are provisioned for one customer, and that customer chooses the sub-processors and regions for its instance. They are recorded in that customer’s order form rather than in this Annex.