Why traditional ECM and RBAC won’t carry insurers through DORA & eIDAS v2
Insurers manage millions of sensitive documents every day: claims, contracts, medical records, customer correspondence. For decades, role-based access control and traditional ECM platforms have been the default answer to governing that information. That era is over. With DORA now enforceable across the EU financial sector and eIDAS v2 establishing new expectations for digital identity and trust, the gap between where most insurers are and where regulation requires them to be has never been wider. The good news: there is a path forward. And it starts with rethinking access control from the ground up.
The regulatory moment insurers cannot ignore
DORA, the Digital Operational Resilience Act, has been applicable since 17 January 2025. It applies to the entire EU financial sector, including insurers of all sizes, and it does far more than add a compliance checkbox. DORA demands demonstrable, structural ICT resilience: boards are accountable, risk frameworks must be operational, third-party suppliers must be overseen, and incidents must be reported with precision. It is a shift from IT compliance to sector-wide governance.
eIDAS v2 is the complementary layer. Where DORA focuses on operational resilience and risk management, eIDAS v2 provides the digital trust infrastructure: qualified electronic signatures, verified identities, qualified timestamps, and crucially qualified electronic archiving. Together, they form a regulatory framework that reaches into every corner of how insurance data is handled, stored, and accessed.
"DORA is about protecting citizens' trust in digital financial services," says Vincent Panis, Head of IT & Digital Operations at Patronale Life and member of the DORA Working Group at Assuralia. The regulation is not primarily about insurers. It is about the people those insurers serve.
Why traditional access control falls short
Most insurance organisations today rely on Role-Based Access Control (RBAC). It is familiar, widely implemented, and increasingly inadequate. Static roles create coarse-grained permissions. As organisations grow and data environments become more complex, they face role explosion, dozens or hundreds of overlapping roles that are difficult to manage and impossible to audit meaningfully. There is no contextual decision-making: a user with the "Claims Handler" role has the same access on a personal device in an airport as on a managed corporate laptop during business hours in the office. That is not resilience. That is risk.
DORA explicitly requires demonstrable control, least-privilege access, and the ability to contain the blast radius of any incident. RBAC cannot deliver that. eIDAS v2 requires that every access decision be explainable and auditable. RBAC cannot deliver that either.
Access control as the connecting pillar
The path from operational resilience (DORA) to digital trust (eIDAS v2) runs directly through access control. The central question is not simply "who has access?" but rather: who can access what, under which conditions, and how can this be proven?
That question has a modern answer: Policy and Attribute-Based Access Control, P.A.BAC, or the combination of PBAC and ABAC. This approach is not a niche idea. It is the recommendation of the National Institute of Standards and Technology, defined in NIST SP 800-162, and it has become the foundation of zero-trust security architectures globally.
PBAC centralises policy definition. Access rules are authored, governed, and versioned in one place. Policies are evaluated dynamically at runtime, and the same rules are enforced consistently across portals, APIs, microservices, and document repositories. Every decision is traceable back to a policy. Audits become reports, not interviews.
ABAC adds granularity and context. Access decisions are made not on static roles alone, but on a rich combination of user attributes (department, clearance, role), resource attributes (document type, classification, status), and contextual attributes (IP location, device posture, time of access, risk level). A claims specialist accessing a sensitive medical attachment from a managed corporate laptop during business hours in an EU region is a very different situation from the same person attempting the same action from an unmanaged device at midnight. ABAC can distinguish between them. RBAC cannot.
What this looks like in practice
Consider three concrete rules from a PBAC/ABAC implementation in an insurance context.
A claims document access rule restricts reading of sensitive claim files to users in the Claims department, with at least Confidential clearance, on a managed device, within an EU IP region, for documents that are not archived. The same rule applied uniformly across every system that touches those documents: without redeployment, without manual exceptions.
A medical attachment protection rule goes further. Reading may be allowed under standard claims access conditions, but downloading a highly confidential medical attachment requires the user to be a designated Claims Medical Specialist, during business hours, when the system's assessed risk level is low. Every download is explicitly justified. eIDAS v2's requirement for controlled access and strong audit evidence is met by design.
An email and attachment rule governs how inbox content and linked files are accessed together. A user can view an email and its attachments only if they are a named party (from, to, or cc), accessing for a business communication purpose, through the established email-attachment relationship. Attachments are never directly accessible outside that relationship. The policy either permits or denies, and the outcome is recorded.
These rules scale. Whether an insurer manages two million or two hundred million documents across claims, contracts, broker relationships, and customer correspondence, the same policy engine evaluates every access request consistently, contextually, and with a full audit trail.
Qualified archiving: more than storage
eIDAS v2's qualified electronic archiving capability is often misunderstood as a storage upgrade. It is not. A qualified e-archive is a dedicated system designed to preserve content integrity and accessibility over time, across application lifecycles, format migrations, and regulatory retention periods. It ensures that signed content remains verifiable years or decades after the original signing infrastructure has changed.
Cloud cold storage solutions are not a substitute. Azure Archive, AWS Glacier, and similar offerings preserve bytes. They do not preserve context, provenance, or legal evidentiary value. For insurers managing crown-jewel data (policies, claims settlements, medical records) the distinction is critical.
Qualified archiving, combined with ABAC-governed access, creates the end-to-end integrity that DORA and eIDAS v2 together demand.
Watch the full session to see the concepts in action
What insurers can do today
The regulatory pressure is real and the compliance clock is running. But the gap between today's access models and DORA/eIDAS v2 expectations can be closed systematically.
Start by mapping your current access control model honestly. Identify where system users hold broad, uncontextualised access, the "one key to the castle" pattern, and where MFA and user context are absent. These are your highest-risk exposure points.
Assess your document and content architecture against the requirements of qualified archiving: long-term preservation, integrity, accessibility, and provenance. Determine which systems hold crown-jewel data and whether those systems can demonstrate their audit trail today.
Then build toward a policy-driven model. PBAC/ABAC does not require a complete system replacement. It can be layered onto existing content infrastructure, evaluated at the access layer, and extended progressively. The goal is not perfection by next quarter, it is a defensible trajectory that regulators can see and auditors can verify.
The question DORA asks is no longer whether your systems can survive an incident. It is whether you can prove they were governed correctly before it happened.
