Case study · dogfood
We ran our own Microsoft 365 tenant through the assessment we sell.
Before recommending a tenant review to anyone else, we ran one on ourselves. It found real problems. This is the baseline, the method, and the part we are not publishing yet.
next Secure Score snapshot due
scopeone tenant, ours
after-numberdue[PLACEHOLDER: post-remediation score and date]
secure score, baseline
52.1 / 64
Internal Secure Score review
Our own tenant scored 52.1 out of 64 before we changed anything, and we are publishing that number rather than the one we would rather show you.
Why our own tenant
We sell a tenant review as the first step of a Microsoft 365 or Azure migration. A firm that sells that and has never run it on itself is asking you to take the method on trust, which is the thing this site is built not to do. So the first tenant we assessed was our own — a multi-domain, multi-brand Microsoft 365 tenant that has been in production since 2024, with real users, real mail flow and real external sharing.
It found real problems. That is what an honest assessment does, and it is why the number above is 52.1, not 61. We had 90 days of flat history before we captured it, so the baseline is a settled position rather than a snapshot taken on a good day.
Microsoft Secure Score is a tenant-wide measure of configuration against Microsoft's own recommended controls. It is a proxy, not a security opinion — a high score is not an attestation and we do not present it as one.
Internal Secure Score review, 90 days of history
What the assessment covers
Five areas, in the order we read them. The list is the same for a client tenant, and each one is a place where the licence you hold decides what can actually be enforced — which is why the licensing pass comes second rather than last.
- Identity and access. Administrator accounts, multi-factor coverage, conditional access, and whether standing privilege exists anywhere it should not.
- Licensing reality. What your current plan can and cannot enforce. Several controls people assume are on are not available on every Microsoft 365 plan.
- External sharing. What leaves the tenant, to whom, and whether anyone would notice.
- Devices. Enrolment, compliance policy, and what happens to company data on a device nobody manages.
- Email authentication. SPF, DKIM and DMARC — the three records that decide whether someone can send mail as you.
The output is a gap list with a severity and an owner against each item, the dated baseline score, and a remediation order. It is a standalone deliverable: if you take it to another firm to execute, it still works.
The four steps, run on ourselves
The same procedure we run on a client tenant, in the same order, with the same read-only first step.
Assess, read-only. Identity and conditional access, licensing and what each plan can actually enforce, external sharing, device compliance, and email authentication — SPF, DKIM and DMARC, which are missing or incomplete in most tenants we look at, including ours. Nothing is changed at this stage.
Write the gaps down, with a baseline. Every finding gets a severity, an owner and the control it maps to, and the tenant-wide score is captured on the same day so there is a dated line to measure against later. A gap list with no baseline is an opinion.
Fix in priority order, and record what we decline. P1 items first. Anything we decide not to fix — because the licence does not support it, because the control would break a workflow, or because the risk is genuinely accepted — is written down as a declined item with the reason, not quietly dropped off the list.
Re-score, and publish both numbers. The same export, the same tenant, the same method, after remediation. Two dated numbers and the list of what changed between them — which is the only version of this that is worth anything to a reader.
What we chose not to fix, and why
Two decisions, both about publication rather than about controls — and they are the honest answer to "why is there no after-number on this page yet".
We are not publishing the open finding list while it is open
A public, itemised list of unremediated configuration gaps in a live tenant is an attack map, not a trust signal. So the findings are described by area above and by severity in the deliverable, and the specific open items stay unpublished until they are closed. We would rather this page be visibly incomplete than be a useful document for the wrong reader.
/trust/, "Our own security posture"
We are not publishing a projected after-number
We know roughly which controls the P1 items map to, so we could estimate where the score lands. We are not going to, because a firm whose pitch is measurement does not publish a number it has not measured — not as a projection, not as a range, and not in small type. The second number appears on this page the day the export produces it, with its own date beside it.
DESIGN-BRIEF §9.6, §11.6
Start with the assessment, not the migration.
Book an assessment call30 minuteswith the engineer who would scope the work[PLACEHOLDER: written-summary turnaround, not yet committed]