Production Access Review

Definition

A production access review checks whether people, service identities and emergency accounts retain only the access justified by their current responsibilities. It reconciles actual permissions with approved needs and verifies the removal of unnecessary access. The output is a set of accountable decisions and completed changes, not a spreadsheet of names marked reviewed.

Production access includes more than a console login. Database roles, deployment permissions, support tools, cloud policies, secrets stores and impersonation features can all provide ways to view or change live systems. Review effective access across those paths, including inherited group membership and long-lived credentials.

Start with Actual Permissions

Obtain inventories from the systems that enforce access. Compare the identity provider, cloud accounts, databases and application administration rather than assuming they agree. Include inactive-looking identities with valid credentials, shared accounts and machine identities. An employee directory tells you who works here; it does not show every credential that still works.

Classify access by consequence. Read-only access to sensitive data may carry substantial risk even without write permissions. Deployment access may indirectly grant data access by changing application code. Explain these paths to reviewers in terms of what the identity can do, not merely a role name.

Run a Review with Clear Decisions

1. Identify the resource owner. Assign someone who understands the system and can approve the business need, rather than sending every decision to a central administrator.
2. State the justification. Record the task, required scope, expected duration and approval for each privileged entitlement.
3. Choose a disposition. Retain, reduce, time-limit or remove access. Unanswered items need escalation and a defined policy, not automatic approval.
4. Implement changes. Remove permissions through the authoritative system and address direct grants that bypass group control.
5. Verify effective removal. Check remaining roles, credentials and sessions according to the platform's behaviour.
6. Keep evidence. Link the reviewed entitlement, decision-maker, change record and verification result.

Illustrative Support-Handover Scenario

A software team finishes a customer migration and moves engineers back to product work. The identity provider shows the temporary production group as empty. During review, the database owner discovers a direct role grant made during the migration and a service credential stored in a support automation tool. The group cleanup did not touch either path.

The team confirms whether the automation still has an approved purpose, removes the engineer's direct grant and replaces or retires the service credential through the agreed procedure. It checks active sessions and platform-specific revocation behaviour rather than assuming that a permission change instantly invalidates every existing connection.

The lesson is a boundary problem: the project closed, but its access changes had no expiry linked to closure. The team adds ownership and review dates to temporary grants and includes access reconciliation in the release and transition checklist.

Machine Identities Need Owners Too

Service accounts are often omitted because they do not appear in employee lists. Record their purpose, owner, resources, authentication mechanism and credential lifecycle. Check that a retired integration cannot still reach production and that an automation identity is not carrying permissions copied from a human administrator.

Coordinate access reduction with operational testing. Removing a machine permission without understanding its dependency can interrupt service; fear of interruption can also become an excuse for permanent broad access. Use an approved change, a rollback plan and a narrow validation of the required function. Connect credential changes to the secrets rotation process.

Emergency and Temporary Access

Emergency access should have explicit activation, monitoring, expiry and post-use review. A permanently shared administrator password is not a controlled break-glass process. Record who used the access, why, which actions occurred and whether cleanup completed. Where possible, use individually attributable, time-bound elevation.

Review intervals should follow risk and compliance obligations. Role changes, departures, incidents and project closure are additional triggers. A quarterly review cannot excuse leaving known unnecessary access in place until the calendar catches up.

Practical Lessons Learned

Reviewers approve vague lists because they cannot judge them. Provide resource context, last relevant activity where appropriate, the requested business need and the consequence of the role. Last use is a useful signal, not a sole decision rule: emergency access may be intentionally unused, while an unauthorised credential may be frequently used.

Measure completion by resolved entitlements and verified changes. Sending every owner a reminder does not reduce risk. Track overdue decisions, expired exceptions and removal failures separately so the team can see where the control is actually stuck.

Expert Tips

• Reconcile direct grants as well as group-derived permissions.
• Give temporary access an owner and expiry when it is created, not during the next audit.
• Review deployment and impersonation capabilities alongside database privileges.

Common Mistakes

• Reviewing only human accounts or only the identity provider.
• Accepting “still needed” without a task, scope or accountable owner.
• Assuming removal automatically invalidates all sessions and credentials.
• Counting sent review forms instead of completed permission changes.

Key Takeaways

• Review effective access across every relevant enforcement point.
• Make approval specific and removal verifiable.
• Temporary and machine access need the same ownership discipline as human access.