Services
AIManaged ServicesConsultingOutsourcing
Differentiators
Compliance & SovereigntyEmail InfrastructureObservability & AIFree Tools & Assessments
Language
EnglishDeutsch — soonFrançais — soonEspañol — soon
Book a review
Industries · Financial services & fintech

We're the kind of ICT provider DORA was written about.

DORA makes your ICT third parties part of your compliance surface — and most vendor contracts fail the test. We supply Article 30 clauses, Register-of-Information data, audit rights and a tested exit strategy as standard, plus the DORA-aligned services, run inside the EU.

The Digital Operational Resilience Act (DORA) has applied directly across the EU since January 2025, requiring around 22,000 financial entities to manage their ICT risk across five pillars — and, critically, to govern every ICT third-party provider they use through a Register of Information and mandatory Article 30 contract clauses. Third-party risk is where firms are failing most: in the 2024 dry run, only about 6.5% passed all the register's data-quality checks. Argus Root is built to be the provider that closes that gap rather than opening one: an EU-resident ICT third party that supplies the Article 30 clauses, register data, audit rights and exit strategy out of the box, and delivers the DORA-aligned services — resilience testing, incident support and software supply-chain evidence — itself.

In short

  • DORA (EU 2022/2554) applies since 17 Jan 2025 to ~22,000 financial entities and their ICT providers; 2026 is the enforcement year. Five pillars; it supersedes NIS2 for finance.
  • Third-party risk (Pillar 4) is the biggest gap — only ~6.5% of firms passed all 116 Register-of-Information checks in the 2024 dry run.
  • Article 30 mandates contract clauses — audit rights, incident cooperation, data portability, exit strategy; we provide them as standard. CTPP penalties reach ~€800K/day.
  • Incident reporting runs on a 4h / 72h / 1-month clock; TLPT (TIBER-EU) is required of systemic firms every 3 years — both delivered through our testing and NOC.
  • An ICT provider that cannot meet DORA becomes your gap; we are built to be the one that strengthens your position, not the one a supervisor flags.

What does DORA require, and who does it apply to?

DORA is the EU's single rulebook for digital operational resilience in finance, and because it is a regulation rather than a directive it applies directly and uniformly across all member states, without the national variation that complicates NIS2. Its scope is wide: not only banks and insurers but investment firms, payment and e-money institutions, crypto-asset service providers and many fintechs — around twenty-two thousand entities — and it reaches their ICT third-party providers as well. Since January 2025 it has been fully in force, and through 2026 supervisors have moved from explaining it to enforcing it, conducting audits, issuing the first threat-led-testing notifications and scrutinising vendor contracts.

The substance sits in five pillars. The firm must run a documented ICT risk-management framework approved at board level; manage and report major incidents on a strict timeline; test its operational resilience, up to threat-led penetration testing for the systemically important; govern every ICT third party through a register and mandatory contract terms; and participate in threat-intelligence sharing. For entities inside DORA's scope it largely supersedes NIS2 under the lex specialis principle, which is a simplification worth having — one well-run programme answers the obligation rather than two that overlap. The pillar that consumes the most effort, and produces the most findings, is the third-party one.

Why third-party risk is where firms are failing.

The numbers tell the story. When the European Supervisory Authorities ran a dry submission of the Register of Information in 2024, only about six and a half percent of firms passed all one hundred and sixteen data-quality checks. Supervisory findings since have pointed at the same places repeatedly: incomplete registers, missing or sub-standard Article 30 contract clauses, weak visibility of sub-contractors, and unmanaged concentration risk from routing critical functions through a handful of large providers — nineteen of which have now been formally designated as critical ICT third-party providers, subject to direct oversight and penalties that can reach the order of eight hundred thousand euros a day. Pillar 4 is where the regulation bites, and where most of the remediation work now sits.

DORA'S 5 PILLARS → WHAT WE RUN 1 · ICT risk mgmt framework · board-owned managed security · hardening 2 · Incident report 4h · 72h · 1 month 24/7 NOC · detection 3 · Resilience test TLPT · TIBER-EU pen testing · vuln mgmt 4 · Third-party ★ biggest gap · RoI · Art 30 we are Article 30-ready 5 · Info sharing threat intelligence shared threat intel In the 2024 dry run only 6.5% of firms passed the Register-of-Information checks — your ICT provider should close that gap, not be it
DORA's five pillars, each mapped to the service that satisfies it. The fourth — third-party risk — is where firms fail most, and it is the one where an ICT provider either strengthens your register or becomes a hole in it.

