Data Processing Agreement

Last updated: 31 August 2026

This Data Processing Agreement (“DPA”) forms part of the Terms of Service between CrossTenant Ltd (company no. 17349672, registered office Unit 82a James Carter Road, Mildenhall, Bury St. Edmunds, IP28 7DE, United Kingdom) and the Customer. It applies wherever CrossTenant processes personal data on the Customer’s behalf, and satisfies Article 28 of the UK GDPR and, where applicable, of the EU GDPR. Capitalised terms not defined here have the meaning given in the Terms of Service.

1. Roles of the parties

1.1 Managed Organisation data — the main case

For personal data within a Managed Organisation’s Google Workspace:

• the Managed Organisation is the controller. It decides why and how its own Workspace data is processed, and it authorises CrossTenant’s access through its own super-administrator;
• the Customer (the MSP) is a processor acting on that organisation’s instructions, under the Customer’s own agreement with it;
• the CrossTenant is a sub-processor to the Customer, engaged under Article 28(4). Where the Customer is instead a controller in its own right in relation to particular processing, CrossTenant is its processor for that processing, and this DPA reads accordingly.

The Customer confirms that it has the authority described in section 4 of the Terms of Service, and that its agreement with each Managed Organisation permits our engagement on these terms. CrossTenant has no direct contractual relationship with the Managed Organisation and takes its instructions from the Customer.

1.2 What this DPA does not cover

CrossTenant is an independent controller, not a processor, for two categories of data, and this DPA does not govern them:

• MSP operator accounts — the sign-in identities, roles, permission assignments, session records and sign-in history of the Customer’s own engineers;
• the write-audit log — the accountable record of administrative actions performed through the console.

We are the controller for those because we determine that they exist, what they contain, and how long they are kept — they are how the service is secured and made accountable, and the Customer cannot instruct us to stop keeping them while using the service. Our handling of them is described in the privacy policy. The audit log is deliberately minimised: a record identifies the operator, the customer scope, the class of operation and the outcome, and — outside two narrow, disclosed exceptions — does not retain the identifier of the account an action targeted; the record is of the action, not of any person’s activity. Sections 5, 9 and 12 of this DPA are applied to that data as a matter of contract even though we hold it as controller.

2. Scope, duration, and instructions

This DPA applies for as long as CrossTenant 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.

CrossTenant 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 models, sell it, or use it for advertising.

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 on important grounds of public interest.

3. Confidentiality

CrossTenant ensures that every person authorised to process personal data under this DPA is bound by an appropriate duty of confidentiality, has been made aware of the confidential nature of the data, and is granted access only to the extent their role requires.

4. Security

CrossTenant implements and maintains the technical and organisational measures set out in Annex II, which are appropriate to the risk under Article 32. We may update those measures as the service develops, provided the level of protection is not reduced. The most significant measure is architectural: the service does not store Google Workspace content, so the great majority of the Customer’s customers’ personal data is never at rest with us at all. Annex II states precisely what is.

5. Sub-processors

The Customer gives general written authorisation for CrossTenant to engage sub-processors. The current list, with each sub-processor’s purpose, location, and transfer mechanism, is published at crosstenant.com/subprocessors and forms Annex III. A provider already listed as Current when the Customer enters into this DPA is part of the disclosed list the Customer authorises at that point.

• For an existing Customer, we give at least 30 days’ notice before an addition or replacement to that authorised list begins processing personal data under this DPA, by updating that page and emailing the Customer’s billing contact. This is a notice period for a change made after the Customer’s DPA is in force, not a waiting period for a provider already listed as Current when the Customer contracts.
• The Customer may object within that period on reasonable, documented data-protection grounds. We will work in good faith to address the objection, including by making the relevant feature optional or unavailable. If we cannot, the Customer may terminate the affected part of the subscription without penalty and receive a pro-rata refund of prepaid fees.
• Each sub-processor is engaged under a written contract imposing data-protection obligations no less protective than those in this DPA, and CrossTenant remains fully liable to the Customer for its sub-processors’ performance.

Google is a special case and is treated as such in Annex III: the Workspace data CrossTenant reads already resides with Google under the Managed Organisation’s own agreement with Google. CrossTenant does not place that data with Google; it retrieves it from there.

6. Assistance with data subject rights

