Appearance
Policy Operationalization & Traceability
Where to find it: Policy Governance, then Operationalization (/governance/operationalization), or select any policy and click the Operationalization tab (/governance/policy/:pid/operationalization).
Policy Operationalization is the discipline that connects corporate policy intent to living operating controls, systems, and evidence. It prevents corporate policies from remaining shelfware by decomposing policies into atomic statements and mapping each statement to its operational mechanisms.
Requires the policy_governance entitlement.
The Atomic Statement: The Unit of Governance
Traditional GRC systems map entire multi-page policy PDFs to regulatory clauses. This produces coarse, unverifiable relationships.
OrviQ decomposes policies into Atomic Statements (PST-YYYY-NNNN):
- Each statement represents a single, indivisible governance requirement (e.g., "All production database backups must be encrypted at rest using AES-256").
- Statements carry their own unique identifier, statement key, operationalization status, and forward/reverse linkage.
- When an atomic statement is operationalized, it connects directly to the operating objects that execute and substantiate it.
Operationalization Target Types
An atomic statement can be mapped to 10 distinct operational GRC object types:
| Target Type | Target Reference | Supported Relationship Types |
|---|---|---|
| Control | CTL-YYYY-NNNN | PRIMARY, SUPPORTING, COMPENSATING |
| Requirement | REQ-... | Direct regulatory obligation mapping |
| Evidence Expectation | EXP-... | EXPECTS_EVIDENCE (documentary, operational, technical, attestation) |
| Risk | RSK-YYYY-NNNN | ADDRESSED_BY, ARISING_FROM_GAP |
| Owner | User / Role / OrgUnit | ACCOUNTABLE_OWNER, IMPLEMENTATION_OWNER, SUPPORTING_ROLE |
| Scope & Asset | SCP-... / AST-... | IN_SCOPE, EXCLUDED_SCOPE, PARTIALLY_IN_SCOPE |
| Task / Action | ACT-YYYY-NNNN | IMPLEMENTATION_ACTION, PERIODIC_ACTIVITY, CORRECTIVE_ACTION |
| Metric / Indicator | IND-... / KRI-... | KRI, KCI, OPERATIONAL_METRIC |
| Finding / Gap | FND-... / GAP-... | DEFICIENCY, GAP_REMEDIATION |
| Exception | EXC-YYYY-NNNN | Linked active governed deviation |
Operationalization Status Vocabulary
Each statement and parent policy evaluates to one of four deterministic operationalization states:
| Status Code | Display Label | Criteria |
|---|---|---|
NOT_MAPPED | Not Mapped | The statement has no operational linkages configured. It exists solely as written policy text. |
PARTIALLY_OPERATIONALIZED | Partially Operationalized | The statement has an owner or control mapped, but lacks necessary evidence expectations, scopes, or monitoring indicators. |
OPERATIONALIZED | Operationalized | The statement is fully substantiated: it has an accountable owner, primary operating control, defined evidence expectation, and in-scope asset population. |
GAP_IDENTIFIED | Gap Identified | The statement is associated with an active, unresolved deficiency in the Gap Workbench or Findings Register. |
Forward and Reverse Traceability
The operationalization graph enables immediate bi-directional navigation across the governance architecture:
Forward Traceability (Top-Down)
$$\text{Regulation} \longrightarrow \text{Requirement} \longrightarrow \text{Policy Statement} \longrightarrow \text{Control} \longrightarrow \text{Evidence Assertion}$$ Use case: An auditor asks: "How does the bank enforce Requirement 4.2 of the SBP Cybersecurity Framework?"
Forward traceability traverses from the requirement to the exact atomic policy statement, the control implementing it, and the daily evidence assertion proving its execution.
Reverse Traceability (Bottom-Up)
$$\text{Evidence Assertion} \longrightarrow \text{Control} \longrightarrow \text{Policy Statement} \longrightarrow \text{Requirement} \longrightarrow \text{Board Policy}$$ Use case: A vulnerability scanner detects an unpatched server.
Reverse traceability shows which control is degraded, which atomic policy statements are implicated, which corporate policies are affected, and which regulatory obligations are exposed to scrutiny.
Semantic Doctrine & Invariants
Semantic Doctrine: Traceability != Compliance or Effectiveness
OrviQ enforces strict architectural invariants to prevent false claims of security or compliance:
- Traceability != compliance or effectiveness: Establishing complete structural linkage between a policy statement, a control, and a regulation demonstrates design architecture. It does not certify that the control operates effectively or that the organization is compliant.
- Policy mapped != Policy operationalized: Linking a policy statement to a control name is a preliminary step; operationalization requires assigned owners, declared scopes, and verified evidence expectations.
- Control mapped != Control effective: A control may be mapped to five policy statements and yet fail its operational tests.
- Evidence existing != Control effective: The existence of fresh evidence records observations; control effectiveness is determined by indicator threshold rules and human assurance review.
- Exception present != Requirement satisfied: An approved exception records a governed deviation; it does not satisfy the underlying obligation.
Permissions Reference
| Action | Permission Key | Required Role(s) |
|---|---|---|
| View policy operationalization and traceability graphs | policy.read | All roles |
| Create, update, or remove operational mappings | policy.operationalize | Tenant Admin, Compliance Manager, Compliance Officer |
| Author and edit atomic policy statement definitions | policy.write | Tenant Admin, Compliance Manager, Compliance Officer |