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

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.

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.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?