---
title: Policy Workflow | Docs | Lattix
description: Staging, review, and publication rules for policy changes.
source: "https://lattix.io/docs/configuration/policy-workflow/"
content-type: text/markdown
---

# Policy Workflow | Docs | Lattix

Configuration

# Policy Workflow

Staging, review, and publication rules for policy changes.

Policies govern access to data. A misconfigured policy can either grant unintended access or lock a legitimate user out. The policy workflow controls how changes move from draft to production, how many reviewers are required, and which policies are considered sensitive enough to warrant extra scrutiny.

## Workflow options

A tenant can enable any combination of the following controls:

**Draft-first editing.** Policies are edited in a non-production draft state. A draft cannot affect live decisions; it is used only by the policy test runner.

**Required review.** Publishing a policy requires a second principal — in a configured reviewer role — to approve the change. The author cannot self-approve.

**Test-run requirement.** Publication can be gated on the draft having been tested against the tenant's sample evaluation set. Policies with untested effects cannot go live.

**Sensitivity-scoped rules.** Different rules can apply to different policies. A policy governing access to `restricted` data might require two reviewers; a policy governing `internal` data might require only one.

**Cool-down period.** High-sensitivity policies can require a minimum time between drafting and publication (for example, four hours). This prevents a single authorized principal from making a material change in the middle of an incident.

## Recommended defaults

For most tenants, the following workflow is a good starting point:

- **All changes** require draft-first editing and test runs against the sample set.
- **Changes to policies governing `confidential` or `restricted` data** require one reviewer.
- **Changes that would introduce a new external recipient group or new jurisdiction** require two reviewers and a 4-hour cool-down.
- **Changes to deny policies** (which override allows) require one reviewer.

Tighten from there based on your organization's operational tempo and regulatory exposure.

## Who can review

Reviewer eligibility is attribute-based. A reviewer must:

- Be in a role authorized to review the category of policy being changed.
- Not be the author of the change.
- (Optionally) be in a different organizational unit from the author, for separation-of-duties enforcement.

Two-reviewer scenarios can additionally require that the two reviewers themselves be distinct organizational units.

## What the reviewer sees

When a policy arrives in a reviewer's queue, they see:

- The diff between the current production version and the proposed version.
- The test runner results for the proposed version against the sample set.
- A list of objects currently governed by the policy that would see a decision change under the new version.
- The author's rationale (a required field on any change).
- The full edit history of the draft.

The reviewer can approve, reject with comments, or request additional tests.

## Emergency bypass

For incident response scenarios, the workflow supports an emergency bypass that allows a policy change to go live with a single authorized principal if:

- The change is flagged as an emergency (with a required rationale).
- The acting principal holds a configured emergency-authorization role.
- The change is additive in the direction of *more restriction*, never more access. Emergency bypass cannot be used to expand access.

Emergency bypasses are prominently surfaced on the ledger and trigger notifications to the security administrator pool.

## Audit

Every aspect of the workflow is recorded:

- Draft creation, edits, and test runs.
- Submission for review.
- Reviewer actions (approval, rejection, comments).
- Publication (including any cool-down satisfied).
- Emergency bypass (with full rationale and notification recipients).

A post-incident or post-audit reconstruction can always determine: who proposed this change, who reviewed it, how long it took, and what effect it had.

## Relationship to products and concepts

- The workflow applies to the [Policy Engine](https://lattix.io/docs/products/policy-engine/).
- It governs changes to policies described in [Policies and ABAC](https://lattix.io/docs/concepts/policies-and-abac/).
- All workflow events are recorded on the [Immutable Ledger](https://lattix.io/docs/concepts/immutable-ledger/).

[Tag Schema Defining the classifications your organization recognizes and how they are applied.](https://lattix.io/docs/configuration/tag-schema/) [Encryption Profiles KMS backend selection, algorithm policy per classification, rotation cadence, and post-quantum transition controls.](https://lattix.io/docs/configuration/encryption-profiles/)