Privacy Policy

Last updated: 1 September 2026

Operator / data controller: CrossTenant Ltd, a company registered in England & Wales (company no. 17349672), registered office Unit 82a James Carter Road, Mildenhall, Bury St. Edmunds, IP28 7DE, United Kingdom. Contact: toby@crosstenant.com. Our registration with the Information Commissioner’s Office (ICO) is in progress; the registration number will be published here once issued.

This policy explains what information CrossTenant (“we”, “us”) accesses, how we use it, what we do and do not store, and the choices and rights you have. It covers both this website (crosstenant.com) and the CrossTenant application — a Google Workspace management console used by managed service providers (“MSPs”, and each subscribing MSP a “Customer”) to administer the Google Workspace organisations they manage (each a “Managed Organisation”). CrossTenant is operated from the United Kingdom.

1. What CrossTenant is, and whose data is involved

CrossTenant is an administration tool. A customer organisation’s Google Workspace super-administrator authorises CrossTenant (via Google OAuth consent and, for some features, domain-wide delegation) so that the MSP the organisation has contracted can perform Workspace administration on its behalf — user lifecycle management, security remediation, device actions, mail and Drive governance, and compliance reporting.

Three kinds of people interact with CrossTenant:

• MSP operators — the engineers who sign in to the console;
• Customer administrators — the Workspace admins who authorise access for their organisation;
• End users of customer organisations — whose directory and account information is displayed to authorised MSP operators as part of administration. End users do not interact with CrossTenant directly.

For customer organisation data, the customer organisation remains the data controller; CrossTenant processes that data on the instructions of the organisation and its contracted MSP, solely to provide the administration features described here, under our written data processing agreement (Article 28 UK GDPR) with the MSP. For the data CrossTenant holds in its own right — MSP-operator accounts and audit logs — CrossTenant is the data controller. Individuals within a customer organisation should raise requests about their Workspace data with their own organisation (the controller) first.

2. Information we access through Google APIs

When a customer administrator authorises CrossTenant, the console accesses Google Workspace data via Google’s APIs, limited to the scopes granted. Depending on the features in use, this includes:

3. How we use this information (purposes and lawful bases)

• Solely to provide the console’s administration features to authorised MSP operators acting for the customer organisation.
• When an Authorised User saves and enables a report schedule, that is the Customer’s standing instruction for CrossTenant to regenerate and deliver that report at the configured times until the schedule is disabled or deleted.
• We do not use Google user data for advertising, and we do not sell it to anyone.
• We do not use Google user data to train machine-learning or AI models.
• Humans at CrossTenant do not read Google user data except with the customer’s or MSP’s explicit permission for support, where required for security investigation or abuse prevention, or where required by law.

For the data CrossTenant controls in its own right, our UK GDPR Article 6 lawful bases are:

• Operator accounts — performance of a contract (Art 6(1)(b)) with the MSP and/or our legitimate interests (Art 6(1)(f)) in operating a secure console.
• Audit logs — our legitimate interests (Art 6(1)(f)) in securing and operating the console and keeping an accountable record of administrative actions.

Providing your name and email is necessary to create an operator account; without it we cannot grant you console access. For customer Workspace data, CrossTenant is a processor and the customer organisation, as controller, is responsible for the lawful basis.

4. What we store — and what we don’t

CrossTenant’s server-side stores keep no copy of your Workspace content. There is no content database or cache: every screen in the console is a live read from Google’s APIs, rendered for the authorised operator and then discarded. Google-returned directory, mail, file, and calendar observations are not kept as a console data store. An operator may deliberately save a joiner role template containing the configuration described below. We never retain message bodies, source-file contents, document text, or passwords in CrossTenant’s server-side stores, including while a change is waiting for approval.

A scheduled report is a deliberate output, not a CrossTenant content store. CrossTenant generates the PDF in process memory and writes it directly to the root of the Shared Drive selected for that Managed Organisation. No server-side copy of the PDF is retained. The Google Drive file is then governed by the Managed Organisation’s own Google access controls, retention settings and deletion choices. It remains there after the schedule is disabled or deleted, and after CrossTenant access is revoked or the Managed Organisation is offboarded, unless it is deleted under those Google controls.

Seven categories of data do rest on the console, each for a stated purpose and period:

