Trust documents

Data Processing Agreement

Effective date: 2026-10-01

This Data Processing Agreement ("DPA") forms part of the Terms of Service between CrossTenant Ltd, a company registered in England & Wales (company no. 17349672), registered office Unit 82a James Carter Road, Mildenhall, Bury St. Edmunds IP28 7DE ("Vaze") and the Customer. It applies wherever Vaze processes personal data on the Customer's behalf and is written to satisfy Article 28 of the UK GDPR and, where applicable, the EU GDPR. Capitalised terms not defined here have the meaning given in the Terms of Service.

1. Roles of the parties

1.1 Estate data — the main case

The Customer is the controller (or, where the Customer administers an estate for another organisation, a processor of that organisation) of the personal data Vaze reads from a Connected Vendor — members, seats, API-key ownership records and per-person usage — of the history Vaze keeps of those reads, and of the digest and report recipients the Customer selects. Vaze processes that data as processor (or sub-processor) on the Customer's documented instructions under section 2. Connector requests send authentication material and the identifiers and query parameters needed for the requested administrative API operation. Scheduled collection does not upload Vaze's stored estate history. Configured digests and reports deliver their content to the recipients the Customer selects, using the delivery provider described on the sub-processor page.

1.2 What this DPA does not cover

Two categories exist so that the Service can be secured and made accountable, and the Customer cannot instruct Vaze to stop keeping them while using the Service:

• Operator accounts — sign-in identities, role bindings and session records of the Customer's own Authorised Users.
• The audit trail — the record of writes and sensitive reads performed through the console. It is deliberately minimised: a record identifies the operator, the estate, the class of operation and the outcome, with structural summaries in place of raw request content, targets, reasons or client prose, outside narrow disclosed exceptions.

Vaze holds these as independent controller, for its own security, integrity and accountability purposes; the Customer is a separate controller of any audit entries it views or exports. Sections 5, 9 and 12 are applied to them as a matter of contract regardless.

1.3 Connected Vendors

Connected Vendors are not Vaze's sub-processors. Each processes personal data under the Customer's own agreement with it. Vaze reads their administrative APIs on the Customer's instruction, and the Customer is responsible for having the right to give that instruction. The supported direct write sends the target project and rate-limit identifiers and the new rate limit to OpenAI only through the explicitly approved and human-executed action path, using the Customer's credential.

2. Scope, duration and instructions

This DPA applies for as long as Vaze processes personal data for the Customer, and its surviving obligations continue afterwards. Annex I describes the subject matter, nature, purpose, data types and data subjects.

Vaze will process personal data only on the Customer's documented instructions, which are: the Terms of Service, this DPA, the configuration and actions the Customer's Authorised Users perform in the console, and any further written instruction the parties agree. We will not process it for any other purpose, and in particular we do not use it to train machine-learning or AI models, sell it or use it for advertising.

Connecting a vendor is a standing instruction to read that vendor's administrative API on the daily schedule and on demand until the vendor is disconnected. Enabling a digest or report schedule is a standing instruction to generate and deliver it at the configured times until the schedule is disabled. Approving and executing an action is an instruction to perform that one change at the vendor.

We will tell the Customer if we consider an instruction infringes data-protection law, and may pause the affected processing while it is resolved. If we are required by law to process personal data other than on the Customer's instructions, we will inform the Customer beforehand unless the law prohibits it.

3. Confidentiality

Vaze ensures that anyone it authorises to process personal data is bound by confidentiality. At this release there is one Vaze super-administrator and no narrower staff role; see Annex II §2.

4. Security

Vaze implements the technical and organisational measures in Annex II. They are described from the software as built, and Annex II also states what is not in place, so that the Customer's own assessment starts from facts.

5. Sub-processors

The Customer authorises the sub-processors listed at vaze.ai/subprocessors, which is the canonical list. Before adding or replacing a sub-processor we will give at least 30 days’ notice, by updating the sub-processor page and e-mailing the Customer’s primary account contact (and any billing contact named in a paid Order), before the new sub-processor begins processing personal data; a Customer that objects on reasonable data-protection grounds may terminate the affected service with effect from the change date. Vaze remains responsible to the Customer for each sub-processor's performance.

6. Assistance with data subject rights

Vaze will assist the Customer, by appropriate technical and organisational measures and so far as possible, in responding to requests from data subjects. Per-person usage is stored against a keyed reference rather than a name; a request that names a person is resolved through the vendor's member list and the identity reference. Requests go to privacy@vaze.ai; we confirm identity and respond within one calendar month. Where Vaze is a processor we act on the Customer’s instruction and the Customer answers the data subject. The return-or-deletion process and separate recovery schedules are stated in section 9.

