Solvency II Software: A Pillar 2 Buyer's Guide

Search for Solvency II software and you will get three completely different kinds of product dressed in the same words. One vendor sells an actuarial capital engine. Another sells a reporting tool that spits out XBRL returns for the regulator. A third sells a governance and compliance platform that keeps your board, your policies, and your key functions in order. All three legitimately call themselves Solvency II software. None of them does the other two jobs. If you buy the wrong category, you either overpay for capability you will never use or you discover a gap three weeks before a supervisory review.

This guide is written for the person who actually owns the buying decision on the governance side: the CRO, the Head of Risk, the Head of Compliance, or a key-function holder at an EU insurer or reinsurer. It explains the categories in plain language, tells you what to look for in the governance layer specifically, and shows how the right tooling removes duplicate work if you are already running DORA, NIS2, or ISO 27001. It is deliberately scope-honest, because the fastest way to lose credibility with a supervisor is to claim a tool does something it does not.

What Solvency II actually requires, in three pillars

Solvency II is the EU prudential regime for insurers and reinsurers, built on Directive 2009/138/EC and the Delegated Regulation (EU) 2015/35, with detailed EIOPA guidelines layered on top. It is organised into three pillars, and the pillar you are in determines which software you need.

• Pillar 1 - quantitative requirements. The capital math: the Solvency Capital Requirement (SCR), the Minimum Capital Requirement (MCR), technical provisions, and the standard formula or internal model that produces those numbers. This is the domain of actuarial and capital-modelling software.
• Pillar 2 - system of governance. The qualitative requirements set out in Articles 40 to 49 of the Directive: board (AMSB) responsibility, written policies, the risk management system, the ORSA as a process, the four key functions, fit and proper, remuneration, and outsourcing. This is the domain of governance and GRC software.
• Pillar 3 - reporting and disclosure. The Quantitative Reporting Templates (QRTs), the Solvency II XBRL returns, the SFCR and RSR narratives. This is the domain of regulatory reporting software.

Most of the confusion in the market comes from buyers who type "Solvency II software" expecting one product and finding vendors from all three pillars competing for the click. The rest of this guide focuses on Pillar 2, because that is where the governance buyer lives, and because it is the pillar most often under-tooled. Firms spend heavily on the capital engine and the QRT tool, then run the entire system of governance on a shared drive full of Word documents and a spreadsheet of key-function holders.

The three categories of Solvency II software

1. Actuarial and capital modelling (Pillar 1)

These platforms calculate the SCR and MCR, value technical provisions, run the standard formula or a full or partial internal model, and stress-test the balance sheet. They are the mathematical heart of the regime. If you need to produce the capital number, you need one of these, and no governance tool replaces it. Buyers evaluate these on model accuracy, computational performance, scenario flexibility, and audit trail over the calculation itself.

2. QRT and XBRL regulatory reporting (Pillar 3)

These platforms take the numbers from your actuarial engine and your ledgers and format them into the QRTs, validate them against EIOPA's taxonomy, and produce the XBRL instance documents you file with your national supervisor. They handle the SFCR and RSR narrative reporting too. Buyers evaluate these on taxonomy coverage, validation rule completeness, filing workflow, and how quickly the vendor ships each new EIOPA taxonomy release.

3. Governance and GRC (Pillar 2)

This is the layer that manages the system of governance: the controls, the written policies, the board and committee oversight, the ORSA as a governed process, the four key functions, fit and proper assessments, remuneration governance, and outsourcing registers. This is where Solvency II governance software like Venvera sits. It does not calculate your SCR and it does not file your QRTs. It complements your actuarial engine and your XBRL reporting tool by proving that the organisation running those tools is properly governed, controlled, and documented.

Being explicit about this boundary matters. A governance platform that claimed to produce capital numbers or file XBRL returns would be misrepresenting itself, and a supervisor would find that out fast. The honest position is that the three categories are complementary. You will very likely own one product from each pillar.

Inside Pillar 2: what governance software has to cover

