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

# Audit Portal

> Be sure that every change was checked against your requirements — and see where coverage gaps remain

## Overview

A finding tells you where a requirement was *violated*. The **Audit Portal** tells you the other half: which requirements were actually **evaluated** against which change — including the runs that came back clean and produced nothing.

That distinction is the whole point. A repository with zero findings looks identical to a repository Zenable silently stopped running on. The Audit Portal is what separates the two, so "requirement R was checked against change C" becomes a fact you can show an auditor rather than something inferred from the absence of a finding.

Find it under **Reporting → Audit Portal**.

## Who it's for

Three audiences read this page:

* **Engineering** — where are we covered, and where are the holes?
* **Cybersecurity** — are our controls being enforced?
* **Auditors** — show me proof the controls ran.

Auditors reach it through the **Security Auditor** role, which grants read-only access to the audit surface. See [Permissions](/permissions).

## What's on the page

### The assurance matrix

The centerpiece. It answers one question:

> Can we provide assurance that **these requirements** were enforced in **these scenarios**?

Your requirements run down the side; the **enforcement surfaces** run across the top — GitHub PR, GitLab MR, IDE / Agent, and CLI / Pre-commit. Each cell reports one of:

| State           | Meaning                                                              |
| --------------- | -------------------------------------------------------------------- |
| **Enforced**    | The requirement ran on every change that surface saw.                |
| **Partial**     | It ran on some of them.                                              |
| **Not covered** | The surface saw changes and the requirement ran on **none** of them. |
| **No activity** | That surface saw no changes at all in the period.                    |

**"No activity" is not a gap.** It is deliberately distinct from *Not covered*: "we never had the chance" is not "we had the chance and missed it". A quiet surface should not read as a failure.

A requirement that never ran anywhere still gets a row — it's shown as *Not covered* across the board. That is the finding, not an omission.

The matrix is rebuilt nightly. The whole page reports **complete days only** — figures always end yesterday or earlier, so a partially-elapsed today can never make the numbers disagree with themselves.

### Landed without a check

Default-branch changes that landed with **no** Zenable evidence. This is the actionable list: each row is a change that reached your main branch unchecked.

Every way a change can land is counted — merge commits, squash merges, rebase merges, fork PRs, and **commits pushed directly to the default branch** (shown with a *Direct push* badge). Landings are observed from your VCS provider directly, so the count does not depend on webhook delivery.

A direct push counts as checked only when a Zenable check ran on that **exact commit** (for example a CLI or pre-commit check before pushing) — a direct push is not rewritten on landing, so commit identity is the honest test.

### PR discipline

The share of default-branch landings that arrived through a pull/merge request. Direct pushes bypass review entirely, so this number is the process-integrity signal auditors ask about alongside coverage.

### Filtering

The **repository** and **date range** filters at the top apply to the whole page at once — the matrix, the gap list, the evidence log, and the export all narrow together, and the filters ride the URL so a filtered view can be shared.

### Evidence log

Every check that ran, including the clean ones. Each entry records the change (repository, commit, change ref), the surface it ran on, how many checks executed, and how many findings came out.

## Exporting evidence

**Export evidence pack** downloads the bundle an auditor asks for over your selected period: the assurance matrix, the gap list, and the raw attestations behind both.

In order to export, you must have the `audit:export` permission. For more details, see the [Role Permission Matrix](/permissions#role-permission-matrix).

<Note>
  If a future release ever introduces a kind of change the coverage figures do not count, the portal will say so **in-product, next to the number it qualifies** — the limitation always travels with the data. Nothing is omitted today.
</Note>