ORSA software for a governed Solvency II Pillar 2 process.
Turn ORSA from an annual document exercise into a traceable, repeatable compliance process. Connect requirements to risks, policies, controls, owners, decisions and evidence while actuarial systems remain the calculation source.
Turn ORSA from an annual document exercise into a traceable, repeatable compliance process. Sia RegAI helps insurance teams connect regulatory requirements to risks, policies, controls, owners, decisions and evidence—while your actuarial and capital systems continue to produce the underlying calculations.
ORSA is more than a report
Article 45 of the Solvency II Directive requires every insurance and reinsurance undertaking to conduct an own risk and solvency assessment as part of its risk-management system. The assessment must consider the undertaking’s overall solvency needs, risk profile, risk-tolerance limits and business strategy. It must also be integrated into strategic decision-making and repeated following a significant change in the risk profile.
That makes ORSA a governed process, not simply a document delivered once a year.
In practice, the evidence is often scattered across policy documents, spreadsheets, risk systems, actuarial outputs, committee papers and email approvals. When an assumption, scenario, legal requirement or business strategy changes, teams must reconstruct why a decision was taken and which controls or evidence need to be updated.
Sia RegAI provides the regulatory traceability layer around that process.
What Sia RegAI supports
Maintain a current ORSA requirements library
Use RegReview to identify and review relevant requirements from Solvency II, EIOPA material and applicable national supervisory sources. Preserve the source, effective date, interpretation, reviewer and decision so the team can see what was assessed and why.
Match requirements to the operating model
Use RegMatcher to connect each applicable requirement to the policies, risks, controls, committees, reports and evidence that support it. Where no suitable control or evidence exists, record the gap, accountable owner and remediation date.
Coordinate the ORSA cycle
Keep the ORSA policy, annual timetable, ad hoc triggers, input owners, review stages and board approvals in one governed workflow. Make dependencies visible across risk, actuarial, finance, compliance and internal audit.
Preserve review and challenge
Record comments, decisions, approvals and evidence at the requirement or control level. Maintain a defensible history of what changed between ORSA cycles and how the administrative, management or supervisory body challenged and approved the assessment.
Monitor change between reporting cycles
When a regulatory source changes, identify which mapped requirement, policy, control or evidence item may be affected. Route the change to the right owner instead of waiting for the next annual document refresh.
What Sia RegAI does not replace
Sia RegAI is not an actuarial calculation engine. It does not replace the systems used to calculate technical provisions, SCR or MCR, run stochastic models, produce QRTs, or generate accounting entries.
It connects the regulatory requirement and governance process to those systems and their outputs. This boundary matters: Article 45 states that ORSA is not itself a capital-requirement calculation. The value is in connecting the quantitative results with risk appetite, business strategy, management action and documented governance.
A six-stage ORSA workflow
1. Confirm scope and requirements
- Identify the legal entities, branches and group considerations in scope.
- Record applicable Directive, EIOPA and national-supervisor requirements.
- Confirm the current ORSA policy, methodology, frequency and material-change triggers.
- Assign a regulatory owner and qualified reviewer to each requirement set.
2. Map inputs and responsibilities
- Connect material risks, risk appetite and tolerance limits.
- Identify actuarial and capital-model outputs required by the assessment.
- Map business-plan assumptions, strategic initiatives and management actions.
- Assign accountable owners across risk, actuarial, finance, compliance and the board.
3. Assess prospective solvency needs
- Document the base case and planning horizon.
- Link the selected stress and scenario tests to the risk profile.
- Record assumptions, limitations and dependencies.
- Preserve references to the calculation source rather than copying uncontrolled values into another spreadsheet.
4. Review continuous compliance
- Link evidence supporting continuous compliance with capital requirements and technical-provision requirements.
- Record emerging risks, concentrations and risk-profile deviations.
- Identify areas where the standard formula or internal model may not fully reflect the risk profile.
- Assign remediation where evidence or control performance is insufficient.
5. Challenge and approve
- Route the draft assessment to the appropriate reviewers.
- Record questions, challenge and responses.
- Preserve the approval decision and any conditions or follow-up actions.
- Link the approved output to the board or AMSB meeting record.
6. Monitor actions and change
- Convert findings into owned actions with deadlines and evidence requirements.
- Track significant changes that may trigger an ad hoc ORSA.
- Compare requirements, controls and evidence between cycles.
- Maintain a complete audit trail for supervisory review.
ORSA requirements-to-evidence example
| Regulatory expectation | Example operational evidence | Typical owner |
|---|---|---|
| Overall solvency needs reflect the specific risk profile | ORSA methodology, risk inventory, scenario rationale and prospective solvency assessment | CRO / Risk |
| Assessment reflects approved risk-tolerance limits | Risk-appetite statement, limits, breaches and management actions | Risk / Board |
| ORSA informs business strategy | Strategy paper, capital plan and documented board decisions | CFO / Strategy / Board |
| Assessment is regular and follows significant risk-profile changes | ORSA calendar, trigger register and ad hoc assessment decision | Risk / Compliance |
| Results are reported to the supervisor | Approved ORSA supervisory report and submission evidence | Regulatory reporting |
| Decisions and review are governed | Review comments, challenge log, approvals and meeting record | Company secretary / Board |
The precise evidence depends on the undertaking, its proportionality assessment, national supervisory expectations and operating model.
Governance calendar and ad hoc triggers
| Stage | Typical governance activity | Evidence to retain |
|---|---|---|
| Cycle launch | Approve scope, timetable, owners, materiality and methodology changes. | Approved plan, RACI, source list and prior-cycle actions |
| Input collection | Freeze business plan, risk profile, capital-model outputs, assumptions and management actions. | Input register, owner certification and data-quality exceptions |
| Scenario design | Challenge scenario selection, severity, dependencies, reverse stresses and management actions. | Scenario rationale, model references, limitations and approvals |
| Draft assessment | Integrate prospective solvency, continuous compliance and risk-profile conclusions. | Section drafts linked to controlled inputs and findings |
| Challenge | Risk, actuarial, finance, compliance and senior management review the conclusions. | Comments, responses, unresolved issues and decision log |
| Board / AMSB approval | Review, challenge and approve the assessment and required actions. | Board pack, minutes, conditions and approvals |
| Supervisory reporting | Produce and submit the required ORSA supervisory report under the applicable process. | Approved report, submission record and supervisor correspondence |
| Between cycles | Monitor significant risk-profile changes and decide whether an ad hoc ORSA is required. | Trigger register, decision rationale and follow-up actions |
Report generation with source control
Sia RegAI can organise the approved requirement, input reference, scenario conclusion, finding and evidence used to support a report section. Draft narrative may be assisted only from controlled inputs. The insurer’s accountable authors and reviewers remain responsible for the ORSA record and supervisory report.
- Each quantitative statement should reference the approved actuarial or capital-model output and reporting date.
- Each scenario conclusion should retain assumptions, limitations, management actions and reviewer challenge.
- Changes from the prior report should be explainable through a source, risk-profile, methodology or business decision.
- The final approved report, board evidence and submission record should be retained together.
Public product view
Why teams move beyond spreadsheets
Spreadsheets can list requirements, but they struggle to preserve relationships and change over time. An effective ORSA process must connect:
- Requirement to interpretation.
- Interpretation to policy and control.
- Control to evidence and owner.
- Scenario to decision.
- Finding to remediation.
- Regulatory change to impacted process.
- Review to approval history.
Sia RegAI keeps those relationships visible and searchable, so the next ORSA cycle begins with a living control and evidence baseline rather than a blank workbook.
How Sia RegAI supports the ORSA workflow
RegReview can monitor the agreed Solvency II and EIOPA source set, preserve versions and route changed requirements to the relevant risk, actuarial and compliance reviewers. RegMatcher can connect approved interpretations to ORSA policies, controls, owners and evidence, retaining the rationale when the assessment is refreshed.
The platform does not calculate SCR, MCR or scenario results. It supports the governed monitoring and assessment workflow around the actuarial systems and accountable decisions.
Implementation approach
First 30 days: establish the baseline
Import the current requirements, ORSA policy, control inventory and previous assessment findings. Agree the taxonomy, owners, review roles and source hierarchy.
Days 31–60: connect the process
Map requirements to policies, risks, controls, model outputs, reports and evidence. Identify missing or weak links and assign remediation.
Days 61–90: run the governed cycle
Configure the review, challenge, approval and action workflow. Test a material-change scenario and confirm that the team can trace from regulatory source to decision and evidence.
Frequently asked questions
What is ORSA software?
ORSA software helps insurers manage the data, governance, assessment, review, reporting or evidence involved in the own risk and solvency assessment. Products vary significantly: some calculate capital or produce reports, while others govern the requirements, workflow and evidence. Buyers should confirm the precise boundary before selecting a tool.
Does Sia RegAI calculate SCR or MCR?
No. Sia RegAI is designed to manage regulatory requirements, impact, controls, ownership and evidence around the ORSA process. Existing actuarial and capital systems remain the calculation source.
How does ORSA relate to Solvency II Pillar 2?
Pillar 2 covers qualitative requirements such as governance, risk management and ORSA. Article 45 requires ORSA to be part of the risk-management system and integrated into strategic decisions.
Can the platform support an ad hoc ORSA?
It can support the governance workflow by recording the trigger, affected requirements and inputs, assigned reviewers, decision, evidence and follow-up. The actuarial calculations continue in the undertaking’s designated modelling systems.
Can Sia RegAI connect ORSA with DORA?
Where requirements share policies, risks, controls or evidence, the mappings can make that relationship visible. Insurance-specific ORSA requirements should remain distinct; shared evidence should only be reused where it genuinely satisfies both requirements.
Build a traceable ORSA process
See how Sia RegAI can connect your ORSA requirements, controls, owners, evidence and approvals without replacing your actuarial systems.