Access Reviews & Identity Coverage

What it is

Access Reviews is a periodic-review campaign: who has access to what, reviewed on a schedule, with every reviewer decision — Certify, Revoke, or Flag — recorded against a point-in-time snapshot rather than a live re-check. Identity Coverage is the reconciled view underneath it: one row per person built by joining every connected identity provider, HR system, and CMDash membership, so it can show you the people no connected source can account for. When a reviewer marks an account for Revoke, CMDash can carry that decision through to a real deactivation in your identity provider — Okta, Entra ID, or Google Workspace — instead of leaving it as a task someone has to remember to act on by hand.

When to use it

Run an access review campaign on whatever cadence your framework requires (quarterly is typical for SOC 2 and ISO 27001). Use Identity Coverage whenever you need to answer "does everyone with system access actually have an owner," especially before a review campaign starts, so gaps in your identity data don't get certified by accident. Use the IdP deactivation push when a Revoke decision needs to become a real access change, not just a tracked task.

Before you start

How to

Run an access review campaign

1. Go to Compliance → All Compliance tools → Access Reviews and click New campaign.
2. Once a campaign is open, each item is a person/system-access snapshot — the page shows what was true at the time the campaign was built, described on the page itself as "never a live re-check."
3. For each item, choose Certify, Revoke, or Flag, optionally on behalf of another reviewer, with a reason note.
4. When a completed campaign closes, it files itself as compliance evidence automatically — no separate export step.

Close the loop on a Revoke decision

1. On an item you marked Revoke, CMDash opens a remediation task, but — as the app states directly on the page — that task "never itself mutates access." A link appears under the decision: Request IdP deactivation →.
2. That link takes you to the task on the Remediations page. From there, request an OKTA_DEACTIVATE_PUSH, ENTRA_ID_DEACTIVATE_PUSH, or GOOGLE_WORKSPACE_DEACTIVATE_PUSH action, matching whichever provider the account actually came from — CMDash checks this server-side and rejects a mismatched request (e.g., asking for an Entra ID deactivation on an Okta-sourced review item) before contacting any vendor.
3. By default this runs in dry-run mode: it previews the exact vendor call it would make without sending anything (toggle dry-run in Remediations → SLA Settings). The confirmation text is explicit about what happens once you turn dry-run off: "Deactivates the account this task carries (from an access-review REVOKE decision) in your connected IdP — the person will lose access immediately once approved."
4. An OWNER or ADMIN approves the pending action. CMDash then re-reads the account from the IdP to confirm the deactivation actually took effect — if the vendor accepted the write but a follow-up read disagrees, the badge reads "could not confirm" rather than showing a silent success. A confirmed deactivation shows: "Confirmed: <identifier> (<external id>) is now deactivated."
5. If the person's access needs to be restored later, the same task supports the corresponding *_REACTIVATE_PUSH action — but only on a task CMDash itself previously deactivated.
6. There is a daily cap on how many IdP deactivate/reactivate pushes can run in a rolling 24-hour window, configurable in Remediations → SLA Settings, as a blast-radius control.

Find the people no source can account for

1. Go to Security → All Security tools → Identity Coverage.
2. The page describes itself precisely: "one reconciled row per person across every identity provider, HR system and CMDash membership — and, more usefully, the people no connected source can answer for."
3. Click Re-run the identity join to refresh the reconciliation against your current connections.

Common questions

If I revoke access in an access review, does it happen automatically? No. A Revoke decision opens a remediation task; a human still has to click through to request the IdP push and a second human (OWNER/ADMIN, not the same person who requested it in the adapter-push flow generally) has to approve it before anything is sent to the vendor. Dry-run is on by default, so even requesting it doesn't touch your IdP until dry-run is turned off and the request is approved.

What happens if the vendor accepts the deactivation but I can't tell if it worked? CMDash distinguishes this from a real failure. A push that succeeded but couldn't be confirmed on read-back is never recorded as a plain failure or a silent success — it's flagged distinctly so you know to check manually rather than assuming either outcome.

Can a VIEWER read an access review campaign? Yes — listing and reading a campaign have no role restriction, so a VIEWER can see it. Creating, closing, or adding reviewers to a campaign is OWNER/ADMIN only, and recording a decision is limited to whoever is an assigned reviewer or active delegate for that item, regardless of role.

Limits: there is no bulk "revoke and push" action across multiple campaign items — each IdP deactivation is requested one remediation task at a time.

Related

• Risk Register
• Compliance Frameworks
• Evidence Collection