Insurance Solvency 2 Software: One Governance Record

Most conversations about insurance Solvency 2 software start in the wrong place. They start with capital: the Solvency Capital Requirement, the Minimum Capital Requirement, technical provisions, the internal model. That is Pillar 1, and it is genuinely hard quantitative work. But it is not where EU insurers and reinsurers are getting caught by supervisors, and it is not where the tooling gap lives. The gap is Pillar 2, the System of Governance, and it is under-served precisely because it looks like paperwork until an EIOPA-driven national supervisory review, a peer review, or an on-site inspection turns it into a live evidence exercise.

This article is about that governance layer. It is aimed at the Chief Risk Officer, the Head of Compliance, and the four key-function holders who carry personal responsibility under Directive 2009/138/EC. The argument is simple: the System of Governance should be run as one live system of record, not a folder of Word documents refreshed once a year for the board pack. And because the governance requirements of Solvency II, NIS2, GDPR, ISO 27001 and DORA overlap heavily, the right insurance Solvency 2 software treats that overlap as an asset, evidencing a control once and reusing it everywhere it is relevant.

The three pillars, and who actually owns them inside a (re)insurer

Solvency II is a three-pillar prudential regime. Confusion about tooling almost always comes from collapsing the three pillars into one procurement decision. They are owned by different people, evidenced in different ways, and served by different software. Being precise about this is the first thing any honest insurance Solvency 2 software vendor should do.

Pillar	What it covers	Internal owner	Tool that serves it
Pillar 1	Quantitative: SCR, MCR, technical provisions, own funds, the standard formula or internal model	Chief Actuary and the actuarial team	Actuarial and capital modelling engine
Pillar 2	Qualitative: System of Governance, risk management system, ORSA process, the four key functions, fit and proper, remuneration, outsourcing	CRO, Head of Compliance and the key-function holders	Governance and compliance system of record
Pillar 3	Reporting and disclosure: QRTs, the SFCR, the RSR, Solvency II XBRL returns	Finance and regulatory reporting	QRT and XBRL reporting tool

Be blunt about the boundaries, because pretending otherwise loses enterprise trust. Venvera does not calculate the SCR or MCR, does not build technical provisions, and does not file QRTs or generate Solvency II XBRL. That work stays in your actuarial engine and your regulatory reporting stack, and it should. What Venvera's Solvency II Pillar 2 module does is run the governance layer, the qualitative half of the regime that sits between the numbers people and the reporting people and, in most insurers, is the least well-tooled of the three.

Why Pillar 2 is the under-served gap

Pillar 1 has a mature software market because the maths demands it: you cannot run a partial internal model on a spreadsheet forever. Pillar 3 has a mature market because XBRL taxonomies and validation rules are unforgiving and change with every EIOPA release. Pillar 2 fell into the gap. It reads like prose in the Directive, so firms treated it like prose: policies drafted in Word, approvals recorded in board minutes, evidence scattered across email, SharePoint and shared drives, and an annual scramble to reassemble it all before the supervisor asks.

That approach fails the moment governance becomes a live inquiry rather than a document. When a supervisor asks who approved the current version of the underwriting risk policy, when it was last reviewed, which board meeting ratified it, and how it connects to the risk management system under Article 44, a folder of documents cannot answer in the room. A system of record can. This is the core case for treating insurance Solvency 2 software as a governance operating system rather than a document repository.

The System of Governance, mapped to the articles

The System of Governance is defined across Articles 40 to 49 of the Directive, elaborated in the Delegated Regulation (EU) 2015/35, and detailed in the EIOPA Guidelines on the System of Governance. Venvera's Pillar 2 module covers this ground as 45 discrete controls, each mapped to the article it satisfies. The structure is worth walking through, because it is exactly the structure a supervisor uses.

• Administrative, management or supervisory body (AMSB) responsibility. The board owns the System of Governance. Every policy needs a defined approval and review cadence, and the trail of who approved what, when, has to be reconstructable on demand.
• Written policies. Risk management, internal control, internal audit, outsourcing and more, each reviewed at least annually and after any significant change, with version history intact.
• Risk management system (Article 44). A functioning system covering underwriting, asset-liability management, investment, liquidity, concentration, operational and reinsurance risk, connected to strategy rather than sitting beside it.
• Own Risk and Solvency Assessment (Article 45). The ORSA as a governed process, discussed below.
• Internal control and compliance function (Article 46). Documented control environment plus a compliance function that advises the board and assesses regulatory change.
• Internal audit function (Article 47). Independent and objective, reporting findings to the AMSB.
• Actuarial function (Article 48). Covered as a governance deliverable, discussed below.
• Fit and proper (Article 42). Assessment and ongoing monitoring of everyone who effectively runs the undertaking or holds a key function.
• Remuneration and outsourcing (Article 49). Remuneration policy aligned to sound risk management, and outsourcing (including intra-group and ICT outsourcing) governed end to end.

Holding all 45 controls in one place, each with its owner, its status, its evidence and its link to the underlying article, is what turns the System of Governance from an annual artefact into a living system. This is the practical meaning of Solvency II governance software.

The ORSA as a process, not a number

The ORSA is where the pillar boundaries get blurred most often, so it deserves care. The Own Risk and Solvency Assessment under Article 45 has a quantitative output, the overall solvency needs figure, and that number is produced by your actuarial and capital modelling engine. Insurance Solvency 2 software on the governance side does not, and should not, calculate it.

