Access Reviews

Scope

Access reviews sit at the boundary between identity governance and compliance evidence. This guide keeps the review model and accountability guidance while leaving private implementation paths out.

Creating a Review Campaign

1. Navigate to a compliance program
2. Click “Access Reviews” or navigate to the relevant workflow
3. The list is server-paginated. Use the footer controls to move between pages; sorting and pagination are applied by the backend so large review histories do not require loading every campaign into the browser.
4. Click “New Review”
5. Set: - Name: Descriptive name (e.g., “Q1 2026 Privileged Access Review”) - Review Type: Privileged, Application, Manager, or Custom - Source: Manual (CSV) or IdP Connector. Portal campaigns are created in Portal and adopted through the separate Import from Portal picker. - Due Date: Optional deadline for completion

Scheduled Review Campaigns

Meridian seeds an access_review cadence during onboarding and program setup. The hourly background sweeper creates draft reviews for active and draft compliance programs when that cadence becomes due.

Quarterly scheduling is calendar-based, not a rolling 90-day counter: a review anchored on January 15 schedules the next draft for April 15 even if the sweeper runs late. Operators still import or confirm scope and move the draft forward through the normal access-review workflow.

Scheduled drafts appear with review type Application. This is intentional: the type describes the reviewed access subject, while the cadence is the creation trigger. There is no separate Scheduled review type.

Scheduled Reviews

Meridian seeds the access-review cadence quarterly by default. When the cadence fires, Meridian creates one scheduled review for each active compliance program only if that program does not already have a draft or in_progress review.

If an unfinished review already exists, Meridian does not create a second scheduled review. The scheduler raises a dashboard warning alert that identifies the blocking review. Operators should finish, cancel, or archive the existing review before expecting the next scheduled review to appear.

Importing Access Data

The review starts in draft status. Import your access snapshot:

1. Prepare a CSV file with the following format:

2. Click Import CSV in the header of the review detail page. The button is only visible while the review is in draft status — importing after decisions have been recorded would wipe them, so the workflow locks the import action once the review moves past draft.

3. The review automatically advances to in_progress after a successful import.

4. A snapshot hash is computed for audit integrity and a success toast reports the item count.

Who reviews each row (manager assignment)

Every imported row is assigned a reviewer so it can actually be decided — there are no permanently stuck rows:

• If a row’s manager_email matches a user in your tenant, that user is assigned as the reviewer.

• If the manager_email is blank or does not match any tenant user, the row is assigned to you (the operator running the import) as a fallback. You can reassign it later to the correct manager.

• If assigning the manager (or the fallback) would make someone review their own access, the row is instead left unassigned and flagged for reassignment — Separation of Duties forbids self-approval (see Making Decisions).

The import response surfaces a warnings list naming each row that fell back or was left unassigned, with the row number (matching the line in your spreadsheet) and the reason — e.g. “manager ‘x@y.com’ not found in this tenant; assigned to the importer”. A clean import shows no warnings.

CSV Requirements

• Optional column: manager_email (resolved to a tenant user; falls back to the importer if unmatched — see above)

• Email addresses must be valid format

• No duplicate rows (same email + resource + entitlement)
• Import is idempotent within the draft state only — re-importing replaces all items. Once the review moves to in_progress, the import button disappears and the snapshot is locked.

Importing from an IdP Connector (WS-12.5)

Instead of CSV, reviews can be populated directly from an IdP connector. Okta and Entra ID connectors are selectable in the UI source picker; Google Workspace connectors are also supported by the import endpoint (API-only for now — not yet offered in the picker):

1. Ensure an Okta connector is configured and active in Settings > Connectors.
2. Create or open a review in draft or in_progress status.
3. Use the API to trigger a connector import:
4. The endpoint pulls the current user-entitlement snapshot from Okta, creates review items, and resolves managers by email match against Meridian users.
5. The review auto-advances to in_progress if it was in draft.

Scope Options

• "all" — Every user in the Okta org with their group memberships and admin roles.
• "privileged" — Only users holding admin role assignments.
• "groups" — Users in specific groups. Pass "scope_value": "group1,group2" with comma-separated group ids or names.

Idempotent Re-Import

If the Okta data has not changed since the last import, the endpoint returns {"status": "no_change"} and does not create duplicate items.

Manager Resolution

The import resolves manager assignments by matching each user’s Okta manager email against Meridian users in the same tenant. Unresolved items are assigned to the operator who ran the import. Self-review is never created: if the IdP reports a user as their own manager (common for executives/founders), or the importer fallback would be the subject, the item is left unassigned for a GRC admin to reassign — Separation of Duties forbids a user signing off on their own access.

Limits

The connector import supports up to 10,000 users per snapshot. For larger organizations, narrow the scope with scope_kind='groups' or 'privileged'.

Making Decisions

For each item in the review, record one of:

• Approved: Access is appropriate, no action needed
• Revoke: Access should be removed
• Not Applicable: Out of scope (e.g., service account, excluded by policy)

Click “Decide” next to an item to open the decision panel. Every Approved, Revoke, and Not Applicable decision requires a written reason. Meridian trims leading/trailing whitespace and rejects blank reasons.