The system of governance is not a single deliverable. It is a standing set of obligations that a supervisor can test at any time. Good Solvency II software turns each of these obligations into something structured, owned, evidenced, and reviewable rather than a document that was last touched eleven months ago. The core areas map directly to the Directive.

Requirement	Legal basis	What the software manages
Board (AMSB) responsibility	Art 40	Ultimate accountability, oversight records, sign-offs
Fit and proper	Art 42	Assessments and re-assessments of key persons
Risk management system	Art 44	Risk strategy, appetite, policy set, review cadence
ORSA (as a process)	Art 45	Board workflow, documentation, policy, sign-off trail
Internal control and compliance function	Art 46	Control library, compliance monitoring plan
Internal audit function	Art 47	Independence, audit plan, findings tracking
Actuarial function	Art 48	Function governance, opinions, reporting to the board
Outsourcing	Art 49	Register, criticality, ICT outsourcing overlap with DORA

Venvera's Solvency II module covers this Pillar 2 surface with 45 controls mapped to those articles, the Delegated Regulation, and the EIOPA Guidelines on the System of Governance. The point of counting controls is not the number. It is that every obligation has a home, an owner, a piece of evidence, and a review date, instead of living in someone's memory.

The ORSA is a process, not a number

The Own Risk and Solvency Assessment (Article 45) is the single most misunderstood item when people shop for Solvency II software. The ORSA has a quantitative output, the forward-looking assessment of overall solvency needs, and that number comes from your actuarial and capital modelling. Governance software does not produce it, and any tool that claims to is overreaching.

What governance software does own is the ORSA as a process. That means the ORSA policy, the annual and ad-hoc trigger workflow, the assignment of who does what, the evidence that the board actually challenged and approved the assessment, the version history of the ORSA report, and the audit trail that shows the process ran the way the policy says it should. Supervisors do not just want the ORSA number. They want proof that the ORSA is embedded in decision-making and genuinely owned by the board. That proof is a governance artefact, and it is exactly what the governance layer captures.

So the clean division of labour is this: your capital engine computes the solvency needs, and your governance platform proves the process around that computation was properly run, documented, challenged, and signed off. Both are needed. Neither replaces the other.

The crosswalk: stop evidencing the same governance twice

Here is the insight that changes the economics of Pillar 2 for most EU insurers. If you are a mid-size or larger insurer, you are almost certainly already subject to other EU regimes with heavy governance requirements. The Digital Operational Resilience Act (DORA) has been applying to financial entities since January 2025. Many insurers hold ISO 27001. Plenty fall under NIS2. Each of those regimes demands governance controls that overlap heavily with Solvency II Pillar 2: organisational structure, segregation of duties, records management, ICT and third-party outsourcing oversight, incident governance, and board accountability.

Without a crosswalk, you evidence each of these separately, once per framework, in a different tool or folder, reviewed on a different cadence. That is duplicated work, duplicated review fatigue, and duplicated risk of drift when one copy is updated and the others are not. The crosswalk approach maps a single piece of evidence to every framework it satisfies. Prove your ICT outsourcing governance once for DORA, and the overlapping Solvency II Article 49 governance control is auto-satisfied from that same evidence. Evidence once, compliant everywhere.

The discipline that makes this honest rather than a compliance shortcut is knowing what must never be auto-satisfied. Overlapping governance controls, the org-structure, segregation, records, and ICT-outsourcing kind, can legitimately be reused because they genuinely are the same control viewed through two regimes. But the insurance-specific controls are native and must be evidenced directly: the ORSA, the four key functions including the actuarial function, and fit and proper. There is no DORA or ISO evidence that satisfies "the actuarial function issued its opinion on the technical provisions." Pretending otherwise would create fake coverage, and fake coverage is worse than no coverage because it hides the gap. Good Venvera's Solvency II Pillar 2 module draws that line explicitly.

The four key functions

Solvency II mandates four key functions, and Pillar 2 software has to track each as an independent, properly staffed, properly reporting function rather than a name in an org chart.

