Does the intended rule apply to the population it is supposed to protect?
Examine which people, applications and sign-in situations your policies actually cover.
Begin with the business decision and the affected population. A targeted workload review may be sufficient; an interconnected tenant assessment may be more useful where the same identity, device or data dependency affects several services.
Evidence we agree to examine
- Policy state: enabled, report-only or disabled, with creation and change history where available
- Included users, groups, target resources and explicit exclusions
- Authentication strengths, device requirements, session controls and dependencies
- Representative sign-ins, What If evaluation and documented emergency-access arrangements
Why context changes the conclusion
A policy named “Require MFA for everyone” may be in report-only mode or exclude a broad group. The name and existence of the policy are not evidence that a specific sign-in was protected.
Treat this as an assessment question, not a finding about your organisation. During an engagement, a conclusion must identify the dated evidence, the sampled population and any exceptions that could not be corroborated.
The output your team can use
A coverage matrix of important user/resource combinations, exceptions and staged validation steps.
Each action should identify its accountable owner, licence or business dependency, proposed rollout safeguards and the record that will demonstrate successful closure. A policy screenshot alone is not enough when the finding concerns coverage or sustained operation.
Access and boundaries
Entra ID P1 is needed for Conditional Access; user/sign-in risk policies require P2. Confirm actual entitlements. No production policy is changed during the assessment.
We agree evidence access before work begins. Your team can lead supervised sessions and provide approved, minimised exports. The assessment does not require you to send passwords, grant access through this website or permit production changes. See access and data handling.
Include device code phishing exposure
Review where device code flow remains allowed, which dependencies justify an exception and whether sign-in evidence supports investigation. Our device code phishing guide explains the threat, Conditional Access considerations and a focused audit scope.
Prepare your audit request
Use the Microsoft 365 Audit Planner for a licence-aware starting scope, or the detailed scoping assistant. Review the brief and send it with your enquiry. You can attach your NDA or RFP in the contact form.
Sources & further reading
Reviewed 6 October 2026. Product names, licence entitlements and guidance can change. Confirm applicability to your tenant and agreed assessment date.