• The authorisation your administrator grants — the OAuth token and service-account configuration for your organisation, the primary domain, and the administrator’s own contact address. Stored isolated per customer and used only to make the API calls described above. Held only while you are a customer and ordinarily deleted when you offboard. If a Shared Drive creation outcome is unresolved, local offboarding and deletion of these credentials pause until that exact attempt is reconciled; this prevents the same request being repeated under changed authority. You can still revoke Google-side access immediately in the Google Admin Console or via Google account settings.
• The audit log — one record per write attempted through the console (including rejected attempts): when, which customer organisation, which operator (their console identity and email address, and the IP address they acted from), the kind of operation (the request method and a fixed operation family — never the full request URL, whose dynamic segments could carry a person’s identifier), the result, and a bounded, structured summary of what was submitted — field counts, value types, and outcome markers such as success and failure counts, with secret-like values redacted and free-text, content, and identifying values omitted entirely. The record is deliberately minimised: it does not retain the identifier of the account or record an action targeted, the operator’s free-text notes or reasons, or the values of the settings that changed. Two narrow, deliberate exceptions retain more, because accountability there demands it: a break-glass execution records the acting super-administrator’s written reason (bounded in length), and a record may carry one explicit, protected target reference where a specific accountability case requires it. It contains no message or file content and no credentials. Each record is cryptographically chained to the one before it, so tampering is detectable, and what the console’s own screens show of the log is a stricter projection still — time, customer scope, operation class, outcome, and acting operator. Retained for a maximum of 24 months, then automatically deleted — including after the relationship ends, because the accountability record is the reason it exists.
• Pending change approvals — where your MSP requires a second person to approve a change, we hold the requesting and approving operators’ identities, the intended action, the customer organisation, and the specific record it targets (which is usually a user’s email address), together with any forwarding, delegate, transfer, or send-as address the change involves. A pending top-level Shared Drive creation additionally holds the exact requested Drive name and a one-way tenant-authority binding, so it cannot execute after that tenant identity is replaced. We never hold a preview of the result, and never the password, signature, or message text a change would set. Pending requests expire within 7 days; resolved records are deleted after 30 days. Offboarding expires any request that still targets that Managed Organisation before its local authority is removed.
• Operator accounts and console configuration — MSP operator sign-in identities (name, email), role and permission assignments, and a short per-operator sign-in history (timestamp, identity provider, IP address, browser user-agent; the most recent sign-ins only). Plus the configuration your MSP authors: report templates, schedules, alert rules, notification recipient addresses and any webhook endpoint URLs, approved policy baselines, operator-written report notes, customer-supplied branding used on generated reports, and saved joiner role templates. A Drive-delivery schedule stores only the Managed Organisation identifier (tenantId) and selected Shared Drive identifier (driveId) needed to target the output; it stores no Drive name, path, URL, or PDF content. A joiner template contains selected onboarding steps and role settings such as org unit, groups, licence, password-change rule, an optional delegate mailbox, and optional signature HTML. It cannot contain a joiner’s name, aliases, or password as dedicated template fields, although an operator can type personal data into the delegate or signature fields. Authorised operators can delete templates in the console. This configuration is retained while the operator/MSP relationship is active, then deleted. Where the optional AI assistant drafts an action that is parked for a second operator’s approval, the operator’s typed question is held (truncated) as part of that approval record for as long as the record itself is kept; the durable audit log marks an action as AI-assisted but deliberately does not retain the question text.
• Scheduled joiners awaiting review — where your MSP prepares a new starter ahead of their start date, we hold that one proposal: the person’s primary email address, given and family name, any aliases and send-as display name your MSP entered for them, the customer organisation, the chosen start date and time zone, the selected onboarding steps, and a reference to the saved joiner role template it was prepared from. It never holds a password, and it never holds a copy of the template’s own contents. Nothing about it runs on its own: when the start time passes, the record is marked ready for review, and an operator with current authority has to open it, re-check it and run the joiner themselves. The person’s name, email address and entered values are removed the moment the record is completed, cancelled, or expires unreviewed, leaving only identifiers, timestamps and status; the record itself is deleted 30 days after the start date. Offboarding a Managed Organisation removes its scheduled joiners.
• Provider-effect custody evidence — bounded technical state prevents an interrupted scheduled delivery or Shared Drive creation from being repeated as though nothing happened. Delivery custody records the schedule identifier, delivery window, opaque attempt identifiers and outcome markers; an ambiguous Shared Drive upload can additionally hold the exact reserved Google file identifier until an authorised operator reconciles it and re-arms the schedule. That delivery custody stores no file name, Drive name, path, URL, report data or PDF content. For one unresolved top-level Shared Drive creation per Managed Organisation, provisioning custody temporarily holds the exact operator-entered Drive name, Google request identifier, service-account and authority digests, optional candidate Drive identifier, state and timestamps. The name can itself contain personal data, so it is owner-only and kept only until the confirmed outcome is acknowledged or the exact attempt is resolved through the controlled recovery path. No file content is held by either custody store.
• Derived health metrics — per customer organisation, six numeric scores, an overall A–F grade, and a timestamp. There is no free-text field, so no names, email addresses, or content are recorded. Encrypted at rest with AES-256-GCM. Only the most recent computation is kept — each recomputation replaces the last, so no history accumulates. A record is served for at most 24 hours before being recomputed, is deleted automatically by a daily sweep once it has not been refreshed for 90 days, and is removed when a customer offboards.

