Policies are useful when they operate.
A policy hierarchy becomes a control system when requirements have stable identity, ownership, trigger conditions, test methods, evidence and an exception path.
Control-system decisions
Make enforceable requirements addressable: stable ID, owner, trigger, test and evidence path.
GRC ownerBefore rolloutTrace procedures and records back to the policy, risk or obligation they serve.
Control ownerFirst control cycleTreat exceptions as decisions with scope, owner, expiry and compensating measures.
Risk ownerRisk-basedGRC programmes often fail at the seam between approved intent and operating behaviour. A policy exists, a procedure exists, and yet the organisation cannot efficiently show whether the intended control happened, under which version, with whose approval, and with what result. More prose does not solve that. Traceability does.
Start with a hierarchy, not a document library
I use layers because governance artefacts change at different rates and serve different decisions: mandate and risk appetite; policies; standards; procedures; checklists or workflows; registers and evidence. This is a design convention, not a universal document taxonomy.
Intent becomes operating evidence.
Mandate & appetite
Charter, scope and risk decisions.
→Policy & standard
Durable control objectives and baselines.
→Procedure
Triggers, decision gates and owner actions.
→Execution layer
Instructions, plans and critical checklists.
→Evidence & assurance
Registers, test results and exception records.
→How to read the diagram. The layers show traceability from durable governance intent toward increasingly operational artefacts and evidence. A lower layer should be able to point to the higher-level requirement or risk decision it implements. Feedback must also travel upward when testing, incidents or exceptions show that the requirement is ineffective.
What it does not claim. The figure does not mean that every organisation needs seven document classes, that lower levels are less important, or that ISO/IEC 27001 mandates this hierarchy. An organisation can merge layers if ownership, versioning, traceability and evidence remain clear.
Make requirements addressable
Long prose is useful for rationale but weak as an operating interface. For requirements that are intended to be enforced or tested, I prefer a stable identifier plus owner, scope, trigger or cadence, test method, expected evidence and exception path. A machine-readable representation can add thresholds and enforcement logic where the requirement is deterministic.
Stable IDs make requirements addressable across tickets, repositories, dashboards, automated checks and audit samples. This is a practical architecture pattern. It should not be confused with a claim that regulation requires policy-as-code.
Build the control object
A useful control object links business purpose to operation. Depending on context it can include the risk or obligation addressed, control type, accountable and responsible roles, trigger, inputs, decision threshold, evidence produced, retention rule and exception route. This makes weak controls easier to identify: a “quarterly review” with no owner, population, acceptance criterion or retained result is difficult to test.
Objective and scope
Risk, obligation, assets, population, roles and constraints.
Operation
Trigger, method, thresholds, approvals, segregation and escalation.
Evidence
Timestamped result, artefact reference, exception or corrective action.
Diagram note. INPUT-LOGIC-OUTPUT is a conceptual control interface, not a definition of “control” from ISO. It is most useful for controls that can be sampled or tested. Cultural, strategic or judgement-heavy controls may not reduce cleanly to deterministic logic.
Evidence is part of control design
Evidence is stronger when generated by the work itself and tied to a source, time, version, owner and interpretation. Configuration snapshots, approvals, pull-request records, monitoring results, access reviews and recovery tests become more useful when they can be traced to the requirement and control they support.
ISO/IEC 27001:2022 establishes requirements for an information security management system and risk-based controls. NIST SP 800-53 Rev. 5 provides a large control catalogue with assessment-relevant structure. ISO/IEC 42001:2023 applies a management-system approach to AI. These sources support disciplined control management and documented information. They do not require my particular data model.
Exceptions are governance data
An exception is not evidence that a control failed. It is a decision to operate outside a normal requirement under stated conditions. A useful exception record therefore needs scope, rationale, approving authority, residual risk, compensating measures, expiry and reassessment trigger. Chat approval without those properties is difficult to govern later.
Claim boundaries
- Established: risk-based management systems require defined responsibilities, controlled processes and evidence/documented information appropriate to their scope.
- Supported: stable identifiers and traceable evidence make control testing and impact analysis easier in software-heavy environments.
- Hypothesis: representing requirements and controls as structured objects can reduce audit reconstruction effort and enable safer automation.
- Not claimed: that all policies should become code, all controls can be deterministic, L0-L6 is a standard, or this architecture by itself establishes compliance.
Limitations
Machine readability can create false precision. Some obligations depend on legal interpretation, professional judgement or organisational context. Excessive atomisation can make policy unreadable and create maintenance cost. Evidence can be complete yet still prove the wrong control objective. The model therefore needs periodic review at both semantic and technical levels.
It should be simplified where a conventional policy, procedure and record set already provides clear ownership, reliable testing and low-cost traceability. Structure is useful only when it reduces ambiguity or operating cost.
Evidence notes
- E1: ISO/IEC 27001:2022 supports risk-based ISMS governance and control selection; it does not define L0-L6.
- E2: NIST SP 800-53 Rev. 5 is a control catalogue and control-management antecedent; it does not require a policy-as-code architecture.
- E3: ISO/IEC 42001:2023 supports an AI management system and continual improvement where AI governance is in scope.
- E4: The structured control object, stable-ID convention and hierarchy are implementation synthesis based on operational GRC practice and require empirical validation.
- Reassessment trigger: material standards revisions, repeated maintenance overhead, inability to map judgement-heavy controls, or evidence that structured representation does not improve testing or change impact analysis.
Authoritative references
Bridge to responsibility and agents
The Blockchain Responsibility Model asks who owns a risk across distributed layers. This policy architecture asks how that owner turns responsibility into an operable and evidenced control. The Agentic GRC model then asks which parts of that control loop can be automated without losing authority or provenance. These are complementary models, not standards mappings.