Map how people reach the application
List the users, devices, and services that need access. Identify shared accounts and any paths that bypass the normal sign-in process.
Define the access decision
For each group, record which role grants access and what evidence your team needs to trust a sign-in. Review exceptions separately and give each one an owner and expiry date.
Test before broadening the rollout
Try approved and denied access paths with a small group. Check that denials are logged and that support can explain what happened without granting broad access.
Worked example — Access to an internal reporting app
Imagine employees, contractors, and a scheduled reporting job all using the same application. The team gives employees access to reports for their own unit, sets expiry dates for contractor access, and gives the job a separate identity. In the pilot, it tests that an employee can open an authorized report and that a contractor whose access has expired is denied.
Pilot checklist
- Choose one application and list its users, devices, and service identities.
- Document which roles can access which resources and under what conditions.
- Test allowed and denied paths, including expired access and unexpected devices.
- Verify that support can explain a denial and that temporary exceptions expire.