Account Reviews

Introduction

Summary

Learn how to implement and operate Account Reviews in eramba so user accounts, access changes, and orphaned identities can be reviewed on a regular basis.

This course is a mix of theory, implementation, and operational guidance. It explains how feeds, pools, reviewers, findings, notifications, and the Account Review Portal work together so access reviews become repeatable and auditable.

This course helps eramba administrators understand how Account Reviews work and how to implement them in a practical, auditable way.

Account Reviews are built around a simple idea: eramba regularly receives account data from target systems, stores that data, identifies what changed, and asks designated reviewers to confirm whether those changes are acceptable. The output is not only a reviewer decision, but also evidence, findings, and history that can be shown to management and auditors.

The course is structured around four pillars:

1. The module logic: what Account Reviews are, what data they require, and how the workflow operates.
2. Review design: how to choose systems, frequency, review type, reviewers, and connectors.
3. Implementation steps: how to configure access, create feeds, create reviews, and test them.
4. Operational steps: how to run recurring reviews, handle findings, and keep evidence for auditors.

Typical Scenarios

This use case allows you to work with the following common situations:

• Differential reviews, where you review additions, removals, and entitlement changes are pointed out
• Snapshot reviews, where you review the complete account population in systems such as AWS on a regular basis.
• Exit reviews, where you compare active employees against system accounts to identify orphaned or unmatched accounts.
• Manager-driven reviews, where each department or system owner validates only the access they are responsible for.

Supported Versions

Account Reviews runs on both on-premise and cloud deployments and is available in Enterprise editions.

Workshops

Every couple of months, Eramba offers free training on this course. Keep an eye on our website for updates. If you are an enterprise customer, you can purchase 8-hour workshops delivered by a GRC professional (no “CSMs” at Eramba) and an Eramba expert to ensure you start on the right foot. Gambling on a poor implementation to save the minimal cost of these workshops is a bad financial decision. Contact support@eramba.org for details.

Theory

Account Reviews Overview

Eramba can pull accounts from various systems using built-in connectors or custom scripts, and users can define the frequency of these account pulls.

There are three types of account reviews: snapshot (reviewing all accounts), differential (reviewing only account changes), and exit (reviewing accounts not mapped to current employees).

The platform provides detailed information about the accounts, including changes to roles and groups. It also sends notifications when new accounts are found or changes occur.

Reviewers can mark accounts as "okay", "not okay", or "unsure", and findings can be associated with accounts that need correction.

Eramba tracks all the account review activities in audit trails, allowing users to analyze the history and identify any issues.

Solution Components

Account Reviews in eramba rely on a chain of components that move data from the target system to the reviewer.

1. A feed provides source data. This is usually a list of accounts, but it can also be a list of employees for exit-style comparisons.
2. A scheduled pull loads that feed into eramba.
3. Eramba stores the imported data and compares it against previous records.
4. A configured Account Review presents the relevant records to designated reviewers through the Account Review Portal.
5. Reviewers mark each entry as okay, not okay, or not sure, and can add comments or supporting files.
6. When an issue is identified, you can raise a finding so corrective action is tracked.

The implementation details are important:

• The feed is effectively a file, even when native connectors hide that implementation detail.
• There is typically one feed per target system.
• Feeds can represent either accounts or employees.
• Pools are the scheduled events that read the feed and create reviewable records.
• Every pool leaves records and audit trail data behind for later analysis.

Feeds

Feeds are the input for Account Reviews.

When designing a feed:

1. Decide which attributes the reviewer truly needs.
2. Keep naming and identity keys consistent across imports.
3. Test the feed with a small, controlled data set before moving to production volume.
4. If you plan to run Differential or Exit Reviews, validate carefully that identifiers are stable across consecutive imports.

There are two common feed categories:

• Account feeds, which contain the accounts and entitlements from a target system.
• Employee feeds, which are used for Exit Reviews to identify current list of employees or former list of employees.

You can populate feeds using:

• Native eramba feeds (AWS and LDAP)
• File feeds: can be uploaded manually or through the API to automate the process.
• Automations

File Feeds

The format for the csv feed file is the following:

• Account feed: login, group-or-role list, optional description
• Employee feed: login, mandatory description

When multiple groups or roles are present in the account feed, separate those values with a pipe character.

The feed type values used through the API are:

• Type 1: accounts to be reviewed
• Type 2: current list of employees
• Type 3: former list of employees

Automations

Automations can be used to write feeds from any system. You can find more information about automations here. (TheoryVideo 3:46)

