A dormant domain administrator account, an outsourced engineer still able to reach production, and a service account with a password that has not changed for years can all sit unnoticed in the same environment. Each may have been legitimate once. Each can also become the fastest route to operational disruption, data loss or a failed audit.

This privileged access review guide is designed for organisations that need more than an annual spreadsheet exercise. The aim is to establish who has powerful access, why they have it, what business service it supports and whether the access remains justified. Done well, a review reduces cyber risk without creating unnecessary friction for the people keeping critical services running.

Why privileged access reviews need business context

Privileged access is not limited to members of a Domain Admins group. It includes accounts able to change configurations, create users, access sensitive data, disable security controls, deploy code, manage cloud subscriptions or administer operational technology. It can be assigned directly, inherited through groups, delegated through roles or embedded in applications and automation.

The difficulty is that most organisations hold this information in several places. Active Directory, Microsoft 365, Azure, AWS, Kubernetes, network devices, endpoint management tools and line-of-business platforms each describe access differently. A list from one identity system may be accurate but incomplete. It may also say nothing about the service affected if that access is misused.

That is why the review must start with context. A privileged account supporting payroll, patient care, public services or production systems deserves faster scrutiny than one attached to a retired test environment. The technical permission matters, but its potential business impact determines the order of work.

Define what counts as privileged access

Before asking managers to certify access, agree a defensible definition. It should cover both human and non-human identities, permanent and temporary permissions, and access held inside cloud and SaaS platforms as well as on-premises infrastructure.

A practical scope normally includes the following distinct access types:

  • Enterprise and local administrator accounts, including break-glass accounts.
  • Privileged cloud roles, subscription owners and delegated administration rights.
  • Security, identity and configuration management roles that can alter controls or permissions.
  • Service accounts, API keys, certificates and automation identities with elevated rights.
  • Third-party, supplier and managed-service access to production or sensitive environments.

Do not assume an account is low risk because it is labelled as a service account. Non-human identities often have broad permissions, weak ownership and long lifespans. They are also less likely to be challenged in a conventional manager-led review.

Build an evidence base before requesting approvals

A weak review sends an application owner a long list of accounts and asks, “Do these still need access?” It shifts the burden to a person who may not understand the technical role, and it produces approvals that are difficult to defend later.

A stronger process assembles evidence first. For each privileged identity, capture the identity type, named owner, account status, authentication method, last use, entitlement, system or platform, access route and linked business service. Where possible, record whether multi-factor authentication is enforced, whether the account is shared and whether the permission is standing or time-bound.

Ownership is the first control test. Every privileged account should have a named person accountable for its use, even where a technical team maintains it. Where there is no owner, no service relationship or no recent activity, the organisation has a clear candidate for investigation, suspension or removal.

Usage data also changes the conversation. An account that has not been used for 180 days may be unnecessary, but it could support a quarterly recovery activity. Rather than remove it automatically, validate the operational need with the service owner and document the outcome. Risk reduction is strongest when it preserves resilience as well as restricting access.

Run the privileged access review in the right order

Not every entitlement needs the same treatment on day one. Start with identities that combine high privilege with high business consequence, particularly shared administrator accounts, external access, dormant accounts and permissions that bypass normal approval routes.

1. Identify the account and its effective rights

Review direct permissions and inherited group membership. Check for nested groups, delegated roles and multiple identities held by the same individual. In cloud environments, assess both standing assignments and eligible assignments that can be activated when required.

Effective access is what matters. A user may not appear in an administrator group but may receive equivalent control through a role, a group chain or a service-specific permission.

2. Confirm purpose, owner and service dependency

Ask a precise question: what approved task requires this level of access, and which business service would be affected if it were removed? A clear answer establishes whether access is justified. A vague answer such as “for support” is not sufficient for a high-impact privilege.

This step exposes a common problem: technical accounts are retained because nobody wants to be responsible for removing them. Linking the account to a service owner brings an operational decision into the open.

3. Test whether the access is proportionate

The correct outcome is not always removal. It may be a lower-privilege role, just-in-time elevation, restricted network access, stronger authentication, a separate administrative account or an expiry date. The right control depends on the operating model and the consequences of delay during an incident.

For example, an on-call infrastructure engineer may need rapid elevation outside business hours. A time-limited privileged role with recorded activation can be safer and more practical than a permanently assigned administrator role. By contrast, a legacy application may require a service account with persistent access until the application is redesigned. In that case, compensate with a named owner, credential rotation, monitoring and a dated remediation plan.

4. Record the decision and evidence it

Every reviewed entitlement should result in a documented decision: retain, reduce, remove, replace or investigate. Record who approved it, the date, the evidence considered and the next review date. This creates an audit trail and prevents the same uncertainty returning at the next review cycle.

5. Verify that remediation happened

Approval is not remediation. Teams need to confirm that removed groups are no longer assigned, disabled accounts cannot authenticate, credentials were rotated and temporary permissions have expired. Sample testing is useful, but high-risk changes should be validated directly.

Make the review continuous, not ceremonial

Annual recertification can satisfy a policy requirement, but it leaves too much time for risky change to accumulate. Privilege changes frequently through joiners, leavers, role changes, supplier activity, cloud deployment and incident response. A review process that only sees a yearly snapshot cannot provide dependable assurance.

A better model combines continuous visibility with scheduled accountability. Detect meaningful changes as they occur, then require formal review at a frequency based on risk. Highly privileged and externally accessible accounts may warrant monthly review. Lower-impact administrative roles may be reviewed quarterly or following material changes to the relevant service.

This approach also improves audit readiness. Instead of rushing to reconstruct evidence before an assessment, security and compliance teams can show current ownership, control status, exceptions and remediation progress. Leadership receives answers they can trust because the evidence is grounded in the live environment, not an outdated export.

Measure outcomes that matter to leadership

The number of accounts reviewed is a process metric, not a risk outcome. Report measures that show whether exposure is reducing and whether critical services remain supportable.

Useful measures include the percentage of privileged accounts with a named owner, the number of dormant or orphaned accounts removed, the proportion using strong authentication, unresolved high-risk exceptions, and the time taken to remediate inappropriate access. Present these alongside the business services affected. This lets leaders see where risk is concentrated and where investment or accountability is required.

For MSPs and MSSPs, the same model can be applied across customers without forcing each customer into a separate manual exercise. A shared assurance process should still retain customer-specific service context, approval authority and evidence. Scale must not turn accountability into a generic tick-box.

Where integrated visibility changes the result

Privileged access reviews often fail because identity data is separated from asset, configuration, vulnerability and service information. Teams can identify an elevated account but cannot quickly establish what it can reach, whether the target system is exposed or whether the system supports a critical function.

An integrated view changes prioritisation. Rebasoft can help teams correlate identity visibility with connected assets, security controls and service context, so reviewers can focus first on access that creates material exposure. That reduces manual evidence gathering and gives operational teams a clearer route from finding an issue to proving it has been addressed.

The objective is not to produce a longer access register. It is to make fewer unjustified privileged pathways available to an attacker or an accidental user, while ensuring authorised teams can restore and operate essential services when it counts. Start with the privileges that could cause the greatest business harm, assign clear ownership, and make every decision evidence-led.