The operating principle
Assess configuration, not imaginary compliance
An administrative review is not a penetration test, a managed SOC, an ISO certification or a legal compliance opinion. Make each result traceable to the actual tenant setting, observed business impact and responsible decision-maker.
Start with the controls that change real exposure
Review privileged accounts, authentication, conditional access or Security Defaults, emergency access, external collaboration, stale app permissions, mail authentication and available audit logs. Include whether the tenant has licences for recommended controls.
A control should be marked as enabled, absent, not licensed, deliberately excepted or not yet verified. Those statuses lead to different commercial decisions.
| Control area | Example evidence | Useful conclusion |
|---|---|---|
| Privileged roles | Role assignments and account inventory | Remove excessive standing access |
| Authentication | Policies, MFA coverage, report-only tests | Stage safer access enforcement |
| External sharing | Guest list, link rules and site ownership | Remove stale or unauthorised access |
| App consent | Application permissions and owners | Review high-impact third-party access |
| Email domains | SPF/DKIM/DMARC configuration and senders | Prioritise deliverability and abuse gaps |
| Recovery | Documented restore objectives and test record | Identify missing recovery proof |
Don't prescribe features the customer cannot use
Microsoft Entra Conditional Access generally requires appropriate P1 or equivalent entitlements, while risk-based access decisions may need P2 capabilities. A recommendation is incomplete if it ignores whether the customer has the feature or can afford the change.
The report should distinguish a configuration adjustment from a licence purchase, a process change or a specialist investigation. This keeps the proposal accurate and avoids hidden recurring costs.
Separate review from remediation
A useful findings register includes observed configuration, business consequence, likelihood/impact judgement, required approval, proposed action, licence dependency and expected user disruption. Make urgent access risks clear, but do not label every deviation a critical incident.
Changes to authentication policies should have test groups, recovery arrangements and a fallback path. The assessor should not silently roll out a disruptive policy simply because a security score would improve.
Documented administration controls
- Written review scope and read-only or least-privilege access plan
- Recorded observations, licence prerequisites and source date
- Prioritised findings with business-owner decisions
- Remediation scope and approval separated from assessment
- Retest plan for changes with lockout or mail-flow risk
Find the difference between a setting and an effective control
A security assessment should start by checking licence entitlements and policy scope before suggesting that a feature is active. A report that says multifactor authentication is enabled is incomplete if exclusions, break-glass arrangements, legacy sign-in paths or service identities have not been examined. Likewise, a retention policy's existence does not prove it applies to the required locations or that the organisation has agreed the period.
Prioritise concrete exposure: privileged users without a clear business need, stale external guests, excessive SharePoint sharing, insecure application consent and unusual authentication exceptions. Describe each finding with the observed setting, affected identities or workload, plausible business consequence, proposed remediation, change approver and verification step.
| Assessment area | Evidence | Remediation owner |
|---|---|---|
| Identity authentication | Policy targets, exceptions and sign-in results | Identity administrator and business owner |
| External file access | Tenant/site sharing settings and guest inventory | SharePoint and data owners |
| Applications | API consent grants and credential expiry | Application owner |
| Mail security | Relevant Exchange controls and mail-flow configuration | Messaging/security owner |
What a credible security assessment should hand back
Provide a prioritised findings register, not a vendor-grade score with no explanation. Rank issues by likelihood, blast radius, reversibility and confirmed evidence; distinguish urgent operational exposures from longer-term housekeeping. Note which recommendations require additional licences or specialist skills and which can be handled by a regular Microsoft 365 administrator.
The assessment is a starting point for remediation, not a certification of ISO, SOC or regulatory compliance. Preserve baseline evidence and, after approved changes, record the actual before/after configuration and affected-user tests. Legal interpretation and incident forensics sit outside a standard configuration review unless explicitly commissioned.
Documented administration controls
- Tie each finding to observable tenant configuration
- Check required licences before proposing controls
- Review exceptions and actual policy scope
- Name business approvers and specialist dependencies
- Include a practical retest criterion for every remediation
The best security review helps an owner decide what to change first, why it matters and who will verify the result.
Primary technical references
Check current feature and licence requirements before changing a tenant. A service description is not evidence that a customer has purchased or activated an option.
Commercial next step
Request a bounded Microsoft 365 security assessment
Describe tenant size, products and any recent incidents or access concerns. We can scope what can be examined without promising a certification or ongoing threat monitoring.
Request an administration assessment