Review Types

Snapshot Review

A Snapshot Review asks the reviewer to look at the full set of accounts currently present in a target system. This is the most straightforward model and is often used monthly or quarterly for systems where a complete recertification is required.

Differential Review

A Differential Review only asks the reviewer to assess what changed since the previous import, such as new accounts, removed accounts, changed groups, changed roles, or changed access attributes.

This approach is usually better for frequent reviews because it keeps the review queue manageable. It is especially useful for Active Directory and other high-volume identity stores.

One important implementation detail is that the first Differential Review pull will still contain the full set of accounts, because there is no previous baseline to compare against yet. Only later pulls show differences.

Exit Review

An Exit Review compares account data against a separate employee feed so you can identify accounts that no longer map to active personnel. This is useful for orphaned account detection and joiner-mover-leaver control testing.

In the standard examples, the Exit Review compares system accounts against the list of current employees and highlights accounts that no longer map to active staff.

Choosing the Right Type

Use Snapshot Reviews when you need full reviewing of accounts. Use Differential to notice when a change was done and a snapshot full review would be impossible. Use Exit Reviews when your main concern is discovering accounts that should no longer exist.

Strategy

Before configuring anything in eramba, define your Account Review strategy in a simple planning table. At minimum, document the target system, review frequency, review type, reviewer or reviewer group, and connector or feed method.

This step is critical because sustainability matters more than quantity. If you review too many records too often, reviewers will stop paying attention and the process will become a formality.

The most common design recommendations are:

• Prefer weekly or monthly cadences over daily full reviews.
• Prefer Differential Reviews for high-change systems.
• Use Snapshot Reviews where periodic full certification is required.
• Assign reviews to the real system owner or manager who understands the access.
• Use one review per reviewer or ownership area when different people are accountable for different subsets of access.

A practical reference strategy is:

• AWS: monthly Snapshot Review
• Active Directory: weekly Differential Review
• Accounting system: daily Differential Review
• Accounting system: weekly Exit Review

Implementation

Plan Your Account Reviews

Before continuing, review Strategy in this course.

Before creating feeds or reviews in eramba, define the operating model for each target system.

Create a planning table with these fields:

• System name
• Business owner
• Technical owner
• Review frequency
• Review type
• Reviewer group
• Connector or feed source
• Escalation requirement, if needed

The same system can appear more than once if you want to run more than one review type against it.

Access Management

Before continuing, review the Access Management documentation.

It is critical to get this right before implementing the Account Reviews use case, as correcting it later can be complex and time-consuming. The following steps must be completed:

1. Log in to Eramba for the first time and set the Admin password and email. This account is not going to be used so we recommend not using your email.
2. Create a Group for your GRC department (name it according to your department) (VideosVideo 1:37) (Theory)
3. Create User Account for the GRC team (VideosVideo 2:02) (Theory). Do not create user accounts for anyone else (IT, Human Resources, Finance, Etc)
4. Log out as Admin, from now on always login with your personal account
5. Optional: Set up SAML, Google OAuth, or LDAP Connectors (Videos & Theory)

Account Review Specific Access Permissions

Before continuing, review the Access Management, REST APIs and Notifications documentation.

• The process of setting up an API account for the Eramba system, including creating a new group with limited permissions, assigning the API account to that group, and using Postman to test the API.
• The creating a notification to alert users when a new account is created for the account review portal
• The importance of creating dummy accounts for testing purposes before setting up real accounts.

Create a Feed

Before continuing, review Feeds in this course and the REST APIs documentation.

1. Decide the source of the feed.
   1. LDAP or AWS
   2. Automation
   3. File Feed
2. Create the feed with the title and source.

How to Create an AWS Feed

1. Create a new feed.
2. In Source Type, select AWS.
3. Enter the AWS Key.
   • Use the key from the AWS Programmatic account that will be used to pull IAM resources.
4. Enter the AWS Secret.
5. Specify the AWS Region.

How to Create an LDAP Feed

1. Create a new feed.
2. In Source Type, select LDAP.
3. Select the LDAP connector. (This connector needs to be created beforehand, see Access Management.)

How to Create a File Feed (CSV)

1. For an account feed, prepare three CSV columns: login, groups-or-roles, and optional description.
2. For an employee feed, prepare two CSV columns: login and mandatory description.
3. Make sure the identifier (login) used for comparisons stays stable across files.
4. If one account belongs to multiple groups or roles, separate those values with a pipe character.
5. Upload it into eramba using the API.

Account Review Creation

