Supervisory pressure in insurance: a threat or an opportunity to regain control over data and risk?

In this article, we analyze where organizations lose control over data and processes, and what approach makes it possible to move from reactive “getting it over the line” to a stable operating model for data and risk management.

What you should know:

• Supervisory assessment is shifting from outcomes to processes. What increasingly matters is whether an insurer can reconstruct how a result, decision, or report was produced, including the data, assumptions, and dependencies involved.
• Manual reconciliations are not a neutral “buffer” but a source of risk. Each adjustment made outside core systems and operational processes weakens data consistency, lengthens organizational response times, and makes it harder to defend positions before supervisors.
• Most issues arise at the intersection of organizational domains rather than within individual teams. The root cause is not the regulatory requirements themselves, but the lack of a shared approach to data and processes that connect risk, finance, operations, and IT.

DORA: operational resilience in practice, not on paper

DORA applies to insurance undertakings from January 2025 and—like in other segments of the financial sector—does not introduce a formal transition period. This does not mean a purely binary approach, however. From the moment the regulation enters into force, supervisory focus gradually shifts from the mere existence of policies and procedures to the extent to which operational resilience mechanisms actually function in practice.

The regulation moves the emphasis from declarative ICT risk management to a real ability to maintain continuity of critical insurance services: policy sales and servicing, claims handling, benefit payments, and settlements with reinsurers and external partners.

DORA applies to insurance undertakings from January 2025 and—like in other segments of the financial sector—does not introduce a formal transition period. This does not mean a purely binary approach, however. From the moment the regulation enters into force, supervisory focus gradually shifts from the mere existence of policies and procedures to the extent to which operational resilience mechanisms actually function in practice.

The regulation moves the emphasis from declarative ICT risk management to a real ability to maintain continuity of critical insurance services: policy sales and servicing, claims handling, benefit payments, and settlements with reinsurers and external partners.

What does DORA actually require from insurers?

DORA changes the approach to operational resilience. An insurance undertaking must be able to:

• clearly identify critical business services and customer-facing processes,
• understand which systems, data, and ICT providers support those services,
• quickly assess the impact of an ICT incident on customers, operational continuity, and reputation,
• provide consistent and reliable information to management and supervisors within a short timeframe.

This represents a shift from reacting to incidents after the fact to deliberate, data-driven operational resilience management, rather than relying on fragmented inputs from different teams.

Where are insurers weakest today?

The most common weaknesses exposed by DORA are well known, yet difficult to eliminate sustainably:

• lack of a single, coherent view of critical insurance services and their dependencies on IT systems and providers,
• fragmented information on incidents, operational events, and security,
• weak linkage between a technical incident and its actual impact on customers and business processes,
• limited control over external providers (outsourcing, cloud, TPAs) and their impact on business continuity.

As a result, insurers often know that an incident has occurred but are unable to quickly assess its effect on claims handling, benefit payments, or ongoing customer service.

What should be done next?

An effective response to DORA requires building a coherent operational resilience architecture:

• Business service mapping – a clear linkage between critical insurance services and the systems, data, and providers that support them, enabling rapid impact assessment.
• Central data integration layer – integration of data from policy, claims, ITSM, monitoring, security, and vendor registers into a consistent information model.
• Incident management with a business perspective – correlation of technical events with insurance processes, combined with automated escalation and reporting.
• ICT vendor risk management – assessment of providers through the lens of their relevance to key services and continuity scenarios.
• Operational resilience reporting – consistent, automated reporting for management and supervisors based on operational data rather than manual compilations.

Related article:

• 

  Why FiDA Is an Opportunity, Not a Cost: A Business Perspective

  7 min reading

IFRS 17: when policy data, actuarial, and finance must speak with one voice

Although IFRS 17 has formally applied since 2023, for many insurers it remains an area of ongoing operational pressure rather than a “closed” regulation. The standard is subject to regular audit reviews and supervisory scrutiny, and any change in input data, actuarial assumptions, or operational processes can quickly affect financial results and equity.

IFRS 17 has changed how insurance reporting is viewed: it is no longer the domain of a single team but a cross-functional process connecting policy systems, claims handling, actuarial, finance, and management reporting. It is precisely at these intersections that issues with data consistency and explainability most often emerge.