When a Managed Organisation offboards, pending approvals that target it are expired before local authority is removed. If a Shared Drive creation outcome is unresolved, local offboarding — including deletion of stored credentials and CrossTenant configuration — pauses until that exact attempt is reconciled. Provider-effect custody evidence is not silently discarded, because doing so could authorise a duplicate delivery or Shared Drive creation. Google-side report files are not CrossTenant configuration and are not deleted by offboarding. Customers and Managed Organisations can request deletion at any time via the contact below; Google-side access can still be revoked unilaterally and immediately on the Google side. The audit log is the only category kept after the relationship for a fixed retention period, and is retained to its 24-month cap as described above; unresolved provider-effect custody is kept only for the bounded reconciliation purpose just described.

5. Optional AI features

CrossTenant includes optional AI features: executive summaries on generated reports and an assistant in the console. When used, these send the operator’s typed question together with sanitised configuration and posture context — settings values, counts, metrics, and summary statistics (for example “3 users have external forwarding enabled”) — to Anthropic’s Claude API to generate text. Every AI request passes through a redaction guard: no mailbox or file content is ever sent. The assistant can additionally draft a proposed administrative action, but a draft is only ever a proposal — the assistant cannot execute anything. An authorised operator must review, confirm, and execute every action, and AI-assisted actions are marked as such in the audit log. Where an AI-drafted action is parked for a second operator’s approval, the approval record additionally holds the operator’s typed question (truncated) while that record is retained, so the change can be traced back to what was asked; the durable audit log itself deliberately does not retain the question text. Per Anthropic’s API terms, data sent to the API is not used to train Anthropic’s models. If you prefer these features not be used for your organisation, tell your MSP — they are optional and can be left unused.

6. Who we share information with

We share data only with the service providers needed to run CrossTenant:

• Google — inherently: the console operates on Google Workspace via Google’s APIs, under the Managed Organisation administrator’s authorisation. Where the Customer configures Shared Drive delivery, Google also receives the generated PDF directly into that Managed Organisation’s selected Shared Drive.
• Anthropic PBC (United States) — only the operator questions and sanitised configuration/posture context described in section 5, and only when AI features are used. No Workspace message or file content is sent to Anthropic.
• Cloudflare, Inc. (United States) — hosts this website and provides DNS, authenticated access control and network routing for the private console. Cloudflare processes console traffic while proxying it; API responses are marked non-cacheable and are not stored in its content cache.
• Microsoft Ireland Operations Limited — Microsoft Azure hosts the private console in its UK West region, so Microsoft processes stored console data and live API data while the instance handles a request. Workspace content is not retained. Where an MSP chooses Microsoft sign-in, Microsoft also processes those operators’ sign-in identities. Azure Communication Services Email delivers CrossTenant-hosted invitations and configured outbound email; it can receive the recipients, subjects, bodies, attachments and delivery metadata described on the sub-processor page.

The complete, always-current list — including each provider’s purpose, the data it can reach, its processing location, and the transfer mechanism relied on — is published at crosstenant.com/subprocessors. That page is the canonical list and governs if this section ever falls out of step with it. For a Customer whose DPA is already in force, we publish and email notice of a later provider addition or replacement at least 30 days before it begins processing personal data under that DPA. Providers already listed as Current when a Customer contracts form part of the disclosed list authorised at signing.