Before continuing, review Review Types in this course and the User Interface documentation.

Once feeds are working, you can create the Account Reviews themselves.

For each review, define:

• The review name
• The target system
• The frequency
• The review type
• The owner
• The reviewer or reviewer group
• The feed that provides the data

The practical setup also includes:

• Comparison type, which can be case-sensitive or non-case-sensitive
• Portal settings with a clear reviewer-facing title
• Whether reviewers can submit without completing all items
• Whether Differential Reviews should automatically submit empty pools when no changes are found
• For Exit Reviews, the employee feed used for comparison

1. Open the Account Reviews module and create a new review.
2. Enter a clear review name that identifies the system and cadence.
3. Select the target feed.
4. Choose the review type: Snapshot, Differential, or Exit.
5. Define the schedule.
6. Assign the owner and reviewer or reviewer group.
7. Configure the portal settings.
8. If the review is Differential, decide whether empty pools should be auto-submitted.
9. If the review is Exit, select the employee feed used for comparison.
10. Save the review and trigger or wait for the first pull.

An important operational limitation is that Account Review objects themselves are not currently created through the API. In practice, that means you can automate feed generation, but the review definitions still need to be configured in eramba.

Notifications

Before continuing, review the Notifications documentation.

Notifications are essential for Account Reviews because a technically correct review that no reviewer notices has no control value.

The most common notification scenarios are:

• A new review cycle is ready for review.
• A Differential Review detected meaningful changes.
• An Exit Review identified unmatched accounts.
• A pool failed because the file was missing, malformed, or otherwise invalid.
• A review is overdue and requires escalation.
• A finding was created, updated, or is approaching deadline.
• A reviewer account was created and needs onboarding instructions.

When enabling notifications:

1. Adjust the subject and body so recipients understand exactly what is expected from them.
2. Confirm the right recipient group is configured.
3. Test delivery with a dummy account.
4. Verify that links open the correct portal page with the expected permissions.

The email body should usually contain the portal URL so the reviewer can jump directly into the Account Review Portal and complete the work from the link.

Test the Account Review

Before continuing, complete Account Review Creation and Notifications.

A common test sequence is:

1. Create the review.
2. Start the review.
3. Use Trigger Pool so you do not have to wait for the real schedule.
4. Confirm that records appear as expected.
5. Generate notifications.
6. Log in as the reviewer.
7. Verify that the portal shows the correct items and allowed actions.

During testing, remember that the first Differential Review pull is a baseline rather than a true delta-only run.

Run and Complete a Review

1. Trigger the notification flow and test access with a dummy reviewer.
2. Open the review from the notification or directly through the Account Review Portal.
3. Inspect each record presented for review.
4. Mark the record as okay, not okay, or not sure.
5. Add comments when clarification or justification is needed.
6. Attach supporting evidence where required.
7. Create a finding for any access issue that needs corrective action.
8. Complete the review and confirm the record is stored for audit trail purposes.

Operational Steps Summary

Once Account Reviews are implemented, the operational goal is to keep feeds current, keep reviewers engaged, and keep findings moving to closure.

The recurring activities are:

• Generate or receive the latest feed files.
• Run the scheduled pull jobs.
• Confirm imports completed successfully.
• Review the portal output.
• Let reviewers mark items as okay, not okay, or not sure.
• Create findings when something requires remediation.
• Retain the resulting evidence for audit and management reporting.

A few day-to-day details are especially important:

• The first Differential Review pool acts as the baseline and therefore contains all discovered accounts.
• Later Differential pools highlight only the differences.
• Exit Reviews highlight accounts that do not map to the current employee feed.
• Pools, Feedback, and Audit Trail records can all be used to investigate what happened on a specific run.

Operational quality depends heavily on tuning. If reviews become too noisy, reduce frequency or switch from Snapshot to Differential where appropriate. If reviews stop producing meaningful outcomes, revisit ownership, reviewer scope, and the attributes included in the feed. It is also good practice to simplify forms and views so reviewers and administrators only see the columns and fields they really need.

Video Guides

Account Review Course Introduction

User Interface Introduction

The key points covered include:

• The landing dashboard, which provides a configurable overview of data from different modules in the software.
• The module structure, where data is organized into tabs and modules with a consistent user interface.
• The menu bar, which provides options to add new items, generate reports, access settings, and view activity logs.
• The concept of "views", which allow users to customize how data is displayed and filtered.
• The ability to save custom views, set them as defaults, and control permissions for other users.
• Functionality to perform bulk actions on multiple items, such as editing or updating their status.