# Reviewing access changes

An access review is a recorded check of who gained, lost or changed access over a period. SecOps helps you inspect the changes and keep a review record with its data coverage, notes and follow-up tickets.

## Choose a period

Open **Access → Access changes**. The default is the period after the last standing review, or the last full month when there is no review yet. You can choose **Last 30 days** or a custom range instead.

A change-review period can cover at most 366 days. If the last review is older, the default period is capped rather than including every day since that review. Check the displayed start and end dates when catching up a long gap.

Changes are grouped by provider and kind: accounts added or removed, privilege granted or revoked, roles and policies, group membership, credentials, MFA and safeguards. Open a group and read its events rather than deciding from the count alone.

Expected activity is hidden initially. Include it when the review needs to cover those events too; an automation rule should not make its existence unknowable.

## What should we check?

For each material change, check whether the account, role, actor and timing fit an intended change. Follow up unexplained privilege, access left after departure, broad credentials and weakened protections in the provider or your work tracker.

Read current account state alongside events. GitHub does not record a member switching two-factor sign-in on or off in this audit log, and Tailscale uses the identity provider for authentication changes. The event list is not a universal record of every change in every provider.

## Record a review

Choose **Record review**, confirm **First day reviewed** and **Last day reviewed**, write **What you saw**, and add ticket links or references, one per line. The last day cannot be in the future.

The record keeps the period, who recorded it, when, the note, ticket references, provider coverage and last-load state. Ticket references document follow-up; entering them does not create tickets in another tool.

For example, a useful note names a role grant you verified against a change request, a credential whose owner must confirm its use, and the follow-up reference. “Reviewed” alone gives the next reader little context.

## Read coverage before signing off

A provider with no changes might have been quiet, or its data may not have arrived. Check the coverage and whether the last load finished, was partial, failed or was still running.

Coverage spanning the reviewed dates means the held evidence reaches across that period. It does not prove the provider reported every event or that there were no gaps between the first and last records. Record limitations in your note rather than treating a coverage label as an audit guarantee.

## How the next period starts

The latest uncorrected review moves the change-attention start forward. If you review through today, later changes on the same day are still eligible after the time the review was recorded. This prevents an entire day disappearing just because the review happened in the morning.

Recording a review does not resolve current account-state concerns such as MFA being off. Those need a provider change or further investigation.

## Correcting a review

Open **Access → Reviews** and the recorded review. Records remain unchanged. **Record correction** appends a new record linked to the earlier one, preserving what the original said.

Each review has its own link, so you can point a colleague or an auditor to the record and its stated limits. Keeping a record is evidence of the recorded review, not certification that every access right was appropriate.

## Learn more

- [Understanding account access](/docs/secops/access)
- [Ownership and identity matching](/docs/secops/ownership)