Identity and access reviews

Overview

Access Review brings application-account reviews and access-change evidence into elba. Use it to define a review scope, collect accounts, record access decisions, follow required changes, investigate unmatched accounts, and export results.

The workspace is organized into four areas:

• Reviews for periodic account reviews and decisions
• Identity gaps for source accounts that are not matched to an elba employee
• Activity for detected access and permission changes
• Sources for the applications that provide account data

Create an access review

1. Create and configure the review

Open Access Review, then select Create review. Give the review a clear name and configure its deadline and reminders.

2. Define the application scope

Add applications from your Third-Party Apps inventory or create an entry for another application that should be reviewed. Inventory suggestions show Verified accounts and Observed users separately:

• Verified accounts come from a connected source and can be copied into the review.
• Observed users come from inferred Browser Security evidence. They help you identify applications that may need a review, but they are never copied into access-review account rows.

A browser-only application is marked Verification required. Connect the application or import an authoritative account list before recording maintain, revoke, or role-change decisions. A browser observation never creates an account identifier, a review decision, or a remediation action.

Account collection depends on the source:

• A connected application can import its available accounts into elba.
• For an application without a connection, import accounts from a CSV file or a screenshot, then review the detected data before adding it to the scope.

Connected data provides the most direct source of account information. For manual imports, confirm the data with the application's owner before starting the review.

Browser evidence does not add roles, groups, policies, or entitlements to a review. If the connected source or import does not represent the granularity required for an application, assess those details in the source application and retain that evidence with your established process.

3. Review accounts

Delegate account approvals

An organization owner or administrator can delegate account approvals for an access review while Security keeps control of the campaign and its final decisions. In a scheduled review, open Delegated approval → Set up and choose the application owner, the employee's line manager, or both. When both are required, the account waits for both approvals; if one person holds both roles, one answer covers both. If the directory has no manager for an employee, Security can assign a manager for this review without changing the directory record.

Choose what happens if a required approver has not answered by the review deadline:

• Escalate to Security is the default. The campaign owner receives the unresolved case to decide.
• Keep access, not reviewed leaves the account without a completed review decision.
• Revoke records a revoke decision at the deadline. This requires an explicit choice and confirmation before launch. It can also apply when no approver could be reached, so check missing owners and managers before selecting it.

Saving these settings on a scheduled review does not send requests. Requests are sent when Security validates the review scope. Approvers may receive a request through a reachable Slack, Teams, or Google Chat connection, or by email. Security can inspect the requested roles and answers in the review, override with its own final decision, and follow up when an approver does not receive or answer a request. A revoke decision is distinct from removing access in the source application; use Required changes to apply and track that action. Review the settings again before launch, particularly if the application owner or manager changed.

For each account, choose the appropriate decision:

• Maintain to keep the current access
• Revoke to request removal of access
• Change role to maintain access while requesting a different role

Use the available filters to work by application, owner, employee, group, or review decision.

4. Apply required changes

The Required changes view collects revocation and role-change decisions. A decision records what should change; it does not prove that the change has happened in the application.

For some connected applications and accounts, elba offers Revoke access to request removal through the integration. elba cannot currently verify the result of these requests. Check the account in the application before using Mark as done. Where the action is unavailable, make the change in the application first, then mark it as done in elba.

For a revoke decision on an account listed by its integration, the row shows elba cannot revoke this account before any request if the application or account does not allow automated revocation through elba. Its explanation identifies which limitation applies and directs you to make the change in the application, then use Mark as done. This message does not record a request or a completed change.

Azure DevOps uses this manual path: elba does not remove its organisation accounts. Check and remove access in Azure DevOps, then record your declaration in the review. For a selection containing both supported and unsupported accounts, Revoke access counts only those elba can request; the others retain their manual completion action.

A role-change decision records the requested role. Apply and check that change in the application, then mark it as done in the review.

Read the result for each account, including when you request several changes together:

• Revocation requested records a request made through elba. It is not confirmation that access was removed.
• Revocation not confirmed means the account is still present in the application's account list read by elba. Check it in the application.
• Revocation failed records a failure known to elba. Review the explanation and check the application before deciding what to do next. The absence of a recorded failure is not proof of success.
• Not revoked means the account was not included in the action. It does not mean that the requested change was completed.
• Done records your manual declaration that the change is complete. It is separate from a result verified by the application.
• Action recorded — result unverified identifies a historical action whose result was not verified. Its existing date is retained without turning it into proof that access was removed.

