> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/admin-user-guide/governance-and-reporting.md).

# Governance and reporting

Everything before this step grants access. This step is about proving that the access people hold is still the access they should hold — and being able to show it.

It has two halves.

**Access review** asks a person to look at what someone has and confirm or remove it. It is a decision, made on a schedule, with a record of who made it.

**Reports and audit logs** are the read-back: who signed in, what they authenticated with, what access exists, what failed, and the trail behind all of it. No decisions, just evidence.

Reviews are what an auditor asks you to run. Reports are what they ask you to produce.

## What this step is for

Access accumulates. People change roles and keep the access from the last one, projects end without anyone withdrawing the access they needed, and accounts stop being used without being closed. None of that shows up as an error — the system works exactly as configured. It only surfaces when someone looks.

Governance is that looking, done deliberately rather than after an incident.

## Order of work

{% stepper %}
{% step %}

### Run a review

Run a review over the access that matters most — administrative entitlements, privileged accounts, and anything covered by a regulation.
{% endstep %}

{% step %}

### Act on what it returns

A review that revokes nothing has told you either that access is clean or that reviewers are approving without reading.
{% endstep %}

{% step %}

### Keep the evidence

Export the reports that support the review, and keep them with it.
{% endstep %}
{% endstepper %}

Reviews are worth scheduling rather than running when something prompts them. The Scheduler and automation step can run the campaign creation for you.

## Related settings elsewhere

Some governance behaviour is configured outside this step:

* **Dormant accounts** — the inactivity thresholds that warn a user and then deactivate an unused account are set in **Security policies**, and the warning mails are edited in **Branding and customisation**.
* **Approval workflows** — who signs off on an access request is configured in **Access policies and approvals**.

## In this section

| Page                   | What it covers                                                                     |
| ---------------------- | ---------------------------------------------------------------------------------- |
| Access review          | Creating a review campaign, assigning reviewers, and certifying or revoking access |
| Reports and audit logs | The reports available, where each lives, and exporting them                        |