Because CrossTenant stores no Workspace content, a data subject’s personal data almost always remains in the Managed Organisation’s own Google Workspace, where the controller can act on it directly — which is normally the fastest route for everyone.

Taking that into account, CrossTenant will assist the Customer by appropriate technical and organisational measures, insofar as possible, in fulfilling obligations to respond to requests to exercise data subject rights. If a request reaches us directly, we will not respond to it ourselves except to acknowledge it and direct the individual appropriately, and we will inform the Customer without undue delay. Assistance is provided at no charge for reasonable volumes.

7. Assistance with the Customer’s wider obligations

Taking into account the nature of the processing and the information available to us, CrossTenant will assist the Customer in complying with its obligations under Articles 32 to 36 — security of processing, breach notification, data protection impact assessments, and prior consultation. This includes providing the information in this DPA, the security page, and reasonable responses to security questionnaires.

8. Personal data breach

CrossTenant will notify the Customer without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting personal data processed under this DPA. The notification will describe, so far as known at the time and supplemented as we learn more:

• the nature of the breach, including the categories and approximate number of data subjects and records concerned;
• the likely consequences;
• the measures taken or proposed to address it and mitigate its effects;
• a contact point for further information.

We will cooperate with the Customer and take reasonable steps as it directs to assist in investigating, mitigating, and remediating the breach. A notification under this section is not an admission of fault or liability. The Customer is responsible for any notification it or a Managed Organisation owes to a supervisory authority or to data subjects.

9. Deletion and return

On termination of the Terms of Service, or earlier on the Customer’s written request:

• CrossTenant deletes the stored authorisation credentials for each Managed Organisation, and the console configuration held for the Customer, ordinarily within 30 days;
• because no Workspace content is stored, there is no bulk export to return. Reports and data the Customer generated remain available to it until access ends, and we will assist with a reasonable export request made before then;
• the Customer can, and should, additionally revoke CrossTenant’s access in each Managed Organisation’s Google Admin Console. That revocation is immediate, is entirely within the Managed Organisation’s control, and does not depend on us.

Exception — the write-audit log. The audit log is retained for a maximum of 24 months from the date of each entry, then deleted automatically, including after termination. It is retained as the accountable record of privileged administrative actions taken against Managed Organisations, in the legitimate interests of CrossTenant, the Customer, and those organisations; a documented legitimate interests assessment supports this, and it contains no Workspace message or file content. This is the only category we retain beyond the deletion window.

10. Audits and information

CrossTenant will make available to the Customer the information reasonably necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates.

In practice, and to keep this proportionate:

• we will 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 an 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), during business hours, without unreasonable disruption, and subject to confidentiality;
• the Customer bears its own audit costs and our reasonable costs of supporting an on-site audit;
• an audit must not give access to another customer’s data or to any Managed Organisation’s data, and we will refuse anything that would.

11. International transfers

CrossTenant is established in the United Kingdom and processes personal data in the United Kingdom and the European Economic Area, except for the sub-processors identified in Annex III as processing elsewhere.

Where personal data is transferred out of the UK or the EEA to a country without an adequacy decision, that transfer is made under an appropriate safeguard under Article 46 — the UK International Data Transfer Agreement, or the EU Standard Contractual Clauses as supplemented by the UK Addendum, as identified for each sub-processor in Annex III. Where the UK Addendum applies, it is incorporated into this DPA and, unless the parties agree otherwise: the Customer is the exporter and CrossTenant the importer; the appendix information is taken from Annexes I and II; and neither party may end the Addendum under Section 19 of the Approved Addendum.

Google Workspace data resides in the region the Managed Organisation has configured with Google, under its own agreement with Google. CrossTenant does not relocate it.

12. Liability, precedence, and general

• Each party’s liability under this DPA is subject to the limitations and exclusions in section 14 of the Terms of Service.
• If this DPA conflicts with the Terms of Service, this DPA prevails on data-protection matters. If it conflicts with the transfer clauses incorporated under section 11, those clauses prevail.
• The sub-processor page is incorporated as Annex III and, being maintained continuously, prevails over any list reproduced elsewhere.
• This DPA is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction, except where the incorporated transfer clauses require otherwise.

Annex I — Description of the processing

A. Parties

Exporter / controller or processor: the Customer, as identified in the Order.
Importer / processor or sub-processor: CrossTenant Ltd, Unit 82a James Carter Road, Mildenhall, Bury St. Edmunds, IP28 7DE, United Kingdom. Contact: privacy@crosstenant.com.

