Privacy policy
Last updated 22 August 2026
GrantRoster runs a single, read-only, point-in-time scan of a Google Workspace and produces an access-risk report. This page explains exactly what we receive from Google, what we store, who else touches it, and how you delete it. If anything here is unclear, email hello@statmd.uk.
Who we are
GrantRoster (sole trader), Netherlands. For the Workspace data we read on your instruction we act as a processor under the GDPR and you are the controller: it is your organisation’s data, we read it only to produce the report you asked for, and we act on your documented instructions. For your own account details — the email address you sign in with and your billing records — we act as controller. We will put a written data processing agreement in place with you before we process any Workspace data on your behalf.
What we receive from Google, and why
When your Workspace administrator connects an account, we request three read-only Google Admin SDK permissions. We request no write access of any kind, and we perform no remediation — we cannot change or delete anything in your Workspace.
| What we receive | Permission | Why |
|---|---|---|
| The administrator’s email address and Google account identifier | openid, email | To record which administrator authorised the connection and the scan. |
| An OAuth refresh token, encrypted at rest (AES-256-GCM) | — | To re-run a scan without asking the administrator to consent again. |
| For each account in your Workspace: email address, full name, last sign-in time, whether 2-Step Verification is enrolled and enforced, whether the account is an administrator or delegated administrator, whether it is suspended or archived, its organisational unit, whether a recovery email is present, and when it was created | admin.directory.user.readonly | To identify dormant accounts, accounts without 2-Step Verification, and administrator sprawl. |
| For each third-party application your people have authorised: the client ID, the displayed application name, the permission scopes granted, and how many of your accounts granted it | admin.directory.user.security | To list the third-party applications holding access to your organisation and how broad that access is. |
| A count of the Drive events in the last 90 days that extended access outside your organisation: a link made externally visible, or someone outside your domain given access to an item they previously had none of. We request those audit events, read only the fields that decide whether access moved outside your domain, and keep the number — never a file name, a file identifier, or the identity of the person an item was shared with. If there are more such events than we will read, the report shows the count as a floor ("N+") rather than as a total | admin.reports.audit.readonly | To show how much content is shared outside your domain. |
File contents, names and identifiers
We request no Google Drive or Gmail permission of any kind. File contents, email messages, calendar entries and chat messages are therefore never sent to us at all — that is enforced by Google at the API level rather than by our own restraint, and it is why GrantRoster needs none of Google's restricted scopes.
File names and file identifiers are a narrower story and we would rather state it exactly than round it off. The external-sharing count comes from the Google Admin Reports audit log, and an audit record for a sharing event can carry the identifier and the title of the document it refers to. GrantRoster requests those audit events, reads only the fields that decide whether access moved outside your domain, and reduces each response to a number in memory while it is being processed.
No file name, file identifier or file content is ever stored, logged, returned by our API, or rendered in your report. None of them appears anywhere in our database schema. The external-sharing figures are counts: they tell you how many items were newly shared outside your domain, never which ones.
How we use it
Solely to generate and display the access-risk report to the administrators of your own organisation, to email a summary of that report to the address that requested the scan, and to support you when you contact us. We do not use Google Workspace data for advertising, we do not sell it, we do not use it to train machine-learning models, and we do not use it to build any profile beyond your own report.
Google API Services User Data Policy — Limited Use
GrantRoster’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. We use Google Workspace API data solely to provide the access-risk report visible to the administrator in our application. We do not transfer this data to third parties except the sub-processors listed below, do not use it for advertising, do not sell it, and do not allow humans to read it except with your affirmative agreement for support, for a security investigation, or where required by law.
Sub-processors
We use a small number of service providers to run the product. Each processes data under its own published data processing terms, which apply to us as their customer.
| Provider | Role | Location |
|---|---|---|
| Supabase | Database and authentication | European Union |
| Vercel | Application hosting | European Union (fra1) |
| Stripe | Payment processing | EU / US (SCCs) |
| Resend | Post-scan summary email | EU / US (SCCs) |
| Source of the Workspace data you ask us to read | EU / US |
Where it is stored, and how it is protected
Your report data is stored in the European Union and the application is hosted in the EU. The Google refresh token is encrypted at rest with AES-256-GCM; the encryption key is held in the application environment and never in the database. Every database read is scoped to your own organisation by row-level security, so one customer cannot reach another customer’s rows. Access to production systems is limited to the people who operate the service.
How long we keep it, and how you delete it
Retention period: for as long as your account is open. We do not run an automatic expiry: a scan snapshot stays until you delete your data or close your account, so that you can re-open an old report and compare it against a newer one. Deletion is all-or-nothing. Delete my data on your dashboard removes every scan at once, and there is no way to delete one scan and keep another. If you want a shorter retention period than that, run Delete my data whenever you have finished with a report, or email hello@statmd.uk and we will do it for you.
Scan snapshots persist so you can re-open your report. There is a Delete my data button on your dashboard, and it performs a hard delete, not a soft one: it removes the Google connection including the encrypted refresh token, and every scan, together with the per-account rows, third-party application rows and findings attached to those scans. After that we no longer hold any data read from your Workspace.
Your own login record survives so you can sign back in. Payment and checkout records also survive so invoices remain valid and a payment already in flight cannot be charged twice or lost when Stripe later confirms it. Their reference to the deleted scan is removed, and none contains Workspace snapshot data. We keep payment records as required for tax and accounting purposes. To close your account entirely, email hello@statmd.uk.
Cookies
We set strictly necessary cookies for two purposes. Supabase, our authentication provider, issues session cookies that hold your login session so moving between pages does not sign you out; they are refreshed on each request. When you start connecting Google Workspace, we also set gw_oauth_state, an HttpOnly CSRF-protection cookie. It holds a random nonce and a signature that ties the attempt to the account and organisation that started it, so a connection cannot be completed by a different signed-in account; it carries no readable identifiers. It is scoped to the connection callback and expires after 10 minutes. We do not ask for consent to set these cookies because the requested login and connection flows cannot work safely without them.
We do not use advertising cookies, cross-site trackers, or third-party analytics, and we do not sell or share any data with advertisers. Clearing your browser cookies signs you out. If you clear them while a Google Workspace connection is in progress, that connection attempt is also aborted because its CSRF nonce is lost; you can start it again after signing back in.
Your rights
Under the GDPR you have the right to access, rectify, erase, restrict and port your personal data, and to object to its processing. Where we act as processor, direct those requests to the organisation whose Workspace was scanned — your employer or your IT provider — and we will assist them in answering you. Where we act as controller, write to hello@statmd.uk. You also have the right to lodge a complaint with your data protection authority; in the Netherlands that is the Autoriteit Persoonsgegevens.
Changes to this policy
If we materially change what we collect or how we use it, we will update this page and the date at the top of it before the change takes effect. The current version is always at https://grantroster.com/privacy.