Access reviews

Access reviews in Keel

A user-access review is a periodic check that the right people have the right access, and that leavers and stale accounts are gone. Auditors probe it hard. In Keel a review is a list with a decision on every row, and completing it files a dated record as evidence.

Access reviews has three tabs. Reviews is where you start, work through and complete reviews. Systems lists each connected system with its accounts and its last review, and is where a system review starts, covered below. Accounts lists the accounts Keel has recorded on those systems, covered below.

Two kinds of review

Review	What it snapshots	Button
People review	The active people on the People page, or one group of them	Start review
System review	The active accounts Keel has recorded for one system: GitHub, Cloudflare or Neon	Start system review

Both forms sit in the Start a review panel on the Reviews tab, and only owners and admins see it. A system review can also start from its row on the Systems tab. A review takes its snapshot when it starts, so a later change to your directory or to a system does not alter a review that is already open.

Start a people review

Bring your people in first, from a CSV export or, on plans with directory sync, from a provider such as Microsoft Entra ID or Google so the roster comes in automatically.

Then give the review a title and, optionally, a scope such as the system it covers. The scope defaults to All systems. If your people carry groups, pick one to certify only that group; otherwise the review covers everyone active. With no active people, Keel asks you to add some before it will start.

System reviews

Access reviews > Systems (/access-reviews/systems) has one row per system Keel records accounts for: GitHub, Cloudflare and Neon, plus any system you upload accounts for by hand. Each row shows the active accounts, how many are admins, how many have MFA off, when the connector last saw an account, when the system was last reviewed and when the next review is due. A one-off review counts as yearly for the due date.

The last column holds the next step for that system. Start review opens a system review over its active accounts straight away, titled with the system’s name. If a review of that system is already open, the button reads Open review instead. A system with no accounts yet shows Connect, which goes to Integrations. The system name opens the Accounts tab filtered to that system.

Systems without a connector

Any system Keel has no connector for can still be reviewed. The system is an information asset of type software or service, and you upload its account list as a CSV:

Add the system on Information assets if it is not there yet.
On Access reviews > Systems, select Add a system.
Pick the asset, choose the CSV file, and select Upload accounts.

CSV template downloads a file with the columns Keel reads: login, email, name, role, admin and mfa. Only login (or email, when there is no login) is required, and the columns can be in any order. admin and mfa take yes or no; a blank mfa is recorded as Unknown.

The system then has its own row, marked Uploaded. Upload a fresh list before each review. An upload replaces the system’s account list, the same way a connector sync does: an account that is missing from the new file is marked Removed with the date, and nothing is deleted.

Out of scope

Some accounts and people should not be certified: a service account, an outside auditor’s read-only login, a test account. Mark them Out of scope with a reason instead of deleting them.

Accounts: on the Accounts tab, select the accounts, choose Mark out of scope in the bar at the bottom of the screen, type the reason and select Apply.
People: the same, from the bulk bar on People.
Systems: on the Systems tab, select Out of scope on the system’s row and give the reason.

An out-of-scope account or person still appears in each new review, marked Out of scope with its reason, so the record shows it was left out on purpose. It needs no decision, does not count toward the review’s total, and does not hold up completion. The completed review’s evidence and its decision pack both say how many were out of scope. A system that is out of scope cannot start a review and is never shown as due.

Bring back into scope undoes the mark. Every change, either way, is recorded in the audit log with the reason and who made it. A connector sync or a new upload leaves the mark in place. Reviews that are already open keep what they captured when they started.

Start a system review

A system review certifies the accounts that exist on the system itself, which can differ from your directory: a contractor added straight to GitHub, an old Cloudflare login nobody removed.

The Start system review form appears once a connected system has active accounts recorded. Pick the system from the list, which shows how many active accounts each one has. The title is optional and defaults to the system’s name, such as GitHub access review, and the scope is set to that system’s accounts.

Each row in a system review shows the account’s login, its role on the system, whether it is an admin, and its MFA status. MFA reads Yes or No when the system reported it, and Unknown when it did not. A known No is highlighted.

Reviewer and recurrence

Both start forms take a Reviewer and a Repeats setting, and the top of an open review lets you change either.

Reviewer is the workspace member accountable for certifying the review. Pick from the members of the workspace. Once the review is completed the reviewer is fixed, because the completed review is the evidence.
Repeats is One-off, Monthly, Quarterly, Every 6 months or Yearly. A completed review shows when the next one is due, counted from the day it was completed. You can change the recurrence at any time.

The Reviews tab lists each review’s reviewer and next due date. Its banner reads the next due date from the most recently completed review, and treats a one-off review as yearly.

System owners and overdue reminders

Each system on the Systems tab has an Owner. Select the owner’s name (or Not set), pick a workspace member and select Save owner. Pick No owner to clear it.

A system review started with no reviewer picked takes the system’s owner as its reviewer.
When a system’s review is overdue and none is open, Keel emails the owner a reminder, at most once a week. A system with no owner, or whose owner has left the workspace, reminds the workspace’s owners and admins instead.

A review falls due by its Repeats setting, or a year after completion for a one-off. A system that has never been reviewed, or is out of scope, gets no reminder. The reminder arrives with the other weekday reminders, such as evidence requests and control reviews.

Review each account

Set a decision on every row:

Keep: the access is still appropriate.
Revoke: a leaver, or access that is no longer needed.
Modify: more access than the role needs.

Each row also takes a note, which is the place for the reason. Keel records who set each decision and shows it under the decision. Keep all remaining sets every row still pending to Keep, for the common case where only a few rows need a different answer.

Leavers and accounts with no owner

