Policy Workflow

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.
• It governs changes to policies described in Policies and ABAC.
• All workflow events are recorded on the Immutable Ledger.