An ICT incident, and three different clocks start. We keep them in one place.
A cloud outage at your policy-administration provider is a DORA major incident, a possible Solvency II Article 35 material event, and, if it touches distribution, an IDD conduct question, and each of those has its own notification clock. Most insurers run ORSA out of the actuarial function and DORA out of ICT, with no shared record between them. Our platform holds the suppliers, contracts, ICT assets, and incident record once, and runs incident management as a workflow, not a spreadsheet. Solvency II and IDD, the prudential and distribution rulebooks, stay with our specialists, working from that same data.
ORSA, DORA, and IDD, each on its own clock.
Solvency II asks the actuarial and risk function to look forward, once a year, at everything that could threaten solvency, including operational risk. DORA asks the ICT function to assess ICT risk on its own cadence, with its own register. Most insurers run these two exercises in different teams with no shared data, and reconcile them, if at all, once a year in prose, after the fact.
The reinsurance relationship makes the overlap concrete. A reinsurer is a prudential counterparty under Solvency II, and, where it also handles claims data or bordereaux, an ICT third party under DORA. Cloud providers, policy-administration platforms, and claims systems carry the same double life. The supplier register your ICT team keeps and the outsourcing file your risk function keeps rarely describe the same counterparty the same way.
Distribution adds a third clock. An IDD conduct question, a DORA major incident, and a Solvency II material event can all originate from the same outage, on different notification deadlines, and a thin compliance team has to triage which regime applies before it can even start drafting the notification.
The supplier is one record. The incident is one workflow.
On the platform, an insurer's counterparties, cloud providers, reinsurers, and administration platforms among them, are single objects. The contracts, functions, and ICT assets connected to them update in one place, and the Register of Information reads directly from that graph rather than a parallel spreadsheet.
Incident management runs as a workflow inside the platform, not a document trail assembled after the fact: classification, the four-eye approval gate, and the record of what was decided and when, all in one place. That record is what a supervisor asking about a Solvency II Article 35 material event or a DORA major incident is actually asking to see.
What this does not claim: the platform does not run your ORSA, model technical provisions, or produce the SFCR. Those stay with your actuarial and risk teams and our specialists, using the same governance data as an input, not a replacement.
DORA, supplier risk, and incidents. Solvency II stays advisory.
When an insurer is onboarded, the platform activates the DORA Register of Information across all fifteen RT/B tables, submission-ready as an XBRL-CSV package, with GLEIF/LEI verification on every counterparty. Supplier risk, the register, AI-assisted and privacy assessments, and contractual arrangements, covers reinsurers, cloud providers, and administration platforms as first-class objects rather than a spreadsheet parallel to the DORA view.
Incident management is workflow-integrated: classification, escalation, and the four-eye approval gate, with entity and group structures modelling branches and group hierarchies where the undertaking operates across several. Policy generation, with AI-assisted drafting and human approval, and health checks run on the same platform.
Our insurance specialists carry ORSA, technical provisions, the SFCR and RSR, and IDD distribution-side obligations, using the platform's governance and supplier data as their starting input rather than reassembling it from scratch each cycle.
The actuarial and conduct calls stay with people.
Solvency-need forecasting, technical-provisions modelling, and how a product-governance question under IDD should be resolved are not data problems the platform can settle on its own. Our specialists, several of them former EIOPA or DNB supervisors and actuaries from Solvency II-regulated groups, make those calls and write the reasoning down against the record it concerns.
That written trail matters most when the questions overlap: whether an outage was a Solvency II material event, a DORA major incident, or both, and why. The decision sits next to the incident record it was made about, not in a separate memo nobody can find under deadline.
You own the platform, the data as adapted to your operation, and the written record of every interpretation decision. Advisory work continues on the actuarial and distribution side for as long as your authorisation requires it.
A discovery call, not a product demo.
You describe the compliance problem consuming the most of your team's time. We walk the platform through an example close enough to your operation that you can judge whether this way of modelling compliance fits how you want to work.
Book a discovery call →