What does IFRS 17 actually require from insurers?

IFRS 17 requires an insurance undertaking to be able to explain, in a consistent and credible manner, the financial result generated by its insurance portfolio.

In practice, this means the ability to:

• maintain consistent, granular policy and claims data,
• apply repeatable and well-documented calculations of cash flows, CSM, and the risk adjustment for non-financial risk (RA),
• clearly link actuarial data with accounting entries,
• explain why results changed between periods and which factors drove those changes.

The key question asked today by auditors and supervisors is no longer “was the report produced?” but rather: can you clearly explain where these numbers came from?

Where are insurers weakest today?

The most common IFRS 17-related issues include:

• lack of a single, coherent view of policy, claims, and financial data,
• discrepancies between source systems and results reported in the general ledger,
• manual adjustments and overrides at the final stage of the process,
• limited explainability of changes in CSM and results between periods,
• heavy reliance on the expert knowledge of a few individuals.

As a result, insurers can generate the report but struggle to defend it convincingly in discussions with auditors, management, or supervisors.

What should be done next?

An effective response to IFRS 17 requires structuring data and processes in a durable and scalable way:

• Central insurance data layer – a consistent view of policies, claims, cash flows, and actuarial assumptions.
• Standardized calculation inputs – a single source of data for cash flows, CSM, and RA used consistently across the organization.
• Full calculation lineage – the ability to trace how changes in data or assumptions affect financial results.
• Automated reconciliation with the general ledger – reducing manual adjustments and reconciliations at the end of the process.
• Change driver reporting – clear analysis of the drivers of changes in results and CSM for management, audit, and supervision.

ORSA: a real test of an insurer’s management capability

Although ORSA has formally operated under Solvency II for years, for many insurance undertakings it remains a cyclical, highly manual process driven primarily by “reporting needs.” Supervisory expectations, however, are increasingly shifting away from the ORSA document itself toward how ORSA conclusions are actually used in managing the business.

In practice, ORSA has become one of the key indicators of organizational maturity: data consistency, scenario quality, the ability to respond quickly to changes in the environment, and the linkage between risk and strategic decisions.

What does ORSA actually require from insurers?

ORSA ultimately comes down to one question: can the insurer consciously manage its solvency under changing conditions?

To do so, the insurer must be able to:

• use the same data across risk, actuarial, and finance functions,
• apply consistent scenarios and assumptions in risk analysis and planning,
• quickly translate changes in assumptions (market, portfolio, operational) into impacts on capital and solvency,
• present a clear, repeatable calculation and decision trail for management and supervisors.

Where are insurers weakest today?

The most frequently identified ORSA-related issues include:

• siloed data used separately by risk, actuarial, and finance,
• manual construction of stress scenarios and projections,
• long calculation cycles and limited ability to run variants,
• difficulty quickly explaining differences between successive result iterations,
• ORSA treated as a one-off documentation exercise rather than a management tool.

As a result, insurers are able to prepare an ORSA report but cannot quickly update it or use it operationally when market or portfolio conditions change.

What should be done next?

An effective response to ORSA requirements calls for structuring risk and capital management processes around a shared data and scenario foundation:

• Common data model for risk, actuarial, and finance – a single source of data used for ORSA, planning, and management analyses.
• Central scenario and stress-testing platform – repeatable assumptions, shorter calculation cycles, and the ability to perform variant analysis.
• Automation of capital projections – reducing manual recalculations and reconciliations between iterations.
• End-to-end calculation and decision lineage – the ability to quickly reproduce results and justify decisions.
• ORSA-based management reporting – materials that support real decisions, not just regulatory compliance.

Solvency II: QRT and SFCR as a test of data maturity

For insurers, QRT and SFCR represent the most visible and regular point of interaction with supervisors. Although these reports have been submitted periodically for many years, every change in taxonomy, interpretation, or data scope quickly reveals the true condition of data, processes, and systems within the organization.

In practice, the problem is rarely the report format itself. The real challenge lies in how the data is prepared—a process that, in many insurers, remains heavily manual, reactive, and dependent on individual expertise.