Revoke opens a remediation task — it does not deprovision the IdP for you. When you revoke an item, Meridian records the decision and creates a tracked high-priority remediation task (“Revoke access: {user} / {resource} / {entitlement}”) so the removal is auditable. Meridian does not automatically remove the access from Okta/Entra/Google Workspace — you (or whoever owns the source system) must action the removal and then close the task. Reviews show how many revokes are still pending remediation: the detail page shows a “N revoke decision(s) pending remediation” banner and the review list shows a per-row badge. The tasks appear in the task workspace filtered to the Access Review category. If you change a revoke back to Approved or Not Applicable, the remediation task is automatically cancelled.

All items must have a decision before the review can be submitted.

Submitting the Review

When all decisions are recorded:

1. Click “→ submitted” to submit the review
2. An evidence artifact is automatically generated containing the full decision log
3. The snapshot hash ties the decisions to the original import for audit integrity

Submission emits a review.completed event. If your tenant has event subscriptions configured (Settings > Event Subscriptions), review completion can fan out to webhooks, Slack/Teams, email, or ticket creation automatically — no extra setup in the review itself.

Submit is single-shot. Submission is protected against double-clicks and concurrent submits: the review row is locked while evidence is generated, and a second submit on an already-submitted review is rejected always exactly one evidence record per review.

After Submission

1. Work the remediation tasks created for each “Revoke” decision: remove the access in the source system (Okta/Entra/Google Workspace, the application, etc.), then mark the task complete. The tasks are in the task workspace under the Access Review category, and the review’s pending-revoke count drops as you close them.

Exporting Evidence

requests in any other state). The export contains:

• Review metadata (id, name, type, status, source/provenance state, snapshot hash, started/completed/closed timestamps, evidence id)
• Decision summary statistics (total, pending, approved, revoke, not_applicable)
• Full item-by-item local decision log with recognizable subject/reviewer/decider projections and downstream task status
• For Portal reviews, the retained atomic source packet/envelope and the separate Portal-observed item decision/remediation fields
• An integrity envelope containing the SHA-256 hash of the canonical exported payload

The file is delivered as a browser download with the filename provided to auditors as evidence of access reviews.

Running an Automated Access Review (WS-12)

Automated access reviews pull user-entitlement data directly from an IdP connector (currently Okta) instead of a CSV file. This eliminates the manual data extraction step and ensures the review reflects the current state of the identity provider.

Importing a Portal governance review

The program page links to Access Reviews, where Import from Portal opens a paginated, named campaign picker. Operators never need to type or discover a numeric campaign ID. Use Create or manage campaigns in Portal when the campaign does not exist yet, then refresh the picker and adopt it into the selected program. Meridian uses a Portal service credential with governance:reviews:read; the ordinary directory/marketplace handoff scope is not sufficient and must be re-issued in Portal with governance read access.

Meridian fetches one atomic Portal evidence packet, checks its declared content hash, and retains the Portal signature envelope. Meridian does not possess Portal’s signing secret and does not claim independent HMAC verification. Re-importing the same unchanged packet is idempotent and may reconcile newly eligible reviewers. A changed packet can refresh only while the local review has no local decisions, evidence, or protected state.

Portal-observed decisions and remediation are displayed separately and never become Meridian decisions. Every imported item starts locally as Pending. Reviewers are correlated by the stable Portal user ID, never email; missing, inactive, or self reviewers remain unassigned and appear as recovery warnings. Reassign those items to an active, independent Meridian person. Submission—not import—creates the Meridian evidence artifact. Meridian never mutates the Portal campaign.

If import reports a missing scope, re-issue the service credential; do not reuse an content-hash errors leave the prior local projection intact and create a safe failure audit. If a changed refresh is blocked after local work, finish and export that review rather than overwriting its audit history.

Prerequisites

• A compliance program with an access review in draft or in_progress status.

Step-by-Step

1. Create the review. Navigate to the program’s Access Reviews page, click New Review, and set the name, type, and optional due date.

2. Trigger the connector import. Use the API:

3. Review the import results. The response includes: - item_count — total review items created. - managers_resolved — items successfully routed to a manager. - managers_unresolved — items assigned to you (the importing operator) because the manager email did not match a Meridian user.

4. Make decisions. The review auto-advances to in_progress. Each item shows the user’s email, the entitlement type (group or role), and the entitlement name. Decide: Approved, Revoke, or Not Applicable.

5. Submit and close. Same as the manual flow — all items must have decisions before submission.

Re-Importing

If you need to refresh the data (e.g., users were added to Okta since the last import), re-run the import endpoint. If the Okta data has not changed, the endpoint returns {"status": "no_change"} and no duplicate items are created.

Manager Review Queue

Items routed to a manager appear in their review queue. Managers can approve or revoke items assigned to them. Items without a resolved manager go to the campaign creator (the operator who ran the import).

Reassigning Items

Limits

The connector import supports up to 10,000 users per snapshot. For larger organizations, narrow the scope or split into multiple review campaigns.