Skip to content

Compliance officers

Review works best when the person reviewing isn't the person being reviewed. The Compliance Officer role gives someone what compliance work needs without making them an administrator: they read the audit log, administrators' actions included, see the data inventory, and handle legal holds. They can't change a setting, an account or a role.

There are two roles of that name:

  • one at server level, for the whole server;
  • one in each tenant, for that tenant's own accounts.

Both are made for you: on a new server when it's set up, on an upgraded one the first time the new version starts, and in each new tenant when it's created. They're listed under Management › Directory › Roles.

What each can do

Server-level A tenant's
Overview and data inventory Everything Its tenant's part
Read and export the audit log Every record Its tenant's records
Check the audit log for tampering Yes No
See locked accounts and their delegates Yes Its tenant's
See, place, widen, release and export legal holds Yes No
See DLP rules, and release or reject held mail Yes No
See accounts, groups, mailing lists, domains, tenants and roles Yes Its tenant's
Change any of those, or any setting No No
Change how long audit records are kept No No
Sign in as someone else, or open their mail No No

A tenant's officer has no legal holds, since holds are server-level only: a hold may concern the tenant's own administrator.

Everything an officer does is in the audit log under their own name, like anyone's. Placing, widening and releasing a hold asks for a reason.

Making someone an officer

Open the person under Management › Directory › Accounts, and under Groups & Roles › Roles choose Compliance Officer. For someone in a tenant, choose that tenant's role; a tenant's accounts can only be given its own roles.

Each role includes what any user can do (sign in, read and send their own mail), so it replaces User on that account rather than adding to it. The change is recorded in the audit log, like any change to an account.

Administrators already have everything the role gives: the Administrator role for the whole server and the Tenant Administrator role for its tenant.

Changing or removing the roles

They're ordinary roles. An administrator can edit either, and a changed role stays as changed.

Deleting one sticks: the server makes each role once and doesn't make it again. A tenant's role that nobody holds goes with its tenant when the tenant is deleted; while someone holds it, the tenant can't be deleted, as with anything else still in use.

Keeping administrators reviewable

An officer reads the record of what administrators do; what keeps that record honest is the audit log itself:

  • every administrator's change is recorded before it's allowed, under their name;
  • records can't be edited or deleted, by anyone, administrators included; they're only removed by age;
  • the tamper check shows whether any were;
  • shortening how long records are kept is recorded too, and shows on the Overview.

A server administrator can still shorten audit retention, down to 90 days, without anyone else agreeing: a server may have only one administrator. The change is recorded and surfaced rather than prevented. And anyone with shell access to the server can change its store directly, which is beyond what the server itself can record.