B. Description of the processing

C. Competent supervisory authority

The Information Commissioner’s Office (ICO), United Kingdom, in relation to UK GDPR. Where the EU GDPR applies to a transfer, the competent authority is that of the exporter’s establishment or, where it has none in the EEA, of the Member State where the data subjects concerned are located.

Annex II — Technical and organisational measures

These are the measures implemented in the CrossTenant service. A private CrossTenant-hosted release is running for founder dogfood on Microsoft Azure in the UK West region (United Kingdom); it is not yet a generally available customer service. The current hosted controls are identified below. Backups remain a separately identified future control and are not claimed as live. CrossTenant also supports an operator-controlled deployment, where disk encryption, network exposure and backups are the Customer’s responsibility to the specification we document. Every application measure applies either way.

1. Data minimisation — the primary control

• No content storage. Google Workspace data is fetched live for each request, rendered, and discarded. There is no database and no cache of directory, mail, Drive, calendar, or device data. API responses are marked non-cacheable so they are not written to the operator’s browser disk either, and content caching is disabled at the network edge for API paths.
• A standing rule for new storage. Every proposal to store a new class of data must answer a fixed set of questions — exact fields, location, encryption, retention and the mechanism enforcing it, read path, custody, and the effect on this Annex — and receive an explicit decision before it is built. Classes that would hold observations about a Managed Organisation’s people are refused, with a no-storage alternative recorded.
• What is stored is limited to: authorisation credentials; operator accounts and access policy; the write-audit log; operator-authored configuration (report templates, schedules, alert rules, notification recipients, policy baselines, branding, and joiner role templates containing selected steps, role settings, an optional delegate address, and optional signature HTML); and derived numeric health metrics per Managed Organisation, which are sealed with AES-256-GCM, cannot represent names or addresses by schema, keep only the most recent computation (each recomputation replaces the last), are served for at most 24 hours before recomputation, are deleted automatically once not refreshed for 90 days, and are removed on offboarding. Joiner templates refuse dedicated fields for the joiner’s name, aliases, or password, but an operator can enter personal data in the delegate or signature fields.
• AI boundary. Where optional AI features are enabled, every payload passes a server-side redaction guard that removes mailbox and file content before transmission. An automated test fails the build if raw content can reach that boundary.

2. Access control and identity

• Operator sign-in is federated to Google or Microsoft; CrossTenant never holds operator passwords. Identity is keyed to the provider’s stable subject identifier, not to an email address, so a renamed account keeps one audit identity.
• Access is invite-only: an identity must be pre-created, or belong to an allowed domain, before it can sign in. Multi-tenant Microsoft authorities are refused outside development, so an email claim cannot be asserted from an attacker-controlled directory.
• Authorisation is role-based and granular to the level of (Managed Organisation, functional area), with roles and groups resolving to an effective policy. Disabling an account survives re-authentication, and an account-wide timestamp invalidates all existing sessions on demand.
• Least privilege to Google: a Managed Organisation marked read-only receives only read-only OAuth scopes at Google consent. Domain-wide delegation is separately customer-approved and its current grant may include write-capable scopes; delegated requests ask only for the scopes the specific operation needs, mutations are refused for read-only organisations, and per-organisation scope narrowing is supported.
• Credentials, tokens, and audit logs are isolated per Managed Organisation. One organisation’s authorisation cannot reach another’s data.

3. Control over changes

• Every write operation requires explicit operator confirmation in the interface.
• An optional approval gate parks elevated operations — bulk actions, standards deployment, and administrator-selected classes of single-record change — until a second, separately authorised operator approves them. The requester can never approve their own request. A super-administrator break-glass path exists, requires a written reason, and is recorded and displayed as such rather than being indistinguishable from a normal approval.
• A parked request holds no preview of the change at rest; sensitive values such as passwords and message text are not stored while it waits, and are regenerated or preserved at execution.
• Requests expire if unapproved, approvers are reminded before expiry, and a request that nobody is currently authorised to approve is surfaced to super-administrators rather than expiring silently.

4. Accountability and audit

