Table of contents
If an IT provider holds only read rights in a Google Workspace tenant, a practical question follows: how will they check every month that the configuration still matches the agreed standard? The answer is a combination of three mechanisms, and it has to be said plainly that one of them does not yet cover everything.
1. Read privileges in a custom administrator role
Google’s administrator privilege model separates read from manage in many areas. A custom role without write rights can include:
- Reports – admin, login, OAuth token, Drive and Gmail log events;
- Alert centre view;
- Security centre dashboard and investigation tool;
- Read access to users, groups and organisational units (Admin API privileges);
- View DLP rule – view, not modify;
- Devices read, where Endpoint Verification is used.
That is enough for the weekly log review, alert handling and the quarterly recertification of users and groups.
2. Cloud Identity Policy API
Google’s Policy API is a read-only interface that returns the effective settings per organisational unit and group. According to Google’s supported-settings list (read 29.09.2026) it covers mainly application settings:
- Gmail – spam and phishing protection, attachments, confidential mode, IMAP/POP; routing and compliance rules partially;
- Drive and Docs – sharing settings, link defaults, shared drive creation;
- Calendar, Chat, Meet, Groups for Business, Marketplace, directory sharing;
- API controls – app access control settings.
This allows the monthly configuration drift check to be automated: export, compare with the previous one, differences into a ticket. The export can be kept as evidence.
3. What cannot be seen read-only
Several security-relevant areas are currently offered by Google neither in the Policy API nor as a read privilege – they have only a manage-level privilege or require super administrator rights:
- two-step verification enforcement, password policy, recovery options;
- session length and admin console re-authentication;
- single sign-on (SSO) and SAML applications;
- context-aware access levels;
- Vault retention rules;
- alert and activity rule definitions;
- the list of administrator role assignments;
- additional Google services on/off per unit.
For these there are two honest solutions: your administrator exports or screen-shares the relevant pages at the monthly check and the provider records it; or the provider watches for changes indirectly – through the admin audit log, where setting changes are visible even with read rights.
What this means in practice
Read-only monitoring is real, but it is not “everything automatic”. A properly built model looks like this: roughly two thirds of the control families are read automatically or through read privileges; the rest need 20-30 minutes of your administrator’s time once a month. In return you get what you never get with a super-admin provider: certainty that the external party cannot change anything in your environment, and an audit log they cannot edit.
Google changes privilege granularity over time, so verify the exact control list in a pilot and review it annually.
This model underpins our Google Workspace monitoring service for regulated companies.
