What is the difference between documented governance and operational governance in Solvency II?

Documented governance describes the policy, roles, and standards on paper. Operational governance proves those rules were actually used through workflows, approvals, ownership assignment, and audit trails. Solvency II expects the second, because a regulator can challenge a document but cannot accept a process that leaves no evidence.

How documented governance differs from operational governance

Documented governance is the formal control design, the policies, standards, role descriptions, and approval rules written down for the insurer. operational governance is the evidence layer, showing those rules were actually followed in day-to-day work through approvals, delegated ownership, workflow records, and audit trails. In Solvency II, the distinction matters because supervisors test practice, not just paper.

That means a policy can be well drafted and still fail the governance test if the organisation cannot show who approved what, when responsibility changed, or how exceptions were handled. Operational governance turns intent into traceable behaviour, which is what makes board oversight, control execution, and challenge by supervisors credible.

Why Solvency II cares about the operating reality

Solvency II governance expectations are designed to show that the insurer is controlled in practice, not merely described in procedure. The regulatory concern is whether the business has embedded ownership, review, escalation, and control operation into actual processes, so the governance model survives scrutiny when an issue, delegation, or exception occurs.

A documented model may satisfy an internal drafting exercise, but operational governance is what proves the control environment can stand up to examination. For a practitioner, the key difference is that documents define the target state, while operating evidence proves the target state is real. That proof is often found in meeting minutes, approval logs, sign-offs, task ownership, and exception handling records rather than in the policy itself.

Operational governance also matters because it exposes mismatch between design and behaviour. If the policy says approvals are required but workflows bypass them, or if ownership is assigned on paper but never evidenced in production, the organisation has a governance gap even when the documentation looks complete. That gap is usually what supervisors and auditors focus on first.

What practitioners should evidence in practice

Strong operational governance is usually visible in four things: clear ownership, repeatable approvals, controlled exceptions, and durable evidence. The question is not whether those elements exist somewhere in the organisation, but whether they are embedded in ordinary operations and can be reconstructed after the fact.

Ownership assignment should be current, named, and tied to an actual decision path.
Approvals should be time-stamped and linked to the relevant action or change.
Exceptions should be recorded with rationale, expiry, and follow-up ownership.
Audit trails should show the sequence of activity, not just the final outcome.

This is where DORA is a useful reference point for financial firms, because it reinforces the need for operationally demonstrable control, particularly around ICT risk, incident handling, and third-party dependencies. For a governance question like this, the practical lesson is that control design only becomes meaningful when execution is demonstrable.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 sets the technical controls, while DORA, ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.

Framework	Control / Reference	Relevance
DORA	None — Digital Operational Resilience Act	Financial governance must be evidenced through operating controls and resilience processes.
Recommendation — Demonstrate governance through traceable operational controls and incident evidence.
NIST CSF 2.0	GV.OV-01 — Oversight of the Cybersecurity Risk Management Strategy	Distinguishes written oversight from oversight that is actually exercised and monitored.
Recommendation — Verify that oversight decisions are recorded and acted on in operating processes.
ISO/IEC 27001:2022	A.5.1 — Policies for information security	Compares formal policy intent with evidence that controls are operating as described.
Recommendation — Link written policies to operational evidence and review gaps regularly.
SOC 2 (AICPA)	CC1.3 — Commitment to competence	SOC 2 emphasises governance and evidence that control responsibilities are actually performed.
Recommendation — Retain evidence that assigned responsibilities are executed in practice.

Practitioner Guidance

What to verify: Check whether each governance rule can be traced to a real workflow artifact, such as an approval record, ownership register, committee minute, or exception log. If the evidence only exists in a policy library, the governance is still largely documentary.

Common mistake: Treating policy publication as control implementation. In Solvency II reviews, that shortcut usually fails because the regulator wants to see how governance operated during normal business activity, not how it was intended to operate.

Decision rule: If a control cannot be independently reconstructed from operating evidence, treat it as an unproven control even if the document is well written. If the document and the workflow diverge, trust the workflow assessment first and remediate the process, not just the wording.

Practitioner takeaway: For Solvency II, the real test is whether governance leaves a verifiable operational footprint, because evidence of execution carries more weight than elegant documentation.