• Every mutating request (including a rejected one) is written to an append-only log, per Managed Organisation, recording the time, the organisation, the operator identity and email, the request method and a fixed route family (the full request URL is never persisted, because its dynamic segments and query values can carry a person’s identifier), the originating IP, the result, and a bounded, structured summary of the submitted input — field counts, value types, and curated outcome markers such as success and failure counts. Secret-like values are replaced with a redaction marker; free-text, content-like, and identifying values — including the identifier of the account or record targeted, reasons, notes, and typed AI questions — are omitted entirely; strings are truncated and structures reduced to counts. Two narrow, deliberate exceptions retain more: a break-glass execution records the acting super-administrator’s bounded written reason, and a record may carry one explicit, protected target reference where a specific accountability case requires it. Browser and API consumers never read the raw log; they receive a strict, versioned projection limited to the time, customer scope, method, server-classified operation class, outcome, and acting operator’s email.
• Entries are chained with a keyed HMAC so that removing, reordering, or editing an entry breaks verification. Verification is available on demand, and the log fails closed — an entry without valid integrity data is treated as invalid rather than trusted. A re-chaining tool supports key rotation. The chain detects alteration but does not by itself detect truncation of its own most recent entries; an off-machine append-only sink is specified and not yet implemented, so the control is described as tamper-evident rather than tamper-proof.
• Audit reads are themselves permission-gated. The log is excluded from third-party synchronisation services, and the server warns at startup, and refuses in production, if its data directories sit inside one.
• Retention is capped at 24 months and enforced by an automated pruner, not by policy alone. Operator sign-in history is capped both by age and by number of entries.

5. Cryptography and secret handling

• All data in transit is encrypted with TLS.
• Delegated access to a Managed Organisation is authenticated without long-lived private key files: assertions are signed through Google’s IAM credentials service. The legacy key-file path is refused in production.
• On-disk files are written atomically and restricted to the service account (files 0600, directories 0700), swept at startup. The server refuses to start in production with a placeholder or reused security secret.
• Stored customer authorisation credentials are protected by filesystem permissions and by encryption of the underlying storage volume, not by an application-layer encryption envelope. In the private Azure-hosted release that storage is an Azure managed disk encrypted at rest with platform-managed keys. The derived-metrics store is the exception and is additionally sealed with AES-256-GCM. An application-layer secrets store is planned and not yet implemented; this is stated rather than implied.
• (current private hosted release) Persistent data sits on an Azure managed disk encrypted at rest with platform-managed keys. Application secrets are injected by the host at run time and kept outside the persistent data root. No backup or restore capability is claimed as a current control; the future backup contents will be encrypted before upload and the control will not be claimed until a restore has been rehearsed.

6. Network and operational security

• (current private hosted release) The application is reachable only through an authenticated Cloudflare Access gateway over an outbound-only Cloudflare Tunnel; no application service port is publicly exposed. API responses are excluded from edge caching, and query strings are excluded from edge logs.
• (future hosted control — not yet live) A separate Azure subscription is reserved for encrypted off-host backups, but no storage account exists and no backup has been uploaded or restored. Before use, the UK region and retention controls will be fixed, transient report artefacts will remain excluded, backup contents will be encrypted before upload, and a restore will be rehearsed. This is a commitment, not a current control.
• On a CrossTenant-hosted instance, invitations, generated reports and alert digests are delivered through Microsoft Azure Communication Services Email, identified in Annex III. CrossTenant does not persist those messages or attachments as a console data store after handing them to the transport. A fallback that would write report artefacts to disk when delivery is impossible is disabled by default in production and we keep it disabled; were it ever enabled, this Annex and the privacy policy would be updated first.

7. Assurance

• An automated test suite of several thousand tests gates every release, including tests that specifically pin security behaviour: authorisation completeness, fail-closed defaults, redaction, and scope minimisation.
• The codebase has been subject to repeated adversarial security review, and findings are tracked to closure. Controls are annotated in code with the finding they close.
• Dependencies are audited and kept current.
• CrossTenant holds no third-party security certification at present. We do not claim ISO 27001, SOC 2, or Cyber Essentials certification, and will say so plainly rather than imply otherwise.

Annex III — Sub-processors

The current list is maintained at crosstenant.com/subprocessors and is incorporated into this DPA by reference. It states each sub-processor’s identity, purpose, the personal data it can reach, its processing location, and the transfer mechanism relied on.

Contact

Data-protection matters: privacy@crosstenant.com. Related documents: Terms of Service · Privacy policy · Sub-processors · Security.