An account disappearing from the list read by elba, even in successive syncs, does not confirm removal. There is no fixed waiting period after which a request becomes verified. Integration capabilities vary by application and account; use the action and result shown for the specific item.

5. Complete and export

Review progress for both account decisions and required changes before completing the review. After completion, decisions and required changes can no longer be edited.

Open the completed review's Summary. Organization owners and administrators can use Download PDF summary for a readable overview and Download detailed CSV for the account-level evidence.

The summary shows the organization and review reference, creation and completion dates, application and account scope, review decisions, who recorded them, application owners, identity matches and evidence of required changes. An account is one access to one application; a person with accounts in three applications is counted three times. An unmatched account is not automatically an external person. The separate external marker reflects the state when the summary is generated.

The creation and completion dates describe the review itself, not an access-observation or audit period. elba does not record who completed the review. The summary's generation time states when its information was read; later exports may differ as evidence or identity information changes.

The PDF is a fixed-layout record for reading and filing. It is not signed, certified or a legal attestation. A revoke decision, a request, a manual completion declaration and a historical action record are distinct from a verified removal. Evidence categories can overlap, so do not add their counts to calculate a total.

The PDF and CSV filenames share the review reference. Keep both together when handing over the review. The detailed CSV is in English and keeps the account and review-decision fields, request, result, explanation and relevant dates for each account. Downloading either file does not edit the review or apply a required change.

Keep these dates distinct: a request date shows when the action was requested; account first missing from elba's list of the application on shows an observation by elba, not a confirmed removal date. A manually recorded or historical action date does not provide independent verification either. Retain supporting evidence from the application alongside the export when you need to demonstrate that access was removed.

You can also duplicate a review to prepare a later review with a similar scope.

Investigate identity gaps

Identity gaps are accounts found in connected sources that elba has not matched to an employee and that have not already been identified as external.

elba labels an account as a former employee only when a source sync or an employee deletion recorded one matching elba identity, that identity is still deleted, and no current identity conflicts with the match. An email domain alone does not prove that someone has left. Ambiguous or unverified matches stay unknown. Accounts with an external domain and no matching employee may appear as external users.

The table and CSV show when the source last reported the account. An old observation does not confirm that the account still exists or still has access. New source syncs retain accounts that match departed employees so you can investigate them. Previously hidden historical accounts are not automatically reclassified by this correction.

For each identity gap:

1. Confirm the person's identity and employment status using your authoritative systems.
2. Check whether the account is a legitimate external collaborator, service account, shared account, or emergency account.
3. Review the application's owner, role, permissions, and recent business need.
4. Add the account to an access review or handle it through your established access process.

You can export identity gaps to CSV for investigation or reconciliation.

Use elba during offboarding

Identity gaps and access reviews can support your offboarding process, but employment status and revocation decisions remain under your organization's control.

A safe workflow is:

1. Confirm the departure in your authoritative HR or identity system.
2. Review accounts associated with the employee across relevant applications.
3. Check for ownership transfers, shared resources, service dependencies, or retention requirements.
4. Record revoke or role-change decisions in an access review.
5. Use direct revocation only where elba offers it for that integration and account; make all other changes in the source application.
6. Mark manually completed changes as done and retain the completed review as evidence.

Do not treat an identity-gap label as authorization to revoke access. Validate each account before acting, especially privileged, shared, service, and emergency-access accounts.

Review access activity

The Activity view records supported changes detected in connected applications, including:

• Access granted
• Access revoked
• Role changed
• Permissions changed
• Authentication method changed

Filter the activity view to investigate changes, and export it to CSV when you need to reconcile it with another control or retain supporting evidence.

Recommended review checks

Before completing a review:

1. Confirm that all intended applications and verified or manually imported accounts are in scope.
2. Resolve ambiguous identities with the application or business owner.
3. Check privileged and service accounts separately.
4. Ensure every revoke and role-change decision has an owner.
5. Confirm manual changes in the source application before marking them done.
6. Export the final review and document any accepted exceptions.