A Google Workspace or Microsoft 365 tenant can run for years without anybody going through how it is configured. We do that, and write down what we find.
A tenant gets set up, and after that it mostly just runs. People join and leave. Perhaps a consultant held admin rights for a project. Perhaps an app was connected for a trial that ended two years ago. Meanwhile the platforms themselves keep changing what they offer and what they switch on by default for new tenants, which is not the same as changing yours.
None of that is anybody's fault. There is rarely an occasion that forces somebody to sit down and go through it.
Can you say how many people hold full administrator rights? Whether every account has multi-factor on it, or just most? Whether anything is forwarding mail out of the building?
If those answers are not close to hand, that is what this is for. The settings are not exotic. What is usually missing is the time to check them.
The same ground on either platform, using whatever each one calls it.
Multi-factor coverage across the accounts, which older sign-in methods are still accepted, and accounts belonging to people who have left.
How many accounts carry full administrator rights, and a straight conversation about what happens if the person who normally does this is unreachable.
Forwarding to outside addresses, and rules that move or hide messages. A forwarding rule is one way somebody keeps reading your mail after the password has been changed.
What your sharing settings permit, and what the platform's own reporting shows is currently shared beyond the company.
The connected applications your admin console can see, and the access each one was granted. That access can outlast whatever it was for.
Which audit and security logs are available to you under your current setup, and how far back they go.
Both platforms can hold on to deleted things, and depending on the workload, the plan and how it is configured, they can hold them for a long time and get you out of an ordinary accidental deletion. That is genuinely worth having. Part of the review is writing down what yours is actually set to and what recovery it would support, which is usually the first time anyone has asked.
What it is not is an independent copy. It lives inside the same vendor platform, so it does not cover every kind of failure. Whether that matters enough to keep a separate copy depends on what you would need to recover from, and it is worth deciding deliberately rather than finding out.
What your subscription includes today is not necessarily what it included when somebody chose it, and capability differs between tiers. So part of the review is checking whether anything useful is sitting there unused. Sometimes there is and switching it on avoids buying something else. Sometimes there is not, and the honest answer is that the thing you want costs more.
A written list of what we found within the scope we agree at the start, ordered by what we would deal with first, in language you can hand to somebody else. Where a finding is limited by what the tools expose or how far the logs go back, the list says so rather than implying we saw everything.
Each item says what is set now and what we would change. Some are a single click. Others change how people work, and those are yours to decide on rather than ours to impose.
You can act on the list yourself, or hand it to whoever runs your IT. It is written to be useful to somebody who is not us.
We do not change production settings as part of looking. If the review itself needs an access change to see something, we tell you what and why before it happens. Fixing anything is agreed separately, with whoever you nominate to approve it. A tenant is live and people are working in it, and switching a setting to prove a point is a good way to ruin somebody's morning.
One agreed pass through your tenant, a written list of what we found, and a straight conversation about which parts are worth your time.
Start a Conversation