---
title: "Review compliance posture"
description: "See where your endpoints stand against each framework, drill into a control endpoint by endpoint, and raise remediation tickets or alerts for the gaps."
url: "https://support.outpostplatform.com/compliance/compliance-overview/"
product: "depot"
type: "how-to"
status: "draft"
ai_summary: "How to read Compliance > Overview: framework cards with a compliance percentage and verdict counts, the control list, and the per-control endpoint table. Verdicts and reasons. Remediation from selected endpoints needs compliance:manage: a ticket on Enterprise and MSP, alerts on Home Lab and Essentials that close when the setting reports compliant."
availability:
  plans: ["home-lab", "essentials", "enterprise", "msp"]
  platforms: ["windows", "linux", "macos"]
  permission: "compliance:read"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/compliance/compliance-overview.mdx"
license: "CC BY 4.0"
---

# Review compliance posture

The **Compliance** pages show how your endpoints measure up against each
framework you have declared and each advisory benchmark Outpost ships. Use
them to find the controls you do not meet, see which endpoints fall short and
why, and turn the gaps into tracked work.

## Before you begin

- You need `compliance:read`. Creating a remediation ticket needs
  `compliance:manage`. See [Security and compliance](/compliance/).
- Declare at least one framework by assigning its baseline. Until you do, the
  overview shows only the advisory benchmarks. See
  [Compliance framework baselines](/compliance/framework-baselines/).
- Endpoints must be enrolled and reporting. A setting is measured from what
  the endpoint last reported, and a report more than 24 hours old does not
  count as evidence.

## Open the overview

1. Select **Compliance** > **Overview**. The **Framework posture** page opens.
2. Read the line above the cards. It gives the number of endpoints and the
   number of declared frameworks.
3. Find the card for your framework. Each card shows:
   - A compliance percentage, or **Not measured** when nothing could be
     measured.
   - The verdict counts beside it.
   - The number of controls and settings the framework cites, and how many
     endpoints are obliged to meet it.

   Cards marked **not declared** are frameworks your organization has not
   declared. Assigning an advisory profile does not declare its framework. Cards
   marked **advisory** are recommendations, not enforced floors. The CIS card
   reads **No content shipped (licensing)** and cannot be opened.

### How to read the percentage

The percentage is compliant verdicts divided by compliant plus gap verdicts.
**Not measured**, **Not applicable**, and **Excepted** verdicts are left out of
both halves. A framework at 100% with many **Not measured** verdicts is not a
compliant estate, so always read the counts beside the number.

| Verdict | Meaning | In the percentage |
| --- | --- | --- |
| **Compliant** | The endpoint reads at least as strictly as the framework requires. | Yes |
| **Gap** | The endpoint was measured and does not meet the requirement. | Yes |
| **Not measured** | Outpost has no current evidence either way. The reason is shown with it. | No |
| **Not applicable** | The control cannot exist on this endpoint, such as a Windows setting on a Mac. | No |
| **Excepted** | A gap covered by an approved, unexpired exception. See [Request and approve exceptions](/compliance/exceptions/). | No |

## Open a framework

1. On its card, select the framework's name.
2. Review the table of controls. Each row gives the control identifier, the
   settings it covers, its compliance percentage, and its verdict counts. The
   citation appears under the control identifier.

## Open a control

1. In the framework's table, select a control identifier.
2. Review the endpoint table. It lists every endpoint obliged to meet the
   control, compliant ones included:

   | Column | Shows |
   | --- | --- |
   | **Endpoint** | The hostname and operating system. |
   | **Setting** | The setting key the control covers. |
   | **Expected and observed** | **wants**: the value the framework requires. **reads**: the value the endpoint last reported, or **nothing reported**. |
   | **Verdict** | The verdict, the reason when there is one, and **See the exception** when an exception applies. |
   | **Ticket** | The reference of an open remediation ticket for this control, if there is one. |

3. To see why an endpoint has a value, select its hostname. The
   **Effective config** page opens for that endpoint and shows which profile
   won the setting.