7. Assistance with the Customer's wider obligations

Taking into account the nature of the processing and the information available to it, Vaze will assist the Customer with its security, breach-notification, impact-assessment and prior-consultation obligations.

8. Personal data breach

Vaze will notify the Customer of a personal data breach affecting personal data processed under this DPA within 72 hours of becoming aware of it, and in any event without undue delay, from the security contact published on the security page. The notification will describe, so far as known and supplemented as we learn more, the nature of the breach, the likely consequences, the measures taken or proposed and a contact point. A notification is not an admission of fault. The Customer is responsible for any notification it owes to a supervisory authority or to data subjects.

What the software detects today is stated plainly in Annex II §7: availability and readiness failure, audit-append failure and store corruption. It does not detect intrusion or exfiltration.

9. Deletion and return

9.1 Customer choice and return

At the end of the Service, the Customer may instruct Vaze to return or delete the personal data processed on its behalf. Requests go to privacy@vaze.ai. On a return request, Vaze will provide a machine-readable export of the customer estate data held by Vaze, including retained usage and cost history, reports, readiness answers and configuration where held, then delete its remaining copies under this section. The export is not an export of Connected Vendors' own live member, seat or key inventories. It excludes stored vendor credentials, refresh tokens, credential fingerprints, agent-token hashes and session state. Vaze will verify the requester's authority before releasing an export or carrying out deletion.

9.2 Live deletion

Vaze will complete the instructed return and deletion from its live service within 30 days after termination or a verified earlier deletion request. Live deletion removes the estate's configuration, stored vendor credentials, usage and cost history, report artifacts and readiness answers. Vaze will confirm completion and explain any data retained under sections 9.3–9.4. The Customer should also revoke its connected credentials at the vendor; Vaze's deletion does not itself prove revocation by that vendor or delete records held under the Customer's separate vendor agreement.

9.3 Recovery copies

Recovery copies containing deleted data are restricted to disaster recovery and put beyond ordinary use; Vaze does not use them for analytics, customer access or any other operational purpose. Encrypted off-box snapshots are subject to a daily retention job with a 28-day cutoff measured against the current time, including stopped historical snapshot groups. Retired local recovery payloads follow a separate 28-day retirement procedure. The storage provider additionally operates previous-version and soft-deletion lifecycles, currently configured for 35 and 14 days respectively. Those periods describe separate layers and do not establish a guaranteed total expiry date for every copy. Vaze tracks expiry and investigates failed or overdue deletion. Before a restored service can start, Vaze applies its current signed retirement records; a restored copy that reintroduces a retired estate is refused until the estate has been removed using the reviewed offline procedure or a compatible post-deletion copy is selected. Vaze will explain the applicable recovery schedule and any outstanding restricted copy when confirming deletion. Copies are deleted in accordance with those schedules unless retention is required by law; a legal requirement and its scope will be explained unless prohibited by law.

9.4 Retained controller records

Vaze separately retains the signed termination receipt for 24 months for its own security, integrity and accountability purposes. Completed retirement removes the full named estate audit trail through its signed retirement transition. Minimal keyed anti-recreation markers remain permanently to prevent a retired estate or audit trail from being recreated; they are pseudonymous security records, not represented as legally anonymous. These controller records are not retained customer estate content or permission to restore deleted data. Other independently controlled operator and security records follow the periods or criteria in the Privacy Notice.

10. Audits and information

Vaze will make available the information reasonably necessary to demonstrate compliance with Article 28, starting with the security page and Annex II. Further audit rights are as follows: we first provide our published security documentation and a written response to a security questionnaire, at no charge, ordinarily within 10 business days; where that is genuinely insufficient, the Customer may conduct a documentary or on-site audit on at least 30 days’ written notice, no more than once in any 12-month period except following a personal data breach affecting the Customer or where a supervisory authority requires it; the Customer bears its own audit costs and our reasonable costs of supporting an on-site audit.

11. International transfers

Personal data at rest is held in the United Kingdom. Where a sub-processor processes it elsewhere, the transfer mechanism relied on is the EU Standard Contractual Clauses as supplemented by the UK International Data Transfer Addendum, or the UK Extension to the EU–US Data Privacy Framework where the provider is certified, recorded per provider on the sub-processor page.

12. Liability, precedence and general

Liability under this DPA is subject to the limits in the Terms of Service, section 14. This DPA prevails over the Terms of Service on data-protection matters. It is governed by the law of England and Wales, with the courts of England and Wales having exclusive jurisdiction.