What do QRT and SFCR actually require from insurers?

Solvency II reporting ultimately comes down to one requirement: the insurer must be able to deliver consistent, complete, and timely data, regardless of regulatory or organizational changes.

To achieve this, the organization must:

• apply uniform data definitions across actuarial, finance, and risk,
• ensure repeatability of the reporting process rather than closing each cycle ad hoc,
• respond quickly to changes in taxonomy and validations without rebuilding the entire process,
• limit manual adjustments and last-minute interventions at the final stage of reporting.

Where are insurers weakest today?

The most common QRT and SFCR issues include:

• data mappings to QRT templates maintained outside reporting systems and processes,
• manual adjustments and “workarounds” applied just before report submission,
• inconsistencies between QRT, ORSA, and data used for IFRS 17,
• difficulty quickly explaining differences between successive report versions,
• heavy workload peaks for teams during reporting close periods.

As a result, insurers often meet deadlines, but at the cost of data quality, process stability, and elevated operational risk.

What should be done next?

An effective response to QRT and SFCR requirements requires treating regulatory reporting as a repeatable production process:

• Central reporting data model – a single, consistent source of data prepared for Solvency II reporting.
• Automated QRT mappings – controlled and versioned rules resilient to regulatory change.
• Data quality validations upstream – detecting issues early, not after report rejection.
• Automated generation of QRT and SFCR – limiting manual adjustments at the end of the process.
• Audit trail and report reproducibility – full traceability from source data to the report submitted to supervisors.

IDD / POG: when product and distribution must be measurable, not just compliant

IDD and POG (product oversight and governance) requirements have long been part of the insurance landscape, but today they are assessed far beyond sales compliance. Supervisors focus on who the product reaches and what actually happens in practice. Insurers must demonstrate that products are appropriate for defined target markets and that distribution does not lead to systemic issues in servicing, complaints, or claims.

In this sense, IDD/POG shifts the emphasis from having procedures to having data and processes that enable ongoing product monitoring throughout its lifecycle and timely intervention when reality diverges from design.

What does IDD/POG actually require from insurers?

IDD/POG requires insurers to manage the product lifecycle in a controlled, evidence-based manner.

In practice, this means the ability to:

• define the target market and justify product design against specific customer needs,
• control distribution channels and ensure alignment between the product and how it is sold,
• monitor product performance post-launch—whether it behaves as expected or generates complaints, lapses, or inappropriate claims,
• demonstrate that product decisions (changes to terms, pricing, parameters) are data-driven rather than based solely on intuition or sales pressure.

Where are insurers weakest today?

The most common IDD/POG issues are highly systemic:

• lack of consistent product data across the lifecycle (sales → servicing → claims → complaints),
• limited monitoring of distribution quality and real alignment with the target market,
• difficulty linking market signals (complaints, lapses, disputes) to specific products, variants, and channels,
• POG processes based on documents and meetings rather than measurable indicators and automated oversight,
• product decisions made in isolation, without the ability to quickly assess customer and portfolio impact.

As a result, insurers can conduct periodic product reviews but lack tools to detect issues early and intervene before they escalate into supervisory or reputational risk.

What should be done next?

An effective response to IDD/POG requires building a “product control loop”—integrating product, distribution, and operational data into a single, controlled process:

• Single source of product and customer information – a consistent view of the product, distribution channel, and post-sale outcomes: servicing, claims, and complaints.
• Continuous product monitoring in practice – tracking signals such as complaints, lapses, disputes, and claim denials, not just periodic reviews.
• Data-linked product decisions – the ability to show the evidence behind changes to products, pricing, or distribution.
• POG as a process, not a document – decisions, roles, and responsibilities embedded in systems rather than files and presentations.
• Early issue detection – identifying warning signals before they become supervisory or reputational problems.

Data governance and data quality: when supervisors stop accepting “manual adjustments”

Supervisory expectations, articulated among others by EIOPA, increasingly make it clear that data used by insurers cannot be treated as a byproduct of processes but must be managed as an organizational asset. While data quality requirements are formally embedded in Solvency II, in practice they have become a standing element of supervisory assessment across ORSA, IFRS 17, QRT, DORA, and POG.

