> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Reviews

> Run periodic access reviews across all connected systems to verify who has access to what.

This page is called **Access** in the sidebar and **Access & Reviews** once you open it. It lets you run periodic reviews of user access across all connected systems. Access reviews are a core requirement of SOC 2, ISO 27001, and HIPAA — auditors need evidence that you regularly validate who has access to what.

## How access data is collected

DSALTA pulls user access data from every connected integration. When you connect an identity provider (Google Workspace, Microsoft Entra ID, Okta), a cloud platform (AWS, GCP, Azure), or any other integration, DSALTA syncs the full list of users, their roles, and their permissions into the Access module.

Each access record shows:

| Column           | Description                                          |
| ---------------- | ---------------------------------------------------- |
| **Name**         | Name of the person or account with access            |
| **Source**       | Which integration the account comes from             |
| **Account type** | Whether the account is a person or a service account |
| **Email**        | Email address on the account                         |
| **Role**         | Their assigned role or permission level              |
| **Status**       | Current state of the account in the source system    |
| **MFA**          | Whether MFA is enabled for this account              |
| **Created**      | When the account was created                         |
| **Deactivated**  | When the account was deactivated, where applicable   |

## Running an access review

Access reviews let you validate that every user's access is still appropriate. To start a review:

1. Navigate to **Data Library → Access** in the DSALTA sidebar.
2. Click **Start New Review**. A **Start New Access Review** dialog opens.
3. Enter a **Review Name**.
4. Pick a **Scope** — **All Systems**, **Critical Only**, or **Custom**. Choosing Custom adds a **Custom Scope** field of up to 50 characters.
5. Set a **Due Date**.
6. Choose the systems under **Systems to Include**.
7. Pick a **Reviewer**.
8. Click **Start Review**.

Reviews are listed with **ID**, **Name**, **Status**, **Reviewer**, **Scope**, **Progress**, and **DueDate** columns.

Inside a review, each row carries three icon buttons and the reviewer picks one:

* **Approved** (checkmark) — Access is appropriate and should remain
* **Revoked** (cross) — Access should be removed
* **Flagged** (warning triangle) — Access needs a closer look

Rows start as **Pending** until a decision is recorded. DSALTA keeps each row's current decision and the time it last changed, together with the single reviewer named on the review, and the **Periodic access review completed** test in **Data Library → Tests** passes once your organization has at least one review. Capture a completed review before you disconnect any integration it covered — disconnecting clears that integration's rows from every review, finished ones included.

## Review scope and filtering

You can filter the access review to focus on specific areas:

* **By system** — Review access for a single integration (e.g., only AWS)
* **By role** — Review users with admin or privileged access first
* **By decision** — Inside a review, the toolbar carries a **Decision** filter (Pending / Approved / Revoked / Flagged) and a search box that matches on name. On the Access list you narrow by integration source and search, and each row's current state is in the **Status** column (Active or Deactivated) alongside its **Created** and **Deactivated** dates.
* **By type** — Separate human users from service accounts

## Automated access checks

In addition to manual reviews, DSALTA runs automated tests that flag access issues:

* **Offboarded users with active access** — A per-integration test (for example `okta-offboarded-users-should-not-have-active-access`) that matches that integration's Access rows to your DSALTA **People** records by email and reports an error when someone whose People status is Terminated or offboarding still holds an Active account — so it is only as accurate as your People page.
* **MFA not enrolled** — Per-integration tests such as `okta-mfa-should-be-enabled-for-all-users` and `gws-mfa-enabled-all-users` report the accounts in that system with no MFA. Equivalents ship with Okta, OneLogin, JumpCloud, Google Workspace, Entra ID, Office 365, AWS, GCP, GitLab, Clerk, Heroku, LaunchDarkly and PostHog, each checking MFA the way that system exposes it — per account, or the org- or group-level enforcement setting. The platform **MFA status recorded** and **Organization-level MFA enforced** tests confirm every account carries a recognised MFA value, and `No` and `Disabled` are recognised values, so read the **MFA** column for the state itself.
* **Unused credentials** — AWS ships **AWS credentials not used in last 90 days should be disabled**, which reads each IAM access key's last-used date and fails when an active key has gone more than 90 days without use. For other systems, judge dormancy during the manual review from the **Status**, **Created** and **Deactivated** columns on the Access page.
* **Privilege hygiene** — Where the source system exposes it, the integration ships its own check: **AWS users should not have attached IAM policies** confirms IAM users get permissions only through groups, and **GCP service account should not have admin privilege access** flags service accounts bound to Owner, Editor or admin roles. Each account's privilege level sits in the **Role** column on the Access page, and weighing it is one of the main jobs of the periodic review above.

These automated checks appear as tests in **Data Library → Tests** and run on the nightly test schedule — see [Tests](/guides/data-library/tests) for the exact cadence.

## Compliance frameworks

Access reviews provide evidence for:

* **SOC 2** — CC6.1 (Logical access controls), CC6.2 (Prior to access), CC6.3 (Access removal)
* **ISO 27001** — A.9.2.5 (Review of user access rights)
* **HIPAA** — §164.312(a)(1) (Access control)
* **PCI DSS** — Requirement 7 (Restrict access by need to know)

## Related pages

* [People & Groups](/guides/data-library/people)
* [Devices](/guides/data-library/devices)
* [Integrations](/integrations/overview)