Running a Microsoft 365 audit without PowerShell looks impossible when you open the framework. The CIS Microsoft 365 Foundations Benchmark v7.0.0 indeed contains 160 recommendations, and for nearly every one carrying an automated procedure, the Center for Internet Security offers the same thing: a PowerShell snippet, to be run under an account holding administrative rights on the tenant.
That is what circulates everywhere, and that is what public repositories reproduce. However, it becomes a problem the moment you step outside your own tenant.
The real cost of the script
Running an audit script inside a client’s tenant assumes three things no serious IT lead grants happily.
Privileged access handed to a third party. Microsoft 365 admin modules indeed connect with accounts that can read, and also write. The client therefore has to trust that the script only reads. Yet they cannot verify it other than by reading it line by line, which nobody does.
A workstation in the loop. The result then depends on installed module versions, on the operating system and on local execution policy. Thus two consultants get two slightly different outputs on the same tenant, and nobody can say which one is authoritative.
No guarantee of repeatability. Six months later the modules have moved on and some cmdlets have gone. Consequently, the before-and-after comparison turns into an exercise in interpretation rather than a measurement.
On an internal audit you live with it. By contrast, on a paid engagement, on a NIS2 supply chain security requirement, or on evidence you have to put in front of an ISO 27001 auditor, those three points become objections that goodwill does not clear.
How to run a Microsoft 365 audit without PowerShell
What those scripts read, Microsoft also exposes through application interfaces, read-only. Identity, messaging, threat protection, compliance, collaboration and document sharing are thus all addressable that way.
The work is not finding those interfaces. Rather, it is establishing, recommendation by recommendation, which one returns the exact setting the benchmark asks you to observe, and in what form. That mapping exercise is long, and it is what separates a tool ticking forty checks from a tool covering all 160.
Out of the 160 recommendations in v7.0.0, 140 therefore become automatic checks. The remaining 20 move to guided verification, captured alongside the operator’s reasoned answer, since they rest on organisational decisions rather than a setting readable in a console.
What read-only changes in practice
The client runs nothing. They grant a named, read-only application consent to an identified application. Moreover, they revoke it whenever they want, in one action. No installer, no agent, no resident connector.
The scope stays visible and verifiable. Granted permissions indeed appear in their own admin portal. They therefore know exactly what the auditor can read, and every access leaves a trace in their audit log, not in the provider’s.
No global administrator account changes hands. That is thus the difference in kind between an audit resting on trust placed in a consultant, and an audit resting on a technical boundary the client controls and can close at any moment.
The finding is time-stamped and repeatable. Two collections three months apart compare mechanically. As a result, the question of whether the corrective measure held gets a factual answer, with a timestamp, rather than an impression.
For an organisation under NIS2 or DORA, those properties separate a compliance statement from compliance evidence.
v7.0.0 lands in a web still talking about earlier versions
The v7.0.0 benchmark is recent. Most public resources, script repositories included, still cover earlier versions. You therefore find recommendation numbers that no longer match, sections that have moved, and audit procedures that have changed.
Auditing against a stale version then produces a report that looks complete and is not. That kind of gap only becomes visible the moment an external auditor opens the document, which is the worst possible moment.
Finally, the first question to ask a provider is not how many checks they run. It is which version of the benchmark they run them against, and what access they require to do it.
Tenovia covers all 160 recommendations of CIS Microsoft 365 v7.0.0, read-only, with no script executed on the audited tenant. The domain-by-domain detail sits on the CIS coverage for Microsoft 365 page.