Supervisors focus less on individual reports and more on whether the insurer is in control of the data underpinning its decisions and reporting.

What does data governance actually require from insurers?

Data quality and governance requirements ultimately serve one objective: data must be consistent, controlled, and defensible wherever it is used.

In practice, insurers must be able to:

• apply the same data definitions across actuarial, finance, risk, and reporting,
• clearly identify the source of key data elements,
• demonstrate how and why data was adjusted,
• reproduce historical versions of data and reports together with the assumptions applied.

Where are insurers weakest today?

The most commonly identified data governance issues include:

• data silos between policy, claims, actuarial, and finance systems,
• different definitions of the same concepts (for example, exposure, premium, reserves) across functions,
• manual data adjustments without consistent documentation or decision traceability,
• lack of full data lineage,
• difficulty quickly explaining data changes between reporting periods.

What should be done next?

An effective response to EIOPA’s data governance expectations requires moving away from point solutions and building durable data management foundations:

• Common insurance data model – harmonized definitions used by actuarial, finance, risk, and reporting.
• Data quality management embedded in processes – automated consistency and completeness checks early, not just before reporting.
• Data lineage and audit trail – full traceability from source systems to regulatory reports or management decisions.
• Controlled data adjustment process – clear rules, accountability, and documentation of changes.
• Data quality reporting – treating data quality as a management metric, not just a compliance requirement.

Outsourcing and third-party risk: responsibility does not disappear with the contract

Outsourcing has long been an integral part of insurers’ operating models. Cloud-based policy systems, outsourced claims handling, TPAs, IT services, data providers, and actuarial support are now standard. At the same time, supervisory expectations—set by EIOPA and reinforced by DORA—make it clear that transferring a process externally does not transfer responsibility.

As a result, outsourcing is no longer just a procurement or legal matter. It has become a core element of operational risk management, business continuity, and customer protection, assessed on an ongoing basis rather than only at contract signing.

What does outsourcing actually require from insurers?

From a business perspective, supervisors expect insurers to understand and control the impact of third-party providers on critical services.

In practice, this means the ability to:

• identify critical and material outsourcing from the perspective of customers and continuity,
• understand which business processes and services depend on a given provider,
• monitor vendor-related risks throughout the contract lifecycle, not just at onboarding,
• demonstrate the ability to respond to provider failures without operational paralysis.

The supervisory question is clear: if a provider fails, does the insurer remain in control of its business?

Where are insurers weakest today?

The most common outsourcing-related weaknesses include:

• lack of a single, up-to-date view of all providers and their relevance to business processes,
• outsourcing classifications based on formal criteria rather than real customer and operational impact,
• fragmented information on contracts, SLAs, incidents, and vendor risks,
• limited ability to assess the impact of provider issues on specific insurance services,
• exit plans that exist “on paper” but have not been tested in practice.

As a result, insurers know who their providers are, but not always what will stop working when a provider fails.

What should be done next?

An effective response to outsourcing and third-party risk requirements requires moving from static registers to operational dependency management:

• Linking providers to business services – assessing outsourcing through its impact on sales, policy servicing, claims handling, and benefit payments.
• Central vendor and contract register – a single source of information on service scope, SLAs, risks, and responsibilities.
• Continuous vendor risk monitoring – incorporating incidents, service changes, and technology dependencies.
• Contingency scenarios and exit plans – tied to real processes and data, not just descriptive documents.
• Management and supervisory reporting – showing providers’ impact on operational resilience, not just a list of contracts.

Reinsurance: when risk transfer comes under supervisory scrutiny

Reinsurance plays a critical role in risk and capital management, but it is increasingly assessed for its impact on solvency and risk profile. From a supervisory perspective, what matters is how reinsurance aligns with the insurer’s risk profile, strategy, and capital requirements under Solvency II.

In practice, scrutiny increases in cases of high concentration of exposures, cooperation with non-EU reinsurers, or where reinsurance materially reduces SCR or solvency ratios. In such situations, supervisors expect not just confirmation that a contract exists, but a coherent explanation of its impact on risk and capital.

What does reinsurance actually require from insurers?

Supervisory expectations around reinsurance boil down to one question: is the risk transfer real, controlled, and defensible?

