---
title: "Profiles and policies"
description: "What a profile is, the scopes you assign it to, how overlapping profiles merge into one policy, mandatory settings, enforcement mode, and built-in profiles."
url: "https://support.outpostplatform.com/automation/profiles/"
product: "depot"
type: "concept"
status: "draft"
ai_summary: "Outpost profiles are named bundles of settings assigned to scopes (whole client, site, device group, endpoint, user group, person, technician). Only active, assigned profiles apply. Higher rank wins; mandatory values beat every rank; compliance floors clamp last. enforcement.mode defaults to monitor. Built-in baseline profiles are locked. Needs profile:read and profile:manage."
availability:
  plans: ["home-lab", "essentials", "enterprise", "msp"]
  platforms: ["windows", "linux", "macos"]
  permission: "profile:manage"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/automation/profiles.md"
license: "CC BY 4.0"
---

# Profiles and policies

A profile is a named bundle of settings, such as a patch window, firewall
rules, or a password policy, that you assign to a group of endpoints or
people. Policy is what an endpoint ends up with after every profile that
applies to it is merged. This page explains how profiles are built, where they
apply, how Outpost decides between two profiles that disagree, and what the
agent does with the result.

To build one, see [Create and assign a profile](/automation/create-a-profile/).
To see what one endpoint resolved to, see
[Check an endpoint's effective configuration](/automation/effective-configuration/).

## What a profile holds

A profile has a **Name**, a **Category**, a **Description**, and a **Status**.
Names are unique within a category. The status is one of three values:

| Status | What it means |
| --- | --- |
| `draft` | The profile is not merged anywhere. New profiles start as drafts, so you can fill one in safely. |
| `active` | The profile is merged on every scope it is assigned to. |
| `archived` | The profile is not merged, and its record is kept. |

Only an active profile with at least one assignment applies anything. The
**Profiles** list marks a profile with no assignments **Not assigned**.

The settings inside a profile come from the settings catalog, which defines
every setting Outpost can manage, its type, its default, how it merges, and
which operating systems it reaches. A setting in a profile is either set, with
a value, or inheriting. Inheriting is not the same as zero or off: it means a
wider scope decides, and with nothing set anywhere the catalog default applies.
See the [Policy settings reference](/automation/policy-settings/) for every
setting.

A setting that the catalog maps to more than one operating system can carry a
per-OS variant: one value for Windows and another for macOS, for example. The
base value applies wherever there is no variant. A setting that the agent
applies the same way everywhere takes one value.

## Where a profile applies

You assign a profile to a scope. Each assignment has a scope, a rank, and a
**Mandatory** flag. The same profile can be assigned to several scopes.

| Scope (**Applies to**) | Covers | Default rank |
| --- | --- | --- |
| **Whole client** | Every endpoint and person in the client | 100 |
| **Site** | The endpoints in one site | 200 |
| **Device group** | The endpoints in one device group | 300 |
| **Endpoint** | One endpoint | 400 |
| **User group** | The people in one user group, when they are signed in to an endpoint | 500 |
| **Person** | One person, when they are signed in to an endpoint | 600 |
| **Technician** | One technician on your team, for remote sessions they start | 700 |

When you leave the rank blank, the assignment takes the default rank for its
scope, so a narrower scope outranks a wider one. You can set any rank of 0 or
more.

## How profiles merge {#merge-order}

When more than one profile applies to an endpoint, Outpost merges them in three
passes. Each pass can overwrite the one before it.

1. **Rank.** Non-mandatory values are applied in ascending rank, and a higher
   rank replaces a lower one. Rank 400 beats rank 100. When two profiles at the
   same rank set the same setting, the setting's merge rule decides, such as
   "the smaller value wins" for a timeout or "on wins" for a protection.
2. **Mandatory.** Mandatory values are applied next, whatever their rank. When
   two mandatory values disagree, the setting's merge rule decides between them.
   No rank can beat a mandatory value.
3. **Compliance floors.** If any applicable profile declares a compliance
   framework in `compliance.target_frameworks`, the baselines of that framework
   become floors. A floor moves a value that is weaker than the framework
   requires, including a mandatory value. See [Compliance](/compliance/).

`compliance.target_frameworks` itself is combined across every applicable
profile, at every rank. A narrower scope can add a framework and can never
remove one that a wider scope declared.

Two profiles at the same rank that set conflicting values the merge rule cannot
reconcile are reported as a conflict on the
[effective configuration](/automation/effective-configuration/) page, and the
**Assignments** tab of a profile warns when two of its assignments share a rank.
Give them different ranks.

## Mandatory settings {#mandatory}

A mandatory value is one no narrower scope can override, whatever its rank.
There are two ways to make a value mandatory:

- Select **Mandatory** on an assignment. Every setting the profile sets through
  that assignment becomes mandatory.
- Select **Mandatory** on one setting inside a profile. Only that setting is
  pinned, wherever the profile is assigned.

Both need the `profile:manage_mandatory` permission in addition to
`profile:manage`, because a mandatory value can lock a client out of settings
its own administrators are expected to control. Some settings cannot be made
mandatory, such as the appearance settings and some power settings. The setting shows **The
catalog does not allow this setting to be pinned.** for those.

## Enforcement mode {#enforcement-mode}

The setting `enforcement.mode` decides whether an endpoint changes its own
configuration to match policy.

| Mode | What the agent does |
| --- | --- |
| `monitor` (default) | Reads every setting, reports what it found, and writes nothing. A setting that disagrees with policy shows as **Drift detected** and stays that way. |
| `enforce` | Records the setting's original value, applies the policy value, checks it with a second read, and puts it back whenever something changes it. |

Monitor is the default, so enrolling an endpoint changes nothing about its
configuration until you decide otherwise. To roll enforcement out in stages,
set `enforce` on a profile assigned to one device group, check the results,
then widen it. For `enforcement.mode`, the most specific profile wins rather
than the most cautious one, which is what makes a staged rollout possible.

In enforce mode:

- The agent checks for drift every 15 minutes, and again as soon as its policy
  changes.
- When a setting stops being managed, because you removed it from the profile
  or the profile no longer applies, the agent restores the value it recorded
  before the first change.
- Moving an endpoint from enforce back to monitor does not restore anything. It
  stops further changes and leaves the managed settings as they are.
- Drive encryption is never reversed. Removing an encryption setting from
  management does not decrypt a volume.
- The agent never restarts an endpoint to apply a setting. A setting that needs
  a restart shows **Pending reboot** until the endpoint restarts.

Enforcement mode governs only the settings that change the endpoint's own
configuration. Patch, script, software, and other settings that parts of the
agent act on apply in either mode.

## Built-in profiles

Outpost ships these profiles. They are active, but they apply nothing until
you assign them.

| Profile | What it does |
| --- | --- |
| SOC 2 Baseline | Declares the scope audited against SOC 2, which turns every SOC 2 baseline in the catalog into an enforced floor. |
| HIPAA Baseline | The same for the HIPAA Security Rule. |
| PCI-DSS Baseline | The same for PCI-DSS. |
| CJIS Baseline | The same for the CJIS Security Policy. |
| NIST 800-171 Baseline | The same for NIST SP 800-171. |
| NIST 800-53 Baseline | The same for NIST SP 800-53. |
| CMMC Level 2 Baseline | The same for CMMC Level 2. |
| ISO 27001 Baseline | The same for ISO/IEC 27001. |
| DISA STIG Hardening | Applies the recommended value of every DISA STIG control the catalog cites, as ordinary settings a higher rank can override. |
| Microsoft Security Baseline | Applies the recommended value of every Microsoft security baseline control the catalog cites, as ordinary settings a higher rank can override. |
| Network Discovery | Turns on network discovery: `discovery.enabled` and `discovery.network_scan_enabled`. |

The built-in profiles carry the **Built-in baseline** chip and are locked: you
can assign and unassign them, and their contents update with the product. To
change a value that DISA STIG Hardening or Microsoft Security Baseline sets,
assign your own profile at a higher rank. A framework that a compliance
baseline declares cannot be removed by a narrower scope, and its floors cannot
be weakened.

## Permissions

| Permission | Allows |
| --- | --- |
| `profile:read` | Viewing profiles, their settings, and their assignments |
| `profile:manage` | Creating, editing, assigning, and deleting profiles |
| `profile:manage_mandatory` | Making a setting or an assignment mandatory |
| `catalog:read` | Viewing the settings catalog, its per-OS backends, and framework baselines |
| `policy:read` | Viewing the effective policy resolved for an endpoint and person |

See [Roles and permissions](/depot/roles-and-permissions/).

## Limits

- FreeBSD and OpenBSD endpoints apply only settings that are not tied to a
  platform, such as the `patch.*` install and maintenance-window settings.
  They enforce no operating system settings.
- On Linux, disk encryption is reported, not managed. Outpost reads whether
  volumes are on LUKS and never encrypts one.
- A setting the catalog maps only to some operating systems has no effect on
  the others. An endpoint reports such a setting as **Not supported on this
  OS**.
- macOS support is a preview. See
  [Supported platforms](/get-started/platform-support/).

## Related

- [Create and assign a profile](/automation/create-a-profile/)
- [Check an endpoint's effective configuration](/automation/effective-configuration/)
- [Policy settings reference](/automation/policy-settings/)
- [Compliance](/compliance/)