• Risk management function (Art 44). Owns the risk management system, the risk appetite framework, and the integration of risk into decision-making.
• Compliance function (Art 46). Advises the board on compliance, assesses the impact of legal changes, and runs the compliance monitoring plan.
• Internal audit function (Art 47). Provides independent assurance over the whole system of governance, including the other functions. Independence is the control that gets tested.
• Actuarial function (Art 48). Coordinates technical provisions, opines on underwriting policy and reinsurance adequacy, and reports to the board. This one is insurance-specific and native to the governance layer, never auto-satisfied from another framework.

The software job here is to hold, for each function, the holder and their fit-and-proper status, the reporting lines that prove independence, the function's activities and outputs, and the evidence that it reported to the board on schedule. When a supervisor asks "show me your actuarial function reported to the board in the last cycle," the answer should be two clicks, not a two-day document hunt.

What to look for when you buy governance software

Once you have established that you are shopping in the Pillar 2 category, use this checklist to separate serious platforms from generic GRC tools with a Solvency II label bolted on.

Native Solvency II control mapping

Controls should map to specific articles of Directive 2009/138/EC, the Delegated Regulation (EU) 2015/35, and the EIOPA guidelines, not to a vague "insurance" template. If the vendor cannot show you the article-level mapping, the content is generic.

A real cross-framework crosswalk

Ask how the tool handles overlap with NIS2, ISO 27001 and DORA. A genuine crosswalk reuses shared governance evidence and clearly refuses to auto-satisfy insurance-specific controls. If everything is "auto-satisfied," walk away, that is fake coverage.

ORSA and key-function workflows out of the box

The ORSA process, fit-and-proper assessments, and the four key functions should be first-class features, not something you assemble from generic tasks. This is what distinguishes insurance-native software from a rebadged general GRC platform.

Board and committee evidence, with an audit trail

Sign-offs, review dates, version history, and immutable evidence that oversight actually happened. Supervisors test embedding, not intention.

EU data residency and honest scope

Your governance data should stay in the EU. And the vendor should tell you plainly what the product does not do, that it complements rather than replaces your actuarial engine and your QRT reporting tool. A vendor who overclaims on scope will cost you credibility in front of your supervisor.

Building your Solvency II software stack

For most insurers the answer is not one tool, it is a stack with clean boundaries. A typical, honest architecture looks like this:

• Actuarial and capital engine (Pillar 1) produces the SCR, MCR, and technical provisions.
• QRT and XBRL reporting tool (Pillar 3) validates and files the returns and produces the SFCR and RSR.
• Governance and GRC platform (Pillar 2) manages the system of governance, the ORSA process, the key functions, fit and proper, and outsourcing, and reuses overlapping governance evidence from DORA and ISO through the crosswalk.

Each layer feeds the others. The capital engine gives the ORSA process its number. The governance layer proves the process around both the capital work and the reporting was properly run. The reporting tool files the output. Nobody pretends to do a neighbouring pillar's job, and that honesty is what holds up under supervisory scrutiny.

If you are already carrying NIS2, DORA, or ISO 27001 obligations, the governance layer is where the biggest efficiency gain hides. The overlapping controls you have already evidenced for those regimes can carry across, so the incremental work to stand up Pillar 2 is concentrated on the genuinely insurance-specific pieces: the ORSA process, the four key functions, and fit and proper. That is the difference between a Solvency II governance programme that takes months and one that reuses what you already have.

The bottom line

Solvency II software is three markets wearing one name. Know which pillar you are buying for. If you already own an actuarial engine and a QRT tool, the gap is almost always Pillar 2, the system of governance, and that gap is usually being filled by shared drives and spreadsheets that will not survive a supervisory review. A purpose-built governance platform closes that gap, and a real cross-framework crosswalk closes it without making you evidence the same governance three times over. Just make sure the vendor is honest about the boundary: it complements your capital and reporting tools, it does not replace them.