Most security reviews are sold as a one-shot audit: pull some data, hand over a slide deck, invoice. That model breaks the moment real tenant data shows up, because the first pass is never complete. Telemetry is missing, a device population turns out to matter, or a client discussion surfaces a detail that changes the read on three roles at once. Treating analysis as a single pass just means shipping recommendations built on a partial picture.
We run it as two phases instead: an analysis phase that's built to loop back on itself when the data says to, followed by a remediation-and-implementation phase that only starts once the client has signed off on what's actually being built.
Phase 1: Security analysis & planning
Strategy first, then data. We fix scope, data availability, telemetry, device landscape, integrations, and rollout approach before touching a single role. Then we check the tenant against the patterns that actually drive overlicensing:
- Users on full licenses who only need a device license
- Inactive users (no activity, no thin-client access) still holding a paid license
- Contradictory access: Deny and Grant on the same entry point for the same user
- Roles carrying far more access than the job requires
- Duties and privileges inside a role that have never been used
- Users whose license tier is driven by access they don't actually use
Every finding becomes a report with slicing-and-dicing options and a recommendation. Cutting access is planned carefully, role by role, trimming what's excessive without breaking a workflow. If data is incomplete, or a client conversation surfaces something that changes the read, we loop back and re-run the analysis rather than patch existing findings.
Phase 2: Remediation & implementation
The optimized security model is built from usage telemetry, not job titles, then imported into the client's test environment for UAT before anything touches production.
Go-live gets its own strategy (sequencing, fallback plan, support model), agreed before a single role changes in production, followed by a defined post-go-live support window.
The two loop-backs in Phase 1 keep a wrong assumption out of the production role model. Everything in Phase 2 builds on a picture we've already stress-tested twice.