> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access reviews

> Run access reviews against live entitlement data instead of an exported spreadsheet: a review ticket per application owner, revoke and extend in place, and an audit trail you did not assemble.

export const Checkbox = ({items = []}) => {
  const [checked, setChecked] = useState(Array(items.length).fill(false));
  const toggle = index => {
    setChecked(prev => {
      const copy = [...prev];
      copy[index] = !copy[index];
      return copy;
    });
  };
  return <div className="custom-checkbox-list">
      {items.map((text, index) => <div key={index} className="custom-checkbox-item flex items-center mb-2">
          <input type="checkbox" checked={checked[index]} onChange={() => toggle(index)} className="mr-2" />
          <span>{text}</span>
        </div>)}
    </div>;
};

The traditional access review is a spreadsheet exported on Monday, chased for three weeks, and signed off against data that stopped being true on Tuesday. If access grants already live in Ravenna as entitlements, the review can run against the live record instead.

<Info icon="list-check">
  **Prerequisites:** [access provisioning](/guides/how-to/setting-up-access-provisioning) set up, so entitlements exist. Reviews of access granted outside Ravenna are covered in step 6.
</Info>

## What good looks like

<Checkbox
  items={[
"Each application owner gets one ticket listing their application's active access",
"Decisions are made against live data, not a snapshot",
"Revoking is a click that actually removes access, not a note asking IT to do it",
"The evidence an auditor wants is the ticket, the approvals, and the audit log"
]}
/>

<Steps>
  <Step title="Reduce the review before you run it">
    The cheapest access review is the one with less to review. Two changes shrink it more than any process improvement:

    * **Default to time-bound access.** Access that expires does not need reviewing. Set your Standard and Elevated policies to **Requester picks a duration** and offer `30d` and `90d`.
    * **Tier by risk.** Privileged access reviewed quarterly and standard access reviewed annually is a defensible position. Reviewing everything quarterly means nothing gets read.

    <Callout icon="link" color="#6B7280">Learn more in [setting up access provisioning](/guides/how-to/setting-up-access-provisioning)</Callout>
  </Step>

  <Step title="Review by application owner, not by employee">
    Reviewing per employee produces a manager staring at a list of thirty tools they do not understand. Reviewing per application produces an owner looking at a list of people they know, for a system they know.

    Each application in the catalog has an owner field. That field is your review assignment list.
  </Step>

  <Step title="Make each review a ticket with a task per decision">
    One ticket per application, assigned to its owner, with a due date. Use a task template so the review has visible structure:

    1. Review the active entitlements on the Entitlements tab
    2. Flag any grant that is no longer needed
    3. Revoke the flagged grants
    4. Confirm every remaining grant has a named business reason
    5. Record the review decision as a comment

    The ticket is the evidence. It carries who reviewed, what they decided, when, and the discussion, without anyone assembling a pack afterwards.

    <Callout icon="link" color="#6B7280">Learn more in [task templates](/guides/how-to/task-templates)</Callout>
  </Step>

  <Step title="Act in place, and watch for failures">
    The **Entitlements** tab on an application shows every grant and its status. Reviewers can revoke or extend from there, so a decision and its execution are the same action.

    Two statuses deserve attention during a review:

    * **Failed Revocation** means the access is still live. This is the one that turns a clean review into an audit finding, and it is silent unless someone looks.
    * **Skipped Revocation** usually means another active grant still requires the access. That is correct behavior, not an error, but confirm the other grant is one you intended.

    <Callout icon="link" color="#6B7280">Learn more about [entitlements](/documentation/automate/access-provisioning/entitlements)</Callout>
  </Step>

  <Step title="Automate the reminders and the failure alerts">
    Two workflows, and only two:

    * **Kick off the review.** On a schedule, create the review ticket per application and assign the owner. Reminder policies handle the chasing without you building it.
    * **Alert on failed provisioning changes.** Use the **Entitlement Status Changed** trigger to post to the Security triage channel whenever an entitlement lands on Failed Revocation. Do not wait for the next review to find these.

    <Callout icon="link" color="#6B7280">Learn more about [workflow triggers and actions](/documentation/automate/workflows/triggers-actions)</Callout>
  </Step>

  <Step title="Handle the access that is not in Ravenna">
    Some access will not be there: tools provisioned before you started, or systems with no identity provider connection. Do not pretend otherwise in the review.

    Two workable approaches:

    * **Add the application with Manual provisioning.** Grants get recorded as entitlements and confirmed by an authorized provisioner, so they appear in the review even though the grant itself happens in the target system.
    * **Pull the data with Foundry.** A [Foundry](/guides/how-to/foundry/overview) action against the tool's API can list current users, which a workflow can attach to the review ticket. Worth building only for the systems an auditor asks about.
  </Step>

  <Step title="Assemble the evidence from what already exists">
    You need three things, and all three are already recorded:

    | Evidence                          | Where it lives                                                                                                                                      |
    | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
    | Who approved each grant, and when | The approval rounds on the original access request ticket                                                                                           |
    | What was reviewed and decided     | The review ticket, its tasks, and its comments                                                                                                      |
    | Who changed the configuration     | The organization [audit log](/documentation/platform/organizations/audit-log), with actor, action, resource, outcome, and a redacted input snapshot |

    The audit log is organization admin only and exportable, which is usually what an auditor actually wants. [Vanta](/integrations/vanta/overview) covers the adjacent question of authentication method and MFA coverage per user.
  </Step>
</Steps>

## Where teams get this wrong

<AccordionGroup>
  <Accordion title="Reviewing everything at the same cadence">
    Tier it, or reviewers stop reading.
  </Accordion>

  <Accordion title="Reviewing by employee">
    Managers cannot assess thirty tools. Owners can assess one.
  </Accordion>

  <Accordion title="Exporting to a spreadsheet">
    The moment you export, the review is against stale data and the revocations become someone else's ticket.
  </Accordion>

  <Accordion title="Ignoring Failed Revocation">
    This is the specific status that produces audit findings.
  </Accordion>

  <Accordion title="No entitlements to review">
    If access is still granted by DM, fix that first. A review process on top of shadow provisioning reviews nothing.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Employee offboarding" icon="user-minus" href="/guides/playbooks/hr/employee-offboarding" horizontal>
    The other place revocation has to be reliable.
  </Card>

  <Card title="Access provisioning" icon="key" href="/guides/how-to/setting-up-access-provisioning" horizontal>
    Where entitlements come from.
  </Card>
</CardGroup>


## Related topics

- [Setting up access provisioning](/guides/how-to/setting-up-access-provisioning.md)
- [Access policies](/documentation/automate/access-provisioning/policies.md)
- [Monitoring and maintenance](/integrations/sso/monitoring-maintenance.md)
- [Employee offboarding](/guides/playbooks/hr/employee-offboarding.md)
- [User management](/integrations/sso/user-management.md)