How Access Reviews & Access Requests Work

What a review records and who it goes to, what a decision does, and the two approvals a request passes. The steps on screen are in Run an access review and Handle access requests.

Access Reviews

A review is run as a campaign. Launching one takes a list, once, of what each person holds at that moment. The list does not change afterwards: access given after the launch is not added to it, and is picked up by the next campaign.

1. Who is covered. Every active person, or the active people in one department.
2. What is listed. Each Zonitix group and role the person holds becomes one line, called an item. A campaign can also list their apps: the ones their persona gives them, the ones a connected system reports them using, or both. An app that is in use but not in the persona is marked as drift.
3. Who reviews. Each person’s items go to that person’s manager. A person with no manager on record has their items sent to whoever created the campaign.
4. What a reviewer decides. Keep or revoke, one item at a time or many together, with an optional note. The campaign completes by itself when the last item is decided.

When The Reviewer Cannot Act

A manager who has left, or whose account is disabled, cannot open their items. Zonitix does not leave those items waiting. It hands them to the first of these people whose account is active: the reviewer’s own manager, then whoever created the campaign, then a person who administers access reviews. It never picks the person whose access is under review. This is done when the campaign is launched, again when a reviewer is offboarded, and once a day for anything missed. The new reviewer is told by email, where email is set up, and the item records who it came from.

If none of those people can take the item, Zonitix leaves it where it is, does not guess, and writes a warning to the audit log. An administrator of access reviews then reassigns it by hand.

Rules On A Decision

• Nobody reviews their own access. This holds for everyone, administrators included, and it is the separation of duties an auditor looks for.
• A reviewer decides only their own items. A person who administers access reviews may decide for a reviewer, and may hand an item to someone else.
• Two things cannot be revoked in a review: the group every active person belongs to, and the roles and groups of the primary administrator.
• A closed or archived campaign is a record. Its items can no longer be decided or reassigned.

What Revoke Does

Revoking a Zonitix group or role removes it from the person straight away. Revoking an app is different, because the account lives in another system: Zonitix starts a removal run that waits for IT to approve it. After that approval the run gains the step that removes the account: an account step for a connected app, a task for IT to do by hand for anything else. Until then the access is still there, and the campaign’s download says so.

Access Requests

A request names one app or software licence and the person it is for. It passes two approvals before anything is granted, and the two must come from two different people unless an administrator is acting.

1. The request. A person asks for themselves and may say why. An approver, or someone who manages users, may also file a request for another person.
2. First approval: should this person have it? The approvers are notified. One of them approves or rejects. An approver cannot approve a request they filed, or one that is for themselves; holders of the administrator role are exempt from that rule. Anyone who may approve may still reject.
3. A check on the person. If the person the request is for is no longer an active employee when the approver says yes, Zonitix rejects the request instead. Nobody is exempt from this check.
4. Second approval: IT sets it up. Approving starts a run that waits for IT. The person who gave the first approval is counted as the one who asked for this run, and whoever asks for a run may not approve it. Holders of the administrator role are exempt from that rule too: their approval is allowed, and the run records it as a self-approval exception. The separate-approver rule is a workflow policy that is on by default. When IT approves, the run gains the step that grants the app: an account step for a connected app, a task for IT to do by hand for anything else.
5. The outcome. The requester is told when the access has been provisioned, or that the request was rejected or declined.

If something here is not working as you expect, start with When something goes wrong.

Review Endpoints

Session routes on your own instance’s API address, https://<your-instance>-api.zonitix.com. Both features are served by the user-management service; the two runs are created in the workflow service, described in How Workflows Run (Orchestration).

• Three permissions. manage_access_reviews launches, closes, archives, reassigns, schedules and revokes from the live view. view_access_reviews reads campaigns, schedules, the live view and the CSV. certify_access decides items.
• Assignment also authorises. The person an item is assigned to may read their own queue and decide their own items without holding certify_access. The queue route returns only the caller’s items, and the decide routes check each item again. Other reviewers’ items, the campaign list and campaign administration stay behind the permissions.

What A Campaign Holds

A campaign’s status is active, completed or archived. Its items are written in one transaction at launch, each with decision: "pending", the reviewer’s email and one of these kinds:

An item is flagged privileged when it is the administrator role, when the role or group carries any permission whose name starts with manage_, or when it carries 15 permissions or more. The flag orders a reviewer’s queue (privileged first, then drift) and is a column of the CSV. It blocks nothing.

Reviewer Rerouting

A reviewer cannot act when no account has their email address, or when the account’s status is disabled, inactive, deleted, terminated, suspended, offboarded or archived. The replacement is the first of these that is an active account and is neither the person under review nor the reviewer being replaced:

• What the item keeps. reroutedFrom, reroutedAt and rerouteReason. The move is audited as ACCESS_CERTIFICATION_REROUTED.
• A decision always wins. An item is moved only if it is still undecided and still with the same reviewer at the moment of the write, so a decision or a reassignment made meanwhile is never overwritten.
• No replacement. The item is left in place and ACCESS_CERTIFICATION_REROUTE_FAILED is written with the item ids. The daily pass tries again the next day.

Decisions And The CSV

A decision is claimed with one conditional write (undecided to decided) before any access is touched. The CSV at /access-reviews/:id/export carries every item of the campaign, with the columns Person, Access, Type, Source, Privileged, Decision, Applied, Decided by, Decided at, Reviewer and Note. Decision is what the reviewer chose; Applied is what happened to the access:

Schedules

• Cadence. monthly, quarterly, semiannual, annual, or custom with a number of months. Each campaign a schedule launches is due dueDays after launch (14 unless set, from 1 to 365) and is named after the schedule and the period.
• The daily pass. Once a day Zonitix launches the schedules that are due, then looks at the open campaigns that schedules launched, then reroutes items whose reviewer cannot act.
• Reminders. With remind on, each reviewer with undecided items is emailed when the due date is two days away or less, or has passed: at most once a day for each campaign.
• Closing. With autoClose on, a scheduled campaign is closed on the day after its due date. Undecided items stay undecided and the close is audited as an early close.
• One open run at a time. With skipIfOpen on, a schedule does not launch while its previous campaign is still active.

Reminders and automatic closing apply to campaigns a schedule launched. A campaign started by hand notifies its reviewers at launch and stays open until every item is decided or someone closes it.

Request Endpoints

• Gate 1. The approve route needs approve_access_request or manage_users. The move from pending (or failed) to approved is one conditional write, so two approvals cannot each raise a run.
• Gate 2. The run is created on the Master Access Request pipeline and starts at the step IT Provisioning Approval, in the IT queue. It carries the first approver’s identity, and the workflow service counts that person among the run’s requesters. A requester may not sign the run’s approval unless they hold the administrator role: that approval is allowed and written to the run as a self-approval exception, and when the step is completed through the automation route it is audited as TASK_APPROVAL_SOD_OVERRIDE. The separate-approver rule is a workflow policy that is on by default; a refused attempt is audited as TASK_APPROVAL_DENIED_SOD.
• How the status catches up. An approved request is compared with its run each time requests are listed: a completed run makes it fulfilled, a cancelled run declined.

What Is Audited

How to read and filter these entries is in Audit Log & Log Forwarding.