While a system review is open, Keel checks each account’s email against your directory and flags two kinds of row:

Leaver: the email belongs to someone who is no longer active in the directory, or whose end date has passed. These are usually a Revoke.
No owner: nobody in the directory has that email. It may be a contractor added straight to the system, a shared login, or an account that belongs out of scope.

Pick Leaver or No owner under Flag to see just those rows, then decide them together. The check runs against the directory as it is today, so a completed review does not show it. It needs at least one person in the directory, and it skips out-of-scope accounts. GitHub reports a login and no email, so its accounts are not checked unless the login is an email address.

Decide many rows at once

Tick the box on each row, or the box in the header to select every row shown, and a bar appears at the bottom of the screen. Choose Keep, Revoke, Modify or Reset to pending and press Apply. Revoke asks you to confirm first. A bulk decision leaves each row’s note as it was, and records you as the person who decided.

The filters above the table narrow what is shown, so the header box selects only those rows. Decision filters by Pending, Keep, Revoke or Modify. A system review also has Flag: Admin shows the admin accounts and No MFA the accounts the system reported without MFA. For example, filter to No MFA, select all, and apply Modify to queue MFA enforcement for each of them. Reviewing against least privilege, only what each person needs to do their job, is what stops access creeping over time.

Flag anomalies with AI reads the review’s rows and lists the ones worth a closer look, such as admin roles or external accounts. It uses AI credits and reasons only from the fields the review captured. In a system review those are the login, role, admin flag and MFA status. Its notes are for the reviewer to weigh, and it sets no decisions itself.

Complete the review

Complete review stays unavailable until every row has a decision. Completing it:

records who completed the review and when;
files the review as evidence on the Access control policy and User provisioning & deprovisioning controls, and for a system review the evidence names the system;
creates a task for every row marked Revoke or Modify, so each removal or change is tracked until someone does it. The row shows its task and the task’s status, and the task’s Source links back to the review.

If the tasks could not be created, the review shows Create missing tasks. It creates only the tasks that are missing, so pressing it twice never opens a duplicate.

Decision pack

Decision pack at the top of a review opens a print-ready record of it. Use your browser’s Save as PDF to keep a copy or send it to an auditor. It lists:

the review’s scope, reviewer, recurrence, and the dates it was opened and completed;
every account with its decision, the note, who decided it, and when;
for each Revoke or Modify, the removal task and its status, or No task linked if there isn’t one.

You can print an open review too. The pack then says the review is not complete and how many decisions are still pending.

The Accounts tab

Access reviews > Accounts (/access-reviews/accounts) lists every account a connector sync or a CSV upload has recorded. For each account it shows the system, the login with the person’s name and email where the system gave them, the role, whether the account is an admin, MFA status, whether it is active or removed, whether it is in scope, and the dates it was first and last seen. Owners and admins can mark accounts out of scope from here (see Out of scope).

These rows of links filter the list:

All systems, or one system.
Any status, Active or Removed.
Any scope, In scope or Out of scope.
Any owner, Leaver or No owner (see Leavers and accounts with no owner). This row appears once the directory has people in it, and only checks active, in-scope accounts.

The filters are part of the address, so a filtered view can be bookmarked or sent to someone. For example, /access-reviews/accounts?system=github&status=removed shows the GitHub accounts that have gone. The system values are github, cloudflare, neon and, for an uploaded system, asset: followed by the asset’s id. The status values are active and removed, the scope values are in and out, and the owner values are leaver and orphan.

When a sync no longer sees an account, Keel marks it Removed with the date, and keeps the row. Nothing is deleted, so the tab also records when access ended.

Where the accounts come from

The accounts come from evidence connections for GitHub, Cloudflare and Neon, set up on Integrations > Evidence. Account lists refresh on the daily scheduled collection. Collect now re-runs a connection’s checks straight away but does not refresh its account list.

System	What Keel records	Access it needs
GitHub	Organization members and outside collaborators	Organization Members and Metadata, both read. MFA status is only known when the credential belongs to an organization owner; otherwise it shows Unknown.
Cloudflare (preview)	Members of the account who have accepted their invitation, with their roles and two-factor status. Pending invitations are left out, because an invitee has no access until they accept.	An API token with Account Settings: Read
Neon (preview)	Members of the organization with their role and MFA status, plus collaborators on any projects you name when you connect	An organization API key. Neon has no read-only API key, so the key you give Keel is able to make changes. Keel only ever sends read requests with it.

Cloudflare and Neon are in preview: built, and still being tested against live accounts. The Catalog tab under Integrations shows each source’s current status.

If Keel cannot read a system’s whole account list on a run, it records nothing for that run. A partial list would mark real accounts as removed, so Keel keeps the previous list instead.

Merged pull requests as change evidence

On the same daily run, the GitHub connection reads the pull requests merged since its last run and files each one as an evidence item on the Change management control. The item links to the pull request and states who wrote it, who approved it, whether the only approval came from the author, whether its checks passed, and the merge date. A pull request approved by someone other than its author also counts toward Secure software development. Each pull request is filed once, and later runs do not rewrite it.

This needs three more read permissions on the token: Pull requests, Checks and Commit statuses. The Keel GitHub App used by Connect with GitHub does not request them yet, so a one-click GitHub connection syncs accounts but files no change evidence. To get it today, connect with a fine-grained access token that has those permissions.

Next steps

Integrations: connect GitHub, Cloudflare or Neon so their accounts appear here.
Evidence: find the completed review and the merged-change records.
Tasks: make sure flagged removals and changes actually happen.
Frameworks & crosswalks: one review can satisfy access requirements in several frameworks.