Appearance
Policy Register
Where to find it: Policy Governance, then Policy Library (/governance/library).
The register is the authoritative record of every policy, standard and procedure the organisation maintains.
What a policy record carries
| Field | Purpose |
|---|---|
| Title | The policy name and formal charter title |
| Identifier | Canonical business reference (POL-YYYY-NNNN) |
| Category | Classification taxonomy (e.g. Information Security, Prudential Risk, AML) |
| Owner and owner title | Accountable executive owner |
| Department / Function | The operating organizational unit (OrgUnit) |
| Active Version | Pinned version identifier (v1.0, v2.1) |
| Status | Lifecycle state (draft, in_review, under_revision, published, expired, archived) |
| Sections & Statements | Structured hierarchy of sections and indivisible atomic statements (PST-) |
| Source Provenance | manual (authored in-tenant) or source_pack_id (adopted from Content 2.0) |
| Operationalization State | NOT_MAPPED, PARTIALLY_OPERATIONALIZED, OPERATIONALIZED, GAP_IDENTIFIED |
| Effective date | When this version takes binding effect across the enterprise |
| Review date | When it is next due for mandatory periodic review |
| Expiry date | When it lapses if not renewed by a governed review |
| Mapped requirements | Downstream regulatory obligations it addresses |
Statuses
| Status | Meaning |
|---|---|
| Draft | Being written; not in force |
| In Review | Submitted into the governed approval flow |
| Under Revision | Returned or rejected; being revised |
| Published | Approved and in force |
| Expired | Past its expiry date |
| Archived | Withdrawn from the estate |
A published policy must enter revision before re-approval
A policy in Published cannot be resubmitted for approval directly. It has to enter revision first.
This prevents a published policy being quietly re-approved without a version change — which would leave two different documents having been "the published policy" with no record of the difference.
Versions
Each policy carries a version identifier. A revision produces a new version, and the previous version remains part of the record.
This matters when an incident or an audit asks what the policy said at a particular time. The answer should be a version, not a recollection.
Dates and their distinct meanings
| Date | Question it answers |
|---|---|
| Effective date | From when does this version bind people? |
| Review date | When must someone look at it again? |
| Expiry date | When does it lapse if nobody does? |
All three feed the Expiry Monitor and the GRC Calendar.
Structured sections and atomic statements
Rather than managing policies as opaque, unsearchable binary blobs (e.g. uploaded PDFs), OrviQ maintains policies as structured data trees:
$$\text{PolicyRecord} \longrightarrow \text{PolicyVersion} \longrightarrow \text{PolicySections} \longrightarrow \text{PolicyStatements (Atomic)}$$
- Section Hierarchy: Policies are broken down into numbered chapters and sub-sections (e.g. Section 3.1 Access Control Requirements).
- Atomic Statements (
PST-): Each distinct obligation within a section is an atomic statement. Atomic statements form the granular units of governance: they are independently mapped, versioned, operationalized, and audited. - Content 2.0 Integration: Instruments adopted from the Content Library arrive pre-structured into sections and atomic statements, saving compliance teams hundreds of authoring hours.
Operationalization posture
Every policy in the register carries an aggregated operationalization posture:
NOT_MAPPED: Purely descriptive text; no operational controls, risks, or evidence expectations mapped.PARTIALLY_OPERATIONALIZED: Some statements mapped to controls or owners, but lacking evidence expectations or scope populations.OPERATIONALIZED: All statements mapped to operating controls, accountable owners, and active evidence expectations.GAP_IDENTIFIED: One or more statements linked to active deficiencies in the Gap Workbench.
See Policy Operationalization & Traceability.
Mapping policies to requirements
Policies link to regulations and requirements, recording which obligations each policy addresses.
Requires policy.map or policy.operationalize.
This mapping powers structural coverage assessment against target frameworks.
Semantic Doctrine: Mapping != Compliance
Policy mapping is a statement of design intention. It demonstrates that the organization has articulated an internal rule addressing a statutory mandate. It does not prove that systems enforce the rule, that personnel adhere to it, or that the organization is compliant.
Policy comparison
Comparison produces a deterministic difference between two policies or two versions of one policy — what text changed, what was added, what was removed.
Deterministic means reproducible: the same two documents produce the same comparison every time, with no model interpretation in between.
Use it to answer "what actually changed in v3.0?" during a review, and to evidence to an auditor that a stated change was made.
Policy gap analysis
Gap analysis compares your obligation set against your policy mappings and surfaces:
- Requirements with no policy coverage
- Policies mapped to nothing
- Requirements covered only by expired or draft policies
The third category is the one worth watching. An obligation covered by a policy that expired eight months ago is uncovered in substance while appearing covered on a count.
Common tasks
Create a policy
Create the record with title, category, owner, version and dates. Requires policy.write.
Map a policy to requirements
Use the mapping panel. Requires policy.map.
Record a review
Record the review and set the next review date. Requires policy.review.
Submit for publication
Find policies about to lapse
Use the Expiry Monitor.
Permissions
| Action | Permission |
|---|---|
| View the register, dashboard, expiry monitor and comparisons | policy.read |
| Create and update policies | policy.write |
| Operationalize atomic statements against controls/risks | policy.operationalize |
| Link policies to regulations and requirements | policy.map |
| Record a review and set the next review date | policy.review |
Requires the policy_governance entitlement. Adopting from the Content Library additionally requires content_library and policy_pack.adopt.
Example
A bank's register holds 94 policies, standards and procedures.
| Status | Count |
|---|---|
| Published | 71 |
| Under Revision | 12 |
| In Review | 6 |
| Draft | 3 |
| Expired | 2 |
The two expired policies are the headline. Both are standards owned by a function that reorganised eight months ago, and neither had an owner after the reorganisation. Gap analysis shows they are the only policy coverage for nine obligations.
That is a real compliance gap, and it was invisible until the register made the ownership vacuum and the coverage dependency visible at the same time.
Outcome: ownership reassigned, both standards revised and republished, and a control added to the reorganisation checklist requiring policy ownership to be reassigned explicitly.
Troubleshooting
"I cannot submit a published policy for approval." Move it to revision first. Direct re-approval of a published policy is blocked by design.
"Gap analysis shows a requirement as uncovered but we have a policy." The policy is not mapped, or it is not in Published status.
"Comparison shows changes we did not make." Comparison is deterministic on the stored text. Differences usually reflect a formatting or conversion change in the uploaded document.
"Policy Library is not visible." Requires the policy_governance entitlement and policy.read.