A policy in EquanimGRC is a versioned document with an owner, a lifecycle status, a review cadence, and explicit links to the framework controls it satisfies. Every policy carries its own revision history, can be branched for a specific part of your organization, and moves through a defined approval workflow before it becomes effective. This page describes what the product literally stores and does.
Authoring and managing a policy
Each policy has a title, description, body content, an owner, and an optional department and category (security, privacy, compliance, operational, hr, financial, legal, or technical). On creation, EquanimGRC assigns a sequential policy number scoped to your tenant — for examplePOL-2026-001 — so the identifier never collides with another organization's.
A policy declares a review cadence in months (12 by default). When the policy becomes effective, EquanimGRC computes a next_review_date from the effective date plus the review cycle. Policies past that date surface through a review due scope, and you can query the ones coming due within a window so reviews never quietly lapse.
Lifecycle and status
A policy moves through four states: draft, editing,ready for review, and approved. The transitions are explicit, not implied:
- Submit for review moves a draft or edited policy to ready for review.
- Approve moves a reviewed policy to approved, sets the effective date, computes the next review date, and increments the policy's version number.
- Start editing takes an approved or in-review policy back to editing so changes are tracked separately from the approved revision.
- Send back to draft (also exposed as reject) returns a policy to draft.
Only a draft or editing policy is considered editable. The status is the record of where a document is, not a label you set by hand.
Versions and history
Every policy keeps an ordered set of policy versions. The first version is created automatically when the policy is created, and each subsequent edit, branch, merge, rollback, or sync produces a new version with an incrementing version number that is unique per policy.
Each version stores its full content and a SHA-256 content hash. The hash lets EquanimGRC tell, cheaply and exactly, whether two versions are identical — which is what makes branch comparison and sync detection reliable rather than approximate. A version also records achange_type (edit, branch create, merge, rollback, or sync) and an optional change summary, so the history reads as a sequence of intentional actions.
Versions can be diffed. A line-by-line diff against the previous version, the source version of a branch, or any other version produces added, removed, and unchanged lines, plus change statistics: lines added, lines removed, lines unchanged, and a change percentage. To undo a change, you create a rollback version — a new version whose content is copied from an earlier one and tagged as a rollback, so the history is never rewritten.
Beyond policy versions, EquanimGRC records an AuditLog of actions across the workspace — who did what, to which resource, and when — which gives auditors a separate, queryable trail alongside the policy's own revision chain. Seeevidence-as-code for how the same discipline applies to the evidence behind your controls.
Mapping policies to controls
A policy is connected to framework controls through a policy control mapping. Each mapping records a coverage percentage (0–100), free-form implementation notes, and a flag marking whether the mapping was suggested by AI or verified by a human. A policy's overall coverage is the average coverage across its mapped controls.
You can add and remove mappings by hand, set coverage per control, and confirm an AI-suggested mapping as human-verified once you've reviewed it. You can also letPolicyControlMapperService propose mappings: it embeds the policy text, finds relevant controls by semantic similarity, and returns suggestions with a coverage estimate, a confidence score, and reasoning. Suggestions below a confidence threshold are dropped, and nothing is applied automatically unless you ask it to. The service also produces a coverage report and a gap analysis so you can see which controls a policy leaves uncovered.
Controls come from the compliance frameworks you've activated. Seeframeworks & controls for how frameworks and their controls are modeled, and Posturizer, which can draft policies directly from the controls you need to satisfy.
Contexts and branching
Real organizations rarely run one policy everywhere. A base access-control policy may need a stricter variant in a regulated region, a different control mapping for a specific product, or an exception for one team. EquanimGRC handles this with policy contexts andbranching rather than copy-and-paste.
A policy context is a named scope — typed as department, product, environment, region, team, or custom — and contexts can nest into a hierarchy. You branch an approved base policy into a context with PolicyBranchService, which creates a new policy linked back to its source, seeds the branch's first version from the source's current content, and optionally copies the source's control mappings. Only approved policies can be branched, so a branch always starts from a reviewed baseline.
Each branch tracks the source version it was branched from and the last source version it was synced with, so EquanimGRC can tell you how many versions a branch is behind its source and whether it needs syncing. When a base policy publishes a new approved version, its branches are flagged as needing sync. The service supports the full set of operations:
- Branch — create a context-specific variant from an approved base policy.
- Compare — diff a branch against its source, with change statistics and a count of versions behind.
- Sync — pull the source's current content into the branch as a new version, tagged as a sync.
- Merge — preview source and branch content side by side, then apply a manually resolved merge as a new version, preserving local changes.
- Rollback — return a branch to a specific earlier version.
Because branches keep a link to their source and their branch point, the lineage stays explicit: you can follow a branch back through its ancestors to the root base policy.
Importing existing policies
If you already maintain policies elsewhere, PolicyImportService ingests them in bulk from a CSV or JSON file. Each record maps to a policy's title, description, content, policy number, and status; the importer resolves the owner by email and the department by name within your tenant, falling back to the importing user as owner when no match is found. It reports per-record successes and errors rather than failing the whole batch, so a few malformed rows don't block the rest of the import.
Approval workflow
Policies are approvable. EquanimGRC supports two approval mechanisms, depending on how formal your process needs to be.
The simpler one is a direct approval record — a polymorphic decision attached to a policy (or a specific policy version) with a status of pending, approved, or rejected, an approver, a comment, and a decision timestamp. Approving or rejecting it calls back to the policy so the policy's own state stays consistent with the decision.
For multi-step sign-off, an approval workflow defines an ordered sequence of steps, each requiring a specific role (admin, manager, editor, or auditor) and carrying a label and an escalation window. When a policy is submitted, ApprovalWorkflowServicecreates an approval step for each configured step under a single run, assigns and activates the first step, and advances through the sequence as each approver decides. Steps have a due date, can be escalated when overdue, and record who decided and when — so a policy's path to approval is auditable step by step.