This is the angle that matters when choosing who runs your infrastructure. Under Pillar 4 your ICT providers are not outside your compliance perimeter; they are inside it, and a provider that cannot hand you the contract clauses and the register data DORA demands becomes a finding with your name on it. The most useful thing an ICT partner can do for a financial entity in 2026 is therefore simple to state and rare to deliver: be the provider that closes the gap rather than the one that opens it.

Is your ICT provider a gap in your Register of Information?

It is the question a supervisor effectively asks, and for many firms the honest answer is yes. The Register of Information must account for every ICT third-party arrangement with clean, structured data — provider, service, locations, sub-contractors, criticality — and each contract must carry the Article 30 clauses. Where a vendor cannot supply those, the firm is left either renegotiating under deadline or carrying a documented gap into a submission that, on the 2024 evidence, most firms already struggle to pass. The provider that arrives with the clauses and the data ready removes that work and that risk at a stroke.

That is how we are built. Our agreements carry the Article 30 provisions by design, our service data maps to the register fields you have to submit, audit and access rights extend to you and your regulator, and a tested exit strategy with no concentration lock-in is part of the arrangement rather than a clause we resist. The checklist below is the shape of what we hand you, so that engaging us subtracts from your remediation list instead of adding to it.

We provide Article 30 clauses RoI data fields Audit & access rights Tested exit strategy EU service locations 4h/72h reporting support

What is threat-led penetration testing, and do you need it?

DORA's testing pillar has two levels. Every entity must run basic resilience testing annually — vulnerability assessments, scans, source-code review, scenario tests. The systemically important must additionally undergo threat-led penetration testing, the advanced, intelligence-driven exercise conducted under the TIBER-EU framework at least every three years, with a threat-intelligence phase, a red-team execution against live production systems, and a supervised closure phase. It is materially more demanding than a standard test, and supervisors have pushed back hard on firms that tried to confine it to non-critical systems.

We deliver both levels through our penetration testing practice, scoped against the full ICT environment as the regulation expects and with the evidence mapped to the DORA articles your assessor will cite. Where the weakness lives in the software you build and ship rather than the systems you run, the asset-inventory and supply-chain expectations under Articles 8 and 30 are met through the SBOM and signing work in our DevSecOps and supply chain security practice. The testing is not a box-ticking event but the part of the programme that proves the rest of it actually holds.

How DORA's pillars map to what we run.

The value of working with one operator across the estate is that the five pillars stop being five separate projects. The ICT risk-management framework and its controls are anchored by our managed security practice. Incident detection and the four-hour, seventy-two-hour and one-month reporting clock are supported by our 24/7 NOC and monitoring, so the machinery to meet the deadlines exists before an incident, not during one. Resilience testing — basic and threat-led — comes from penetration testing and vulnerability management; supply-chain evidence from DevSecOps; and operational continuity from backup and disaster recovery, which is itself part of what the resilience pillar expects.

The fourth pillar, third-party risk, is the one we answer simply by how we are constituted: an EU-resident provider with Article 30 clauses, register-ready data, audit rights and a tested exit strategy, which closes a gap rather than opening one. The whole is tied to the obligations you report against through our compliance and sovereignty practice. The result is a single, coherent programme mapped to DORA article by article, rather than a collection of services you have to stitch into a compliance story yourself.

A DORA-ready ICT provider, by design.

Most infrastructure providers treat DORA as their client's problem. We treat it as a specification we are built to meet, because under the regulation our compliance and yours are not separable — a provider that cannot meet DORA hands its financial clients a finding. So we supply the Article 30 clauses, the register data, the audit rights and the exit strategy as standard, run the EU-resident infrastructure ourselves with no resale layer, and keep our own house in order so that engaging us strengthens your position rather than complicating it.

There is a concentration argument too. Part of what DORA is reacting to is the systemic risk of the whole sector depending on a handful of giant providers, nineteen of them now under direct oversight. An EU operator that runs the metal itself, on open foundations, is a way to reduce that concentration rather than deepen it. It is the same principle behind everything Argus does — a European operator that builds and runs the thing and tells you the truth about it — applied to the sector where the rules about ICT providers are now the most exacting in the world.

Questions financial buyers ask.