In practice, this means the ability to:

• demonstrate that reinsurance genuinely reduces risk, not just improves capital metrics,
• understand the impact of reinsurance contracts on SCR, solvency, and financial results,
• control exposure concentration across reinsurers and reinsurance programs,
• consistently link reinsurance to ORSA, risk policy, and capital planning,
• quickly analyze the effects of changes to the reinsurance program.

Reinsurance is no longer a “black box”—it must be transparent and data-driven.

Where are insurers weakest today?

The most commonly identified reinsurance issues include:

• lack of a single, coherent view of reinsurance contracts, exposures, and limits,
• fragmented reinsurance data across actuarial, finance, and risk,
• difficulty quickly translating program changes into SCR and solvency impacts,
• limited transparency of settlements with reinsurers,
• heavy reliance on the expertise of a small number of individuals.

As a result, insurers can design reinsurance programs but struggle to consistently justify their impact in supervisory dialogue.

What should be done next?

An effective response to supervisory expectations around reinsurance requires structuring this area as a repeatable, measurable process rather than a collection of contracts:

• Central register of reinsurance contracts and exposures – a single source of truth for contracts, limits, shares, and settlements.
• Linkage to risk and capital data – enabling rapid assessment of impacts on SCR and solvency.
• Scenario and variant analysis – evaluating alternative reinsurance programs within ORSA and planning.
• Audit trail of reinsurance decisions – the ability to reconstruct why a given program was adopted.
• Management and supervisory reporting – consistent materials showing the role of reinsurance in risk management, not just numerical outcomes.

A common denominator of today’s regulations

As is easy to observe, the areas that most strongly affect insurers today are not limited to individual legal acts or compliance checklists. Increasingly, they are systemic requirements derived from regulations such as Solvency II, IFRS 17, and DORA, but enforced through the lens of how the organization operates as a whole.

Supervisors are less likely to ask “has the requirement been formally met?” and more likely to ask “does the insurer understand its data, processes, and dependencies, and can it manage them in practice?”

From compliance to operational capability

A shared characteristic across all discussed areas is the shift in supervisory expectations—from reporting and documentation toward real operational capability.

This applies to operational resilience (DORA), financial reporting (IFRS 17), risk and capital management (ORSA, reinsurance), and customer protection (IDD/POG). Regulations increasingly test whether the insurer can:

• quickly connect data from different domains,
• assess the impact of events on customers, results, and solvency,
• make decisions under time pressure and uncertainty.

Data as a foundation, not a byproduct

Across nearly all discussed areas, data emerges as a key source of risk—its quality, consistency, availability, and explainability. Manual adjustments, spreadsheets, and end-of-process interventions are becoming major drivers of operational and supervisory risk.

In response, insurers are forced to build durable data management foundations: common models, central integration layers, quality controls, and full data lineage—not as IT initiatives, but as elements of the management system.

Systems as management tools, not just reporting engines

The role of IT systems is also changing. They are no longer passive data sources for regulatory reports but increasingly active tools for managing risk, resilience, and products.

Architectures that enable cross-domain data correlation, scenario analysis, and full decision explainability are becoming prerequisites for sustainable growth and scalability in insurance.

Automation instead of ad hoc actions

A common theme across all regulations is pressure for repeatability and scalability. Insurers can no longer respond to new requirements simply by increasing operational team effort.

A shift toward operating models based on automation, standards, and data architecture becomes essential to reduce operational risk, fixed costs, and dependence on individual expertise.

Summary: regulations test the ability to operate

Today’s regulatory pressure in insurance is fundamentally about whether the organization can operate in a consistent, predictable, and defensible manner—both under stress and in day-to-day management.

DORA, IFRS 17, ORSA, QRT, and IDD do not prescribe specific technologies, but they consistently test data quality, process repeatability, and the ability to rapidly explain decisions. Where manual reconciliations and ad hoc actions remain the foundation, operational and supervisory risk increases with each new regulation.

Insurers that invest in shared data models, automated processes, and architectures resilient to regulatory change gain real control over risk, performance, and customer outcomes. The rest will increasingly find themselves reacting under time and supervisory pressure, rather than managing change deliberately.