Annex I — Description of the processing

A. Parties

Processor or sub-processor: Vaze, per section 1. Controller: the Customer, or the organisation whose estate the Customer administers, per section 1.

B. Description of the processing

• Subject matter — administration and governance of the Customer's AI vendor accounts.
• Nature and purpose — scheduled and on-demand reads of vendor administrative APIs; storage of the resulting history; rendering of console views, digests and reports; recording of an accountable trail; execution of narrowly registered, human-approved changes.
• Data subjects — the Customer's Authorised Users; the Customer's staff (and, for a managed estate, the managed organisation's staff) as reported by its AI vendors; digest and report recipients.
• Categories of personal data — name, work e-mail, identity-provider identifiers; vendor role and seat assignment; API-key ownership metadata; per-person usage counts held against a keyed reference; operator sign-in and action records.
• Special categories — none intended. The Service reads no prompt or content and has no field for it.
• Duration — for the term of the Terms of Service, then per section 9.

C. Competent supervisory authority

The Information Commissioner's Office (United Kingdom), unless the Customer's establishment makes another authority competent.

Annex II — Technical and organisational measures

Each measure names what is built. Where a control is commonly expected and is not in place, that is said too.

1. Data minimisation

• Connectors read administrative metadata only. No code path requests prompts, conversation content, documents or source code.
• Per-person usage is pseudonymised at the write boundary: rows carry a keyed reference and names are resolved live from the vendor at read time.
• Audit records carry route families and structural summaries, not raw paths, bodies, targets, reasons or client prose, outside narrow disclosed exceptions.

2. Access control and identity

• Federated sign-in only (Google for customers; Microsoft for one pinned directory); no local passwords. Sessions are HttpOnly cookies re-checked against the live user record on every request, so a disable takes effect on the next request.
• Every area is gated by role bindings. Capabilities (approver, break-glass, manage-members) grant no read or write by themselves.
• A Vaze super-administrator can read everything, including the audit trail. There is no narrower Vaze staff role at this release; today that is one person.

3. Control over changes

• Vendor writes are propose → approve → execute, never direct. Only a narrowly registered kind of action can execute, and only when an Authorised User explicitly runs it.
• Emergency execution requires a bounded written reason and durably consumes the approval.
• Actions that would change a Connected Vendor are blocked while the audit boundary is degraded.

4. Accountability

• Writes, and the reads of person-identifying surfaces, are recorded with signed intent before the operation and terminal evidence after it.
• Audit records are hash-chained. The properties and the two stated limits of that chain are set out verbatim on the security page; that text is the only description Vaze gives of audit integrity.
• A failed audit append is durably latched and surfaced as incomplete rather than silently repaired.

5. Cryptography and secret handling

• Vendor credentials and state files are written with owner-only permissions (0600) and are read server-side only. No browser endpoint returns credential material.
• Storage relies on Azure managed-disk server-side encryption with platform-managed keys, Azure's default. Vaze applies no additional application-level encryption and uses no customer-managed key.
• Transport is TLS at the Cloudflare edge; the application listens on loopback only and is reached through an authenticated tunnel.

6. Availability and integrity of state

• A corrupt or unreadable state store refuses to write rather than overwrite, preserving the original bytes.
• Writes are atomic (temp file, fsync, rename) and a startup lock refuses a second instance on the same data directory.
• The dedicated Vaze runtime has a daily encrypted off-host backup to selected-network Azure storage in UK South and an independently escrowed repository password. Its independent 28-day wall-clock retention job is enforced across all seven reviewed snapshot groups; real prune/full-read activation passed on 2026-10-01. Actual failure and recovery notifications passed through the existing external readiness monitor on 2026-09-30. Section 9 distinguishes this control from the unproved all-copy deadline. An isolated restore passed byte, audit-chain, estate and IAM verification; the release receipt remains in the deployment runbook.

7. Monitoring and incident detection

• An external monitor polls the authenticated readiness endpoint every three minutes and e-mails the responder on failure and recovery. Persistent host logs are retained on a bounded budget.
• Not built: intrusion or exfiltration detection, continuous automatic restore testing or 24/7 response. Backup-job heartbeats and independent retention/readiness alerts are operational checks, not intrusion detection or continuous recovery assurance.

8. Assurance

• No SOC 2, ISO 27001, penetration test or cyber insurance. Automated tests and a production dependency audit run on every change.

Annex III — Sub-processors

The canonical list, with purpose, data reached, location and transfer mechanism, is at vaze.ai/subprocessors.

Contact

privacy@vaze.ai