What is DORA, and who does it apply to?
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied directly across the EU since 17 January 2025. It governs how financial entities — banks, insurers, investment firms, payment institutions and many fintechs, around 22,000 entities in all — manage their ICT risk, and it reaches their ICT third-party providers too. It is a regulation rather than a directive, so it applies uniformly without national transposition, and 2026 is the year supervisors shifted from guidance to active enforcement.
What are DORA's five pillars?
ICT risk management (Articles 5–16); ICT incident management and reporting (17–23); digital operational resilience testing (24–27); ICT third-party risk management (28–30); and information sharing (45–49). Together they require a firm to run a documented risk framework, report major incidents on a strict clock, test its resilience, govern every ICT provider through a register and mandatory contract clauses, and share threat intelligence. The third-party pillar carries the highest rate of compliance gaps in supervisory assessments.
Why is third-party risk where firms are failing?
Because it is both the newest discipline and the most exposed. In the regulators' 2024 dry run of the Register of Information, only about 6.5% of firms passed all 116 data-quality checks, and supervisory findings repeatedly cite incomplete registers, missing Article 30 contract clauses and weak sub-contractor visibility. The register has to account for every ICT provider, and any provider that cannot supply the required clauses and data becomes a gap in your compliance — which is exactly the gap we are built not to be.
What is the Register of Information?
It is the structured inventory of all your ICT third-party arrangements that DORA requires you to maintain and submit to your competent authority, covering provider details, the service, its locations, sub-contractors and criticality. Deadlines vary by authority through 2026. Keeping it complete and accurate is one of the hardest practical tasks under DORA, and it depends on every provider handing you clean, structured data — which we do as a matter of course rather than a special request.
What are Article 30 contract clauses?
Article 30 sets the mandatory provisions every ICT contract with a financial entity must contain: audit and access rights for you and your regulator, cooperation and reporting during incidents, data portability, a defined exit strategy, service-location transparency and sub-contractor controls. Many firms discover at audit that their existing vendor contracts lack these. Our agreements include them by design, so engaging us does not create another contract you have to renegotiate to be compliant.
What is threat-led penetration testing under DORA?
TLPT is the advanced, intelligence-driven testing DORA requires of systemically important entities under Articles 26 and 27, conducted under the TIBER-EU framework at least every three years against live production systems. It is distinct from the basic resilience testing all entities must do annually. We deliver both through our penetration testing practice, scoped to the full ICT environment as the regulation expects rather than confined to a convenient subset, with the evidence mapped to the DORA articles.
How quickly must we report an incident under DORA?
On a strict, staged clock for major incidents: an initial notification within hours of classification, an intermediate report within around 72 hours, and a final report within roughly a month. Supervisors have penalised firms for delaying classification to stop that clock starting. We support the detection and the reporting timeline through our monitoring and NOC, so the operational machinery to meet the deadlines exists rather than being assembled in the middle of an incident.
Does DORA replace NIS2 for us?
For financial entities within DORA's scope, yes, in effect — DORA is the more specific regulation and its ICT risk and third-party provisions take precedence over NIS2's general ones under the lex specialis principle. That is helpful, because it means one well-run programme answers the financial-sector obligation rather than two overlapping ones. We map controls to DORA specifically, while keeping NIS2 alignment for any parts of a group that sit outside DORA's scope.
We're a fintech, not a bank — does DORA still apply?
Very likely yes. DORA's scope is broad, covering payment institutions, e-money firms, crypto-asset service providers, investment firms and more, not only banks and insurers. Smaller and non-interconnected entities get a simplified ICT risk framework, but the incident-reporting, contract-clause and information-sharing obligations apply at full weight regardless of size. If you are a regulated financial entity of almost any kind operating in the EU, the safe assumption is that DORA reaches you.
Why use an EU ICT provider that is itself DORA-ready?
Because under DORA your ICT providers are part of your compliance surface, and one that cannot meet the requirements becomes your problem at audit. An EU-resident provider that supplies Article 30 clauses, clean Register-of-Information data, audit rights and a tested exit strategy as standard removes a gap rather than adding one — and reduces the concentration risk that comes from routing critical services through a single hyperscaler. We are built to be the provider that strengthens your DORA position, not the one a supervisor flags.

Make your ICT provider the part of DORA you don't worry about.

Tell us what you run and where you are in your DORA programme, and we will map our services to the five pillars, show you exactly what we contribute to your Register of Information and Article 30 obligations, and set out the resilience testing and incident support you need. You get a clear picture of how we close gaps rather than open them, before any commitment.