International transfers. Anthropic and Cloudflare process data in the United States, and Microsoft may use locations outside the United Kingdom as permitted by its DPA. These transfers are made under appropriate safeguards: for Cloudflare, the UK Extension to the EU–US Data Privacy Framework; for Anthropic, Standard Contractual Clauses as supplemented by the UK International Data Transfer Addendum, incorporated via Anthropic’s Data Processing Addendum; and for Microsoft, the 2021 Standard Contractual Clauses and UK International Data Transfer Addendum in Microsoft’s Products and Services Data Protection Addendum.

We do not sell personal data. We do not share it with advertisers. We may disclose information if required by law, or to protect the rights, safety, or security of CrossTenant, our customers, or others.

7. This website, and the console’s own server logs

crosstenant.com is a static informational site. It sets no advertising or tracking cookies. Standard server logs (IP address, user agent, pages requested) may be processed by Cloudflare, which hosts the site, for security and performance purposes.

Separately, the private hosted console runs on Microsoft Azure in the UK West region and is reached through Cloudflare’s authenticated edge and outbound-only tunnel. Cloudflare processes console traffic while proxying it, but API responses are marked non-cacheable. The console application writes operational logs on its Azure-hosted server — the ordinary record of requests, warnings, and errors that any server produces, used for diagnosis and for detecting problems. Where a call to Google fails, the error text Google returns is recorded, and that text can include a domain name, a user’s email address, or a project identifier. These logs are not a data store and are not queried as one; they are held on the same infrastructure, under the same access controls, as everything else described in section 8, and are rotated and discarded on the operating system’s ordinary schedule.

8. Security

• All data in transit is encrypted with TLS. Stored files are restricted to the console’s own service account, and the console requires the infrastructure it runs on to provide full-disk encryption; the derived health metrics described in section 4 are additionally encrypted by the application itself.
• Credentials and audit logs are isolated per customer; one customer’s authorisation can never access another customer’s data.
• Access follows least privilege: read-only customers receive only read-only OAuth scopes at Google consent. Domain-wide delegation is separately customer-approved and its current grant may include write-capable scopes; the console requests scopes per operation and refuses mutations for read-only customers.
• Write operations require explicit operator confirmation and are recorded in the per-customer audit log. Audit records are cryptographically chained so that alteration is detectable.
• Elevated changes can be held until a second authorised operator approves them; a requester can never approve their own request.
• MSP operator access is governed by per-customer, per-area role-based access control. Operators sign in through Google or Microsoft; CrossTenant holds no passwords.

A fuller technical description — including what we deliberately do not claim — is published at crosstenant.com/security. Security issues can be reported to security@crosstenant.com; our disclosure policy is on the support page.

In the event of a personal-data breach affecting your data, we will notify affected customer administrators without undue delay and meet our regulatory notification obligations.

The CrossTenant console uses only strictly-necessary cookies (your sign-in session) and browser local storage for interface preferences (theme, sidebar state, customer scope, table layout); it stores no customer or tenant data in the browser, and sets no advertising, analytics, or tracking cookies, so no cookie-consent banner is required.

9. Your rights

Where UK GDPR / GDPR or similar laws apply, you have rights over your personal data, including access, correction, deletion, restriction of processing, data portability, and objection. For operator-account and audit-log data (where CrossTenant is the controller) these are exercised directly with us; for customer Workspace data (where CrossTenant is a processor) requests go to the customer organisation and we assist. If you are an end user of a customer organisation, your organisation (the data controller) and its MSP are usually the right first contact — but you can also reach us directly below and we will help route your request. Customer administrators can revoke CrossTenant’s access entirely at any time in the Google Admin Console or via Google account permissions. You also have the right to complain to a supervisory authority — in the UK, the Information Commissioner’s Office (ICO).

CrossTenant does not carry out solely-automated decision-making or profiling that produces legal or similarly significant effects. AI features are advisory only and a human operator decides and confirms every action.

10. Children

CrossTenant is a business administration tool and is not directed at children. We do not knowingly collect personal data from children, except insofar as a customer organisation’s directory may include accounts it administers (for example, in education deployments), which we process only on that organisation’s instructions.

11. Changes to this policy

We will post any changes to this policy on this page and update the “Last updated” date above. Material changes affecting how Google user data is handled will be communicated to customer administrators before they take effect.

12. Contact

The data controller for this service is the entity named at the top of this policy. Questions, requests, or concerns: toby@crosstenant.com.