Skip to main content
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:

​
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 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)