The reason under a verdict tells you what to do next:

| Reason | Verdict | What it means |
| --- | --- | --- |
| applied, waiting on the machine to settle | Compliant | The value already meets the requirement. The endpoint is finishing applying it, for example after a restart. |
| the last report is too old to be evidence | Not measured | The endpoint last reported more than 24 hours ago. |
| this machine has never reported the setting | Not measured | No report for this setting has arrived from the endpoint. |
| the machine says this platform cannot express it | Not measured | The agent reports the setting as unsupported on this operating system or build. |
| waiting on a recovery key to be escrowed | Not measured | The agent will not finish encrypting until Outpost confirms it stored the recovery key. See [Disk encryption recovery keys](/compliance/recovery-keys/). |
| applied and then changed underneath us | Gap | Something on the endpoint changed the setting after Outpost applied it. |
| the applier could not write the setting | Gap | The agent tried and failed to apply the setting. |
| the reported value cannot be placed against the baseline | Not measured | The reported value cannot be compared with the requirement. |

## Create a remediation ticket

A remediation ticket turns a gap into work in your ticket queue. It names the
framework, the control, the setting, the required value, the citation, and the
hostnames of the endpoints you select.

1. On the control's page, select the endpoints the ticket covers. Select
   **Select the gaps** to pick every endpoint with a **Gap** verdict, or tick
   endpoints one at a time.
2. Select **Create remediation ticket**. The button needs `compliance:manage`
   and at least one selected endpoint.

The console confirms with **Raised** and the ticket reference. The ticket's
subject has the form `Compliance gap: <setting> (<framework> <control>)`, with
the framework's short code, such as `soc2`. It carries the tag
`compliance:<framework>:<setting>`, which is how the **Ticket** column finds it
again. Creating the ticket is recorded in the audit log.

If a control covers more than one setting, the ticket is about the first
setting listed at the top of the page.

## Create remediation alerts {#remediation-alerts}

On Home Lab and Essentials, which do not include the service desk, the
control's page raises alerts instead of a ticket.

1. On the control's page, select the endpoints, the same way as for a ticket.
2. Select **Create remediation alerts**. The button needs `compliance:manage`
   and at least one selected endpoint.

The console confirms with **Remediation alerts are available in Alerts for**
and the number of endpoints. Each selected endpoint gets one alert for the
setting, titled `Compliance remediation: <setting>`, in the posture category.
If an open alert already exists for the same endpoint and setting, for
example from another framework, it is raised again rather than duplicated.

An alert closes automatically the next time its endpoint reports the setting
and the setting meets every framework that applies to it, or an approved
exception covers it. You can also resolve it yourself. See
[Alerts](/service-desk/alerts/).

## Verify

Reopen the control's page. The endpoints you selected show the ticket
reference in the **Ticket** column. After you fix a setting and the endpoint
reports again, its verdict changes to **Compliant**, and the framework's
percentage and counts change with it.

## If something goes wrong

| Symptom | Cause | Fix |
| --- | --- | --- |
| Most verdicts are **Not measured** | Endpoints are offline, or have not reported in the last 24 hours. | Check that the endpoints are online. The verdicts update when they report. |
| **The fleet is larger than one read covers, so these counts are partial.** | Your fleet is larger than one posture read covers. | The counts cover part of the fleet. Open individual controls for detail. |
| **Create remediation ticket** or **Create remediation alerts** is unavailable | You do not hold `compliance:manage`, or no endpoint is selected. | Select endpoints, or ask an owner for the permission. |
| **It could not be tagged, so it will not link back to this control.** | The tag would be longer than a ticket tag allows. | The ticket exists. Find it in the ticket queue by its reference. |

## Next steps

- [Request and approve exceptions](/compliance/exceptions/) for gaps you
  accept.
- [Generate evidence packs](/compliance/evidence-packs/) for an audit period.
- [Service desk](/service-desk/) to work the tickets you raised, or
  [Alerts](/service-desk/alerts/) for remediation alerts.