What the governance layer owns is the ORSA as a process. That means the ORSA policy and its board approval, the schedule and trigger events for running an ad hoc ORSA after a material change in risk profile, the scenario and stress-testing framework as a documented methodology, the roles and responsibilities of everyone involved, the challenge and sign-off by the AMSB, and the ORSA record and supervisory report as controlled documents with a full audit trail. The number comes from the actuarial engine; the process, the governance, the evidence and the board workflow live in Venvera. Keeping that line clean is not a limitation, it is honesty about where value is added and where the actuarial team rightly stays in charge.

The four key functions, and why the actuarial function is a governance deliverable

Solvency II mandates four key functions: risk management, compliance, internal audit and actuarial. Each must be effective, adequately resourced, free from conflicts of interest, and headed by a person who is fit and proper. In practice these are the controls supervisors probe hardest, because they are what makes governance real rather than nominal.

For each function, insurance Solvency 2 software should track the function holder and their fit and proper assessment, the reporting line and evidence of independence, the mandate or terms of reference, and the periodic reports the function delivers to the board. The actuarial function under Article 48 is the clearest illustration of the governance-versus-numbers distinction. The technical provisions calculation, the assessment of data quality, the opinion on the underwriting policy and the reinsurance arrangements: those calculations belong to the actuarial team and their modelling tools. What the governance layer captures is the actuarial function report to the AMSB as a controlled deliverable, the independence and fit and proper status of the function holder, the mandate, and the evidence that the function is resourced and effective.

This is why these insurance-specific controls, the ORSA, the four key functions and fit and proper, are native to Venvera. They are evidenced directly by the people who own them, never auto-satisfied from another framework. There is no honest way to infer that your actuarial function is effective from your ISO 27001 certificate, and any tool that claims to is setting you up to fail a review.

The DORA overlap: evidence once, compliant everywhere

Here is the part that changes the economics for a (re)insurer that is already doing NIS2, GDPR, DORA or ISO 27001. A large slice of the System of Governance is governance in the general sense: organisational structure, segregation of duties, records management, the four eyes principle, and the governance of ICT and outsourcing arrangements. Those same requirements appear, in near-identical form, across the other regimes an EU insurer is already subject to.

DORA, the Digital Operational Resilience Act, is the sharpest example. DORA demands a board-owned ICT risk management framework, governed ICT third-party arrangements, and a register of information on outsourcing. Solvency II's outsourcing requirements under Article 49, and its expectations on the governance of ICT and operational risk, overlap with that directly. If you have already evidenced your ICT outsourcing governance for DORA, the overlapping Solvency II governance control should be auto-satisfied from that same evidence rather than re-collected from scratch. The same holds for ISO 27001 organisational controls, NIS2 governance obligations, and GDPR accountability and records requirements.

This is the cross-framework crosswalk, and the principle is evidence once, compliant everywhere. The discipline that makes it trustworthy is the line drawn earlier: only genuinely overlapping governance controls are auto-satisfied. Insurance-specific controls stay native. You get the efficiency of reuse on the shared governance surface without any fake coverage on the controls that are unique to insurance. For a CRO staring at overlapping NIS2, Solvency II and DORA programmes, this is the difference between three parallel evidence exercises and one.

Solvency II governance area	Reused from	Native or auto-satisfied
Organisational structure and segregation of duties	ISO 27001, NIS2, DORA	Auto-satisfied
ICT and operational outsourcing governance	DORA third-party register	Auto-satisfied
Records management and accountability	GDPR, ISO 27001	Auto-satisfied
ORSA process	None	Native
Four key functions and actuarial function report	None	Native
Fit and proper	None	Native

One live system of record, not four parallel programmes

Bring the pieces together and the operating model changes. Instead of a Solvency II governance programme running in isolation from the DORA programme running in isolation from the ISO 27001 programme, you get one system of record where a single piece of evidence, say the board-approved outsourcing policy or the segregation-of-duties matrix, is attached once and counts against every framework that requires it. The CRO sees a single control inventory. The compliance function sees regulatory change once and assesses its impact across frameworks together. The board sees one coherent governance picture instead of four disconnected assurance streams.

This matters most under time pressure. When a national supervisor sends a request for information, or EIOPA-driven scrutiny lands, the question is never "do you have a policy". The question is who owns it, when it was last reviewed, which board meeting approved it, what evidence supports it, and how it connects to the risk management system. A live system of record answers in minutes. A folder of documents answers in a fortnight of chasing, if at all.

What to look for when you evaluate insurance Solvency 2 software

If you are a CRO, Head of Risk, Head of Compliance or a key-function holder evaluating tools for the governance layer, a short checklist keeps the conversation honest:

• Does it stay in its lane? A credible Pillar 2 tool complements your actuarial engine and your QRT and XBRL reporting tool. It should never claim to compute the SCR or file returns. Overreach here is a red flag.
• Are the 45 governance controls mapped to the articles? Each control should trace to Articles 40 to 49, the Delegated Regulation and the EIOPA Guidelines, so a supervisor can follow the logic.
• Does it treat the ORSA as a process? Policy, schedule, triggers, scenario methodology, board challenge and the controlled ORSA record, without pretending to own the number.
• Are the four key functions first-class? Function holders, fit and proper, independence and periodic board reports, with the actuarial function handled as a governance deliverable.
• Is the crosswalk honest? Genuine governance overlap with NIS2, GDPR, ISO 27001 and DORA is reused; insurance-specific controls stay native and are never auto-satisfied.
• Is data resident in the EU? For an EU (re)insurer this is not optional.

The governance layer has been the quiet gap in the Solvency II software market for years, sitting between the well-tooled quantitative work of Pillar 1 and the well-tooled reporting of Pillar 3. Treating it as a live system of record, wired into the ISO 27001 and DORA evidence you already produce, is how a modern (re)insurer runs the System of Governance without drowning in duplicated effort.