Does DORA apply to our insurance or reinsurance undertaking?
DORA applies to insurance and reinsurance undertakings listed in Article 2(1) of Regulation (EU) 2022/2554, but small insurers under Article 4 of Solvency II are excluded under Article 2(3). If your undertaking is authorized under Solvency II and is not one of those small insurers, DORA applies to your whole network and information system estate, and your Solvency II authority is the body that supervises your compliance. Insurance intermediaries are a separate case: those that are micro, small or medium-sized enterprises are excluded under Article 2(3), while the Commission's review due by 17 January 2028 must consider whether excluded intermediaries using automated sales systems should come into scope. Confirm your status against the exact wording of the DORA text on EUR-Lex and with your supervisor, because the exclusion turns on the size tests in Solvency II rather than on how the business describes itself.
Three decisions set the workload once scope is settled. The first is proportionality: Article 4(1) requires Chapter II to be applied in line with your size, overall risk profile, and the nature, scale and complexity of your services and operations, so a small or simple undertaking carries a lighter load than a large group with many ICT dependencies. The second is threat-led penetration testing. Article 2(2) directs TLPT authorities to require testing from certain large insurers unless their assessment shows it is not justified, so ask your supervisor in writing whether you are in scope before budgeting for a TLPT. The third is the Solvency II amendment in Directive (EU) 2022/2556, which places insurers' and reinsurers' network and information systems under DORA and removes ICT risk elements from certain delegated-act powers. Your governance documents should reflect that single source of obligations.
Ownership stays with your undertaking throughout. Your board owns the ICT risk framework and the controls that implement it, and a partner such as DeployOpen can help prepare systems, configurations and evidence for your supervisor, but it does not decide scope or issue any report. Where an attestation is needed, an independent auditor or assessor issues it, and DORA provides no certification scheme for this purpose. Before engaging anyone, record your scope determination, the proportionality rationale and the TLPT decision in writing, then ask any outside party to quote against that written scope. Cost and duration depend on those inputs, and the drivers are the number of ICT services in use, the criticality of the functions they support and the depth of testing your supervisor requires.
Which authority supervises, and when TLPT applies
Article 46 of DORA assigns supervision of compliance to the competent authority already designated under each sector's legislation. For insurance and reinsurance undertakings, that is the Solvency II authority in the insurer's home member state. DORA does not create a new supervisor for insurers. The same authority that reviews governance, risk and solvency will review ICT risk management, incident reporting and third-party arrangements, and it keeps oversight of critical ICT third-party providers separate from its own supervision of the insurer.
- Existing relationship: Your DORA file goes to the authority you already report to under Solvency II, so review the supervisory contacts and reporting channels you use today.
- Supervisory powers: Expect the authority to use its general powers to request documents, carry out inspections and require remediation of ICT deficiencies.
- Critical providers: Oversight of critical ICT third-party service providers sits with the ESAs as Lead Overseers, not with your insurer's authority.
- Governance linkage: Board accountability for ICT risk should be documented in a form the Solvency II authority can review alongside existing governance records.
- Cross-border groups: Confirm which authority leads for a group with entities in several member states, and how coordination works.
Confirm your authority's expectations on format, reporting channels and inspection practice directly with them before you map your existing controls to DORA requirements.
Threat-led penetration testing under DORA is not automatic for every insurer. Article 2(2) requires TLPT authorities to require testing from certain entities, and it includes large insurers, unless the authority's assessment shows that testing is not justified. The decision is therefore a supervisory judgment about an individual undertaking. Insurers should not assume they are out of scope because they are not named in a list of thresholds, and they should not assume they are in scope without confirmation.
- Judgment-based trigger: The authority decides whether a large insurer must test, based on its own assessment of the undertaking.
- Testing requirements: Commission Delegated Regulation (EU) 2025/1190 sets the technical standards for TLPT, including how tests are scoped, run and closed.
- Authority-issued attestation: Article 26(7) provides for an attestation that a TLPT met the requirements. It is the only authority-issued attestation DORA provides for.
- No insurer thresholds supplied: Quantitative criteria for insurers are not set out in the sources used here, so ask your authority how it assesses size and risk.
- Early planning: If your authority asks you to test, the scope, tester selection and remediation planning will take time, so begin the internal discussion before the request arrives.
Ask your authority in writing whether it considers your undertaking within TLPT scope and what evidence it expects you to provide for that assessment.
DORA sets no certification scheme for compliance. Supervisors assess compliance using their powers, and the one attestation the Regulation names is the attestation that a threat-led penetration test met the requirements under Article 26(7). An insurer should not expect a DORA certificate, and no firm, including an implementation partner, can issue an authority report or attestation on its behalf. Preparing for supervision means building evidence that your own records can show to an inspector.
- No DORA certificate: There is no DORA certification to obtain, so evidence is judged against the Regulation and its technical standards.
- Attestation scope: The Article 26(7) attestation concerns a threat-led test, not general DORA compliance.
- Evidence of decisions: Keep records showing how the board approved the ICT risk framework, how risks were assessed and how deficiencies were tracked to closure.
- Test records: Retain scoping documents, tester qualifications, findings and remediation evidence for any penetration or threat-led test.
- Independent input: An auditor or consultant can review your readiness, but only the authority or the TLPT attestation process produces the outcome that counts.
Confirm with your authority which documents it will request first and how it wants them organized before an inspection.
Insurers can prepare for supervision and a possible TLPT request in parallel, because both depend on the same underlying evidence. Start by establishing a current inventory of ICT systems and the functions they support, then check how that inventory connects to your testing and incident records. Where an implementation partner helps, its role is to prepare systems, controls and evidence, while the insurer keeps ownership of decisions and results.
- Inventory first: A current list of ICT assets, services and dependencies is the basis for both supervisory review and any test scope.
- Testing programme: Maintain a documented programme of security testing, so that a threat-led test is an extension of existing work rather than a standalone exercise.
- Roles and sign-off: Name the owner of each DORA control and the person who approves test scope and remediation.
- Supplier evidence: Gather contracts, assurance and exit plans for ICT providers, since authorities will ask how third-party risk feeds into testing.
- Partner scope: Agree in writing what an implementation partner prepares and what remains the insurer's responsibility.
Review this plan with your Solvency II authority and your internal audit function before committing budget or staff time.
How an insurer moves from scoping to supervisory evidence
The sequence turns DORA's requirements into a scoped, owned and documented programme that the Solvency II supervisor can test. Each step closes with an output that feeds the next, so the evidence file builds as the work progresses.
Confirm scope and proportionality under Article 4(1)
Establish whether the undertaking or intermediary falls within Article 2(1) and is not excluded under Article 2(3), such as a small insurer under Solvency II Article 4 or a micro, small or medium-sized insurance intermediary. Then document how the size, risk profile, and the nature, scale and complexity of services apply Chapter II under Article 4(1). The output is a signed scoping memo approved by the management body, owned by the chief risk officer with input from legal counsel. It is done when the memo names the entity's category, the proportionality rationale and the supervising authority.
Map Solvency II system governance to Chapter II
Compare the existing Solvency II system of governance, including the risk management, internal control and internal audit functions, with DORA's ICT risk management duties in Chapter II. Note where ICT responsibilities already sit with the management body and where they do not. Directive (EU) 2022/2556 amends Solvency II so network and information systems are managed under DORA, so this mapping shows which Solvency II documents must change. The output is a gap-mapping matrix owned by the chief information security officer and the Solvency II risk function, reviewed by the management body.
Close governance and framework gaps
Turn the mapping into remediation work: assign board-level ownership of ICT risk, update the ICT risk management framework, and adopt the policies and controls needed to meet Chapter II. Self-hosted open-source platforms can support asset inventories, logging, access control and backup evidence inside the insurer's own infrastructure, but the insurer decides which tools fit its risk profile. An implementation partner can prepare configurations and documentation; the insurer keeps ownership of the control decisions. The step closes when each gap has an owner, a status and a linked piece of evidence.
Prepare the register of information and third-party inventory
Build the register of information covering every contractual arrangement for ICT services, including cloud providers, software vendors and intra-group services. Record which functions are critical or important, and confirm which providers hold open-source or self-hosted components. Ask the supervisor and relevant ESAs for the current template and submission format before finalizing. The output is a reconciled register owned by the third-party risk manager, checked against procurement records and contracts, and signed off before any regulator request.
Formalize incident classification and reporting processes
Define how ICT-related incidents are detected, classified, escalated and reported under Chapter III, and assign decision rights for major incident reports. Set up the templates and contacts for the competent authority, and test whether the process works with the insurer's existing operational risk and claims processes. The output is an incident management procedure with a classification matrix, an escalation tree and a worked tabletop record, owned by the chief information security officer and approved by the management body.
Run the required resilience testing
Schedule the basic testing programme under Chapter IV for ICT tools and systems, covering vulnerability assessments, scenario-based tests and any required penetration testing. Confirm early whether the insurer is a large insurer that the TLPT authority may require to test under Article 26, since TLPT rules for insurers depend on that assessment and on the TLPT RTS in Delegated Regulation (EU) 2025/1190. The output is a testing plan, a results register and a remediation log, owned by the head of security testing and reviewed by internal audit.
Assemble and maintain supervisory evidence
Compile a current evidence pack that the Solvency II supervisor can test under Article 50 powers: the scoping memo, gap matrix, policies signed by the management body, the register of information, incident records, test reports and internal audit findings. Keep the pack version-controlled and dated, so each item can be traced to a control. Because DORA sets no certification scheme, the pack supports supervision rather than an attestation. Ask your auditor or assessor to confirm the scope of any independent review. The output is a supervisory evidence file owned by the compliance lead and refreshed on a fixed review cycle.
What the Solvency II amendments change for insurer ICT governance
Article 2 of Directive (EU) 2022/2556 changes the Solvency II framework so that insurers' and reinsurers' network and information systems are managed in accordance with DORA. The practical effect is that ICT risk sits inside the same governance structure that Solvency II already requires for insurers, rather than being a separate technology topic. The board remains responsible for the system of governance, so it should expect ICT risk to appear in the written governance documentation with the same weight as other material risks. The directive also removes ICT risk elements from certain delegated-act powers, which means the detailed ICT rules come from DORA and its technical standards, not from Solvency II delegated acts. Insurers should confirm with their Solvency II supervisor how that split is reflected in their existing reporting and review cycle.
For the risk function, the consequence is that ICT risk should be assessed and reported within the existing risk management and own risk and solvency assessment processes, using the same governance logic applied to other risk categories. Risk owners need a clear line of sight from ICT assets and third-party services to the risk register, and the risk function should check that its ICT risk taxonomy matches the categories DORA uses. This is a check to run now: compare the current system of governance policies against DORA Chapter II and identify where ICT risk is named but not assigned an owner, a tolerance or a review frequency. Gaps found at this stage are cheaper to close in the existing policy set than during a supervisory review.
On documentation, the system of governance file should show where ICT risk management is set out, who approves it and how it links to the DORA policies and the ICT risk management framework. Insurers should not assume that a Solvency II policy alone covers DORA requirements, and should confirm with their supervisor and legal team which documents must be cross-referenced. The directive itself does not set out the document structure, so the practical design of this mapping is a decision for the insurer, informed by the scope of its business and its supervisor's expectations. Any external support for this work should be scoped in writing, and the insurer remains the owner of the governance documents and the sign-off.
What insurers must have in place before a supervisory review
A supervisory review of an insurer or reinsurer under DORA looks for documented governance, a complete picture of ICT dependencies, tested procedures and records that match the Solvency II framework. The cards below cover six items the supervisor will ask to see, with a practical way to check each one internally before the review starts.
ICT risk framework and board ownership
The management body must approve the ICT risk management framework and remain accountable for it, and the minutes should show that it reviewed and challenged the framework rather than only noting it. Check that the board paper names the owner of each control area, that the framework covers the proportionate scope the entity actually uses, and that the most recent review date is recorded. Ask for the signed approval and the minutes that show discussion.
Register of information and ICT inventory
The register of information lists every contractual arrangement for ICT services, including subcontractors, and it must be current when the supervisor asks for it. Compare the register against accounts payable, cloud billing and intra-group service agreements to find contracts that were never recorded. Confirm that each entry names the provider, the service, the location of data processing and whether the function is critical or important.
Incident classification and reporting procedures
Insurers need a written process that takes an ICT incident from detection to classification, to the decision on whether it is major, and to the initial, intermediate and final reports. Test the procedure with a tabletop exercise based on a realistic incident and confirm that the people named in the procedure can be reached outside office hours. Keep the classification decisions and their timestamps, because the supervisor will check whether reports were late.
Testing programme and TLPT readiness
Every insurer needs a testing programme that covers its ICT tools and systems, with results that feed back into remediation. Large insurers that the authority selects must also prepare for threat-led penetration testing under the TLPT regime. Confirm that vulnerability scans, penetration tests and remediation tickets are dated and linked to findings, and, where TLPT may apply, that the entity has a named test owner and a clear view of its critical functions.
Solvency II governance records updated for DORA
Because Directive (EU) 2022/2556 amends Solvency II so that ICT systems are managed under DORA, the system of governance documents must reflect that change. Review the own risk and solvency assessment, the risk management and internal audit policies, and the outsourcing policy to confirm that ICT risk is described consistently across them. Mismatched wording between the Solvency II file and the DORA framework is an easy finding for a reviewer to raise.
Exit plans for critical ICT providers
For each critical or important ICT service, the entity should hold an exit plan that describes how the service would move to another provider or back in-house without interrupting insurance operations. Check that each plan names the data to be returned, the time the team estimates for migration, and the contractual rights that support it. Test at least one plan against a realistic scenario, such as a provider outage or contract termination, and record the gaps the test exposed.
What DORA readiness costs an insurer, and who is paid for what
This table separates the cost components of DORA readiness for an insurance or reinsurance undertaking by who is paid, whether the cost is one-time or recurring, and what drives it up. No price figures have been published for this work, so use the table to structure requests for written quotes and internal budgets.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal staff time (board, risk, IT, compliance) | Insurer's own employees; board time for approving the ICT risk framework and policies | Largely one-time for the initial build, then recurring for annual review and reporting | Number of Solvency II and DORA-relevant systems, existing documentation quality, and how many policies must be rewritten |
| Implementation partner fees (systems and evidence preparation) | External partner, under a written fixed scope agreed before work starts | One-time for the initial scope, with possible recurring change requests | Number of in-scope systems, hardening depth, documentation volume and integration with existing tools |
| Tooling and licences | Software vendors and open-source platform hosting in the insurer's own infrastructure | Mix: licences and hosting recur; setup is one-time | Platform choice, number of users or nodes, hosting model and retention of logs and evidence |
| Testing providers (security and resilience testing) | External testers engaged by the insurer | Recurring, usually on a testing cycle | Scope of applications and infrastructure, need for remediation retests, and whether threat-led testing applies to the insurer |
| Independent auditor or assessor fees | Independent audit or assessment body, only where the insurer commissions an assessment | Recurring if an assessment cycle is commissioned | Scope of assessment, number of entities and sites, and the assurance type the insurer chooses (confirm with the assessor) |
| Ongoing support and retainers | External partner under a separate retainer agreement | Recurring | Frequency of upgrades, patching, testing, evidence refresh and incident support required |
| Regulatory and supervisory engagement | Insurer's own staff; supervisory authority does not charge for supervision under DORA | Recurring | Number of supervisory interactions, incident reports and remediation requests raised by the Solvency II authority |
What makes DORA work heavier or lighter for an insurer
An insurer's DORA workload depends less on the Regulation's headline rules than on a few factors that set how much ICT risk management, testing and third-party control it must carry. Each card below names one factor and how to control it, so the insurer can size its programme before scoping external help.
Entity size and proportionality
Article 4(1) requires Chapter II to be applied in line with proportionality, taking into account size, overall risk profile, and the nature, scale and complexity of services and operations. A small insurer with a narrow product range sits in a very different position from a large multi-line undertaking. Confirm with the Solvency II authority how the insurer's size and risk profile have been assessed, and record that reasoning in the ICT risk framework so it can be defended at supervision.
Number and criticality of ICT third parties
Every core system, claims platform, policy administration tool or data feed sourced from a provider adds to the register of information and to contract and monitoring work. Weight rises sharply when providers support critical or important functions. Ask for a current inventory of ICT providers, then flag which ones would stop underwriting, claims or regulatory reporting if they failed, because those providers need the strictest contract terms and exit planning.
Cloud and self-hosted platform footprint
The mix between managed cloud services and platforms the insurer runs in its own accounts or data centers changes who controls logging, patching, backup and access. Self-hosted open-source platforms keep control inside the insurer's environment but move operational duties onto the insurer's own team. Map each platform to its hosting model and owner, then document which controls the insurer holds itself and which it depends on a provider to supply.
Group structure and intra-group services
Insurers often rely on group functions for shared IT, security operations or data platforms. Those arrangements still fall under DORA's third-party rules, and the group entity's controls do not automatically satisfy the local undertaking's obligations. List every intra-group service, the service level agreed in writing, and who holds audit and exit rights. Confirm whether the group policy covers the local undertaking's specific supervisory expectations.
Legacy policy and system maturity
Older policy administration and claims systems often lack modern logging, identity controls or documented change processes, which raises the effort needed to meet the ICT security requirements. The gap is usually widest in batch interfaces and spreadsheets used for pricing or reserving. Start with a gap analysis that ranks legacy systems by business criticality, then decide which to remediate, isolate or retire.
Whether the entity falls under TLPT
Article 2(2) requires TLPT authorities to consider testing for large insurers, unless their assessment shows it is not justified. Being in scope brings threat-led penetration testing with its own preparation, tester requirements and remediation cycle, which adds cost and staff time beyond the basic testing every entity runs. Ask the Solvency II authority in writing whether the insurer is in scope, and plan the testing programme around that answer.
Who owns controls, who prepares evidence, and who issues findings
The insurance or reinsurance undertaking owns its ICT risk management framework, its decisions and its residual risk. DORA places responsibility on the financial entity and its management body, and the Solvency II authority decides whether the entity complies. Nothing an outside party does transfers that accountability.
- Governance decisions: the management body approves the ICT risk strategy, the risk tolerance and the policies, and it carries the duty to oversee them.
- Control ownership: named internal owners run each control, review its performance and accept or treat residual risk.
- Register and incident handling: the insurer maintains its register of information and runs its own incident classification and reporting to the supervisor.
- Supervisory contact: the insurer answers the Solvency II authority's requests, inspections and any remedial measures.
- Internal review: internal audit and the independent control function test whether the framework works in practice.
Before engaging any partner, confirm which decisions in your framework must stay with named internal roles and document that split in writing.
An implementation partner such as DeployOpen plans, deploys, configures, hardens and documents self-hosted open-source platforms inside the insurer's own infrastructure. Its work produces the systems, configuration records, documentation and evidence that the insurer's controls depend on. It does not decide compliance and it does not issue reports, attestations or certificates.
- Systems work: build, integration, hardening, backup and upgrade of the platforms in scope, inside the insurer's cloud accounts, data centers or air-gapped networks.
- Documentation drafting: draft procedures, configuration baselines and technical records for the insurer's review and approval.
- Evidence preparation: set up logging, access records, change records and test outputs so the insurer can retrieve them.
- Testing support: run or support security testing and remediate findings the insurer chooses to address.
- Limits: the partner cannot sign the insurer's policies, accept residual risk or represent the insurer to the supervisor.
Ask each partner to state in the written scope which deliverables are documents, which are configured systems and which are evidence records, and who signs each one.
Independent parties issue findings. An auditor, assessor or certification body gives an opinion on controls where a framework calls for one. For threat-led penetration testing, the authority-issued attestation under Article 26(7) of DORA confirms that a test met the requirements, and that attestation comes from the competent authority, not from the tester or the partner. Testers under the TLPT regime must meet the requirements of the testing standards and be accredited or approved as the rules require.
- Assessment opinions: independent parties test design and operating effectiveness and report their own conclusions.
- TLPT testers: only testers meeting the TLPT requirements may run threat-led tests for in-scope insurers, and the authority decides on the resulting attestation.
- Separation of duties: the party that built or configured a control should not be the party that tests it for the same assessment.
- Independence checks: confirm an assessor's independence and accreditation in writing before engaging.
- Scope: an assessor tests against the scope the insurer and assessor agree, not the scope a partner proposes.
Before signing, confirm which party will issue each output and whether the supervisor requires that output to come from an independent source.
Questions insurers ask about DORA scope, cost and effort
Does a small insurer have to comply with DORA?
Small insurers excluded under Article 4 of Solvency II fall outside DORA under Article 2(3), so they are not required to apply it as financial entities. Insurance intermediaries that are micro, small or medium-sized enterprises are excluded as well. Exclusion depends on the legal status and size tests in the texts, so confirm your classification with your Solvency II authority before you scope any work. Check separately whether you are an essential or important entity under NIS2, because Article 1(2) makes DORA the sector-specific act for financial entities in that position. Keep your exclusion reasoning on file so you can show it to a supervisor later.
Which authority supervises DORA compliance for insurers?
The Solvency II authority already designated for your sector supervises DORA compliance for insurance and reinsurance undertakings. Article 46 assigns supervision to the competent authority under each sector's legislation, without prejudice to oversight of critical ICT third-party providers, which the ESAs handle as Lead Overseers. In practice, your prudential supervisor will review your ICT risk framework, incident reporting, register of information and testing evidence. Use the governance structure and document set you already give them, so reviews do not start from scratch. Ask which templates, reporting channels and evidence formats they expect, because those details sit in national practice and the technical standards, and the Regulation alone does not settle them.
Must a large insurer run threat-led penetration testing?
A large insurer may have to, but the TLPT authority decides, and it must require testing unless its assessment shows that testing is not justified. Article 2(2) names certain large insurers among the entities it covers, so ask your authority whether your undertaking is in scope. If it is, the threat-led test follows the TLPT technical standard in Commission Delegated Regulation (EU) 2025/1190. Plan for a multi-phase programme rather than a single penetration test, and ask any provider to state scope, tester qualifications, phases and deliverables in writing. The insurer keeps ownership of the test results, the remediation and the decisions taken on findings.
How do the Solvency II amendments change ICT governance for insurers?
Directive (EU) 2022/2556 amends Solvency II so that insurers' and reinsurers' network and information systems are managed in accordance with DORA. It also removes ICT risk elements from certain Solvency II delegated-act powers, so ICT requirements now come from DORA and its technical standards. For governance, the management body should own ICT risk alongside your other risks within the system of governance, and it should approve the policies, risk assessment and reporting that DORA requires. Map your existing Solvency II governance documents to the DORA artefacts so you maintain one coherent set of records instead of two parallel ones.
What work does DORA need from internal insurance staff?
Internal staff own the decisions. The management body approves the ICT risk framework, named owners run incident handling and the register of information, and the teams that operate systems produce the evidence. Typical roles include ICT risk, information security, operations, procurement and compliance, with legal input on contracts with ICT providers. The effort depends on how well your estate is already documented, how many ICT providers you use and how many incidents you log each year. Before you sign anything, ask any prospective partner to list the internal roles and time they expect from you, and check that list against your own asset inventory.
Can an insurer carry out its DORA work in-house?
Yes, an insurer can do much of its DORA work in-house, because the financial entity owns its controls and DORA does not require outside consultants. In-house teams need capacity and skills in ICT risk, incident reporting, resilience testing and ICT contract management, plus a way to produce evidence that a supervisor can test. Outside help is most useful where the team lacks hands-on platform engineering skills, needs security testing from an independent provider, or wants a fixed-scope readiness plan. An implementation partner prepares systems and evidence, but only your supervisor or an independent auditor reaches conclusions. DORA sets no certification scheme, so do not buy any certificate as proof of compliance.
What could the 2028 DORA review change for insurers?
The Commission must review DORA by 17 January 2028 and report to Parliament and the Council. For insurers, the review covers whether insurance intermediaries excluded under Article 2(3)(e) should come into scope where they use automated sales systems. It also covers the criteria for designating critical ICT third-party providers and the voluntary nature of significant cyber threat notification. Separately, the Digital Omnibus proposal COM(2025) 837 would route major incident reports through a single NIS2 entry point, and its procedure was still awaiting committee decision as of October 2026. Keep your register and incident process modular so you can adjust them without rebuilding the framework.
What could still change: the 2028 review and the Digital Omnibus
The most concrete item for insurers is the Commission review that Article 58(1) of DORA requires by 17 January 2028. Among other things, that review must consider whether insurance intermediaries excluded under Article 2(3)(e) should be brought into scope where they use automated sales systems. An intermediary that is currently outside DORA because it is a micro, small or medium-sized enterprise should check whether its sales platform, quoting engine or policy issuance tools rely on automated processes, and record how those systems are built, hosted and monitored. If the scope changes, that inventory becomes the starting point for an ICT risk assessment rather than a last-minute project. The review is a reporting duty for the Commission, so it does not change obligations today, but it gives an intermediary a clear date to plan around.
The Digital Omnibus proposal, COM(2025) 837 of 19 November 2025, would amend Article 19 of DORA so that major ICT-related incident reports and voluntary notifications of significant cyber threats pass through a single entry point under NIS2. For an insurer, this would change where a report is filed and possibly how the reporting chain is wired, but it would not remove the need to classify incidents and meet deadlines under the current text. As of October 2026, the European Parliament's Legislative Observatory lists procedure 2025/0360(COD) as awaiting committee decision. Plan on the text as it stands, and confirm with your competent authority and any NIS2 national authority which reporting channel applies to your entity today. Keep your incident runbooks and reporting templates modular so that a change in the single entry point can be absorbed without rewriting classification logic.
The practical step is to assign an owner, usually in compliance or the risk function, to track both the Omnibus procedure and the 2028 review, and to review the position at each governance cycle. Ask your legal advisers whether your undertaking or intermediary falls under NIS2 as an essential or important entity, because that determines whether the Omnibus change affects you at all. Keep the register of information and the incident procedures current with the regime in force. Where a change is adopted, a fixed-scope implementation partner can prepare the affected systems, workflows and evidence, but only the entity owns its reporting decisions and the independent supervisor sets its expectations.
How DeployOpen prepares insurer systems and evidence for DORA
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure. For insurers and reinsurers, we prepare systems, controls and evidence for the Solvency II authority's supervision, while the organization keeps ownership of its controls and independent assessors issue any reports.
How we scope
- Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
- The written scope states which ICT systems, DORA chapters and insurance entities are covered by the work.
- Scoping confirms whether the undertaking is excluded, in scope or subject to the Solvency II authority's supervision.
How we build
- We implement and configure self-hosted open-source platforms in the client's own cloud accounts, data centers or air-gapped networks.
- Logging, access control, backup and change records are set up so they produce the evidence supervisors ask for.
- Where resilience testing is needed, we run security tests and support the organization in preparing for threat-led testing requirements.
How we hand over
- Deliverables include configuration documentation, control mapping to the organization's own ICT risk framework, and operating procedures.
- Evidence packs are organized so the insurer's compliance and internal audit teams can review them independently.
- Handover sessions train the client's staff to run, monitor and update the platforms without ongoing dependency on DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Retainers can cover updates to documentation when the Solvency II authority or the European Commission changes requirements.
- Clients should confirm with DeployOpen which post-handover tasks sit inside a retainer and which need a separate written scope.
