Assessments have a bad reputation, and a lot of it is deserved. Too many are a tool run against a tenant, exported to a document, and handed over with a few hundred findings sorted by the severity the tool assigned. Nobody reads past page ten, and nothing changes.
So it is worth being specific about what a useful one looks like, what it covers, and what you should expect to be holding at the end.
What gets looked at
A Microsoft security assessment should cover the layers in the order they depend on each other, not in the order the portal presents them.
Identity comes first. How Conditional Access is actually constructed, what the exclusions are and why, how much standing privilege exists, whether privileged access runs through elevation, and whether legacy authentication is genuinely closed.
Devices next. What is enrolled, what compliance means in practice, and whether the access policies are able to use that signal at all.
Data after that. Where the sensitive data is, what classification exists, whether labels match anything the business recognises, and what data loss prevention is set to do rather than set to observe.
Workloads and the platform. Azure subscription structure, landing zone and governance, network exposure, key and secret handling, and what has been deployed outside any of it.
Detection and response. What is being collected, what is being retained, what would actually fire, and who would see it.
Governance last. Whether anything above is enforced, or documented and drifting.
How it should be done
By reading configuration, not by asking people what they think is configured. The two differ more than most teams expect, and the gap between them is often the finding that matters most.
The other thing that separates a useful assessment from a report is context. A misconfiguration in a system that holds nothing is not the same as the same misconfiguration in the tenant holding regulated data, even though a scanner will score them identically. Ranking by the tool's severity rather than by your exposure is how organizations end up fixing the wrong twenty things first.
What you should get at the end
Three things, and I would push back on any engagement that delivers fewer.
- A clear statement of the current state, written so that somebody who was not in the room can understand it
- Findings ranked by what they mean for this organization, with the reasoning visible, not just a severity label
- A sequenced roadmap where each step is something a named team can pick up and do
The roadmap is the part that earns the fee. A list of problems is not a plan. The sequence matters because the fixes depend on each other, and doing them in the wrong order means doing several of them twice.
I would add a fourth thing that is easy to skip: an explicit list of what was accepted. Every environment carries risk on purpose. Writing down which risks were accepted, and why, turns an implicit mess into a decision somebody owns.
What makes one useless
A few reliable signs. The output is a tool export with a cover page. Everything is high severity, which means nothing is. There is no sequence, only a list. The recommendations could have been written without looking at your tenant, because they were.
And the most common one: the report recommends buying the next licence tier as the first action. Sometimes that is the right answer, but it should arrive after the analysis rather than in place of it.
The test afterwards
The assessment worked if, three months later, the team is working through the roadmap without needing the person who wrote it. If the document is sitting unopened because nobody could turn it into work, then it measured the environment accurately and changed nothing, which is the expensive kind of correct.