The Digital Operational Resilience Act has been fully applicable since 17 January 2025. The European Supervisory Authorities published the first list of critical ICT third-party providers on 18 November 2025.
National competent authorities — BaFin, FCA, ACPR, CSSF, CNB, FINMA-equivalents — are working through their first full DORA-era supervisory cycles right now. And inside the perimeter of regulated entities across the EU and the UK, Oracle Forms applications continue to run loan books, policy administration, claims handling, payment reconciliation, trade settlements, and KYC remediation — often in production, often with no exit plan, often with monitoring and recovery testing capabilities that DORA’s authors did not have in mind.
The mismatch is structural, not cosmetic. Oracle Forms was designed for a world of trusted intranets, stable desktops, and quarterly release cycles.
DORA was written for a world of continuous monitoring, threat-led penetration testing, four-hour incident classification windows, and documented exit strategies from concentrated third-party dependencies. The two architectures don’t meet in the middle.
This article is for the people who sit on the regulatory side of that mismatch — CROs, Heads of ICT Risk, Internal Audit functions, compliance officers — and for the CIOs and IT leaders who are now being asked by them to do something about it.
It maps DORA’s five pillars against where Forms-based estates actually fail, explains what the next supervisory cycle is likely to surface, and lays out what a defensible remediation plan looks like.
DORA is structured around five pillars, each backed by Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that have been progressively published by the ESAs through 2024 and 2025.
Pillar 1 — ICT risk management framework (Articles 5–16). Regulated entities must maintain a board-approved ICT risk framework covering identification, protection, detection, response, and recovery. The framework must be reviewed at least annually, and after every major ICT-related incident. ICT systems must be appropriately documented, classified by criticality, and continuously monitored. Patch management, vulnerability management, cryptographic controls, and identity and access management are all specified in detail.
Pillar 2 — ICT-related incident management, classification and reporting (Articles 17–23). Entities must detect, manage, and notify ICT-related incidents. Major incidents must be reported to competent authorities on a defined timeline: initial notification within 24 hours of classification, intermediate report within 72 hours, and a final report within one month. The classification criteria (geographical spread, data losses, criticality of services affected, economic impact, reputational impact, duration, clients affected) are defined in the RTS.
Pillar 3 — Digital operational resilience testing (Articles 24–27). All entities must conduct a comprehensive ICT testing programme proportionate to their size and risk profile. Significant entities — credit institutions, central counterparties, central securities depositories, and certain others — must additionally perform Threat-Led Penetration Testing (TLPT) at least every three years, following the TIBER-EU framework and the DORA-specific RTS.
Pillar 4 — ICT third-party risk management (Articles 28–44). Entities must maintain a register of all contractual arrangements with ICT third-party providers, distinguishing those supporting “critical or important functions”. Contracts for critical functions must contain specific provisions on availability, security, business continuity, audit rights, exit strategies, and subcontracting. The Lead Overseer regime designates certain ICT third-party providers as “critical” — subject to direct supervisory oversight by the ESAs, with the power to impose periodic penalty payments of up to 1% of average daily worldwide turnover for non-compliance.
Pillar 5 — Information and intelligence sharing (Articles 45–49). Voluntary arrangements for sharing cyber-threat intelligence between financial entities, with safeguards under GDPR and competition law.
The penalty regime for financial entities themselves (Article 50 and national transpositions) reaches up to 2% of annual worldwide turnover, with member states also empowered to impose criminal sanctions in some jurisdictions. The ESAs and competent authorities can additionally require remediation plans on fixed timetables, with periodic penalty payments for non-compliance.
Mapping a typical Forms-based application against DORA produces consistent findings across institutions. Six are common enough to be near-universal.
Continuous monitoring is structurally limited (Article 9–10). DORA requires the ability to detect anomalous activity in real time and to support the entity’s SIEM and SOC operations. Oracle Forms applications, particularly older ones, lack the structured event emission, granular audit hooks, and API-level instrumentation that modern detection requires. You can log database access, but you cannot easily emit a structured event stream that captures user behaviour inside the Forms application itself. For systems classified as supporting critical functions, this is increasingly being raised in supervisory dialogue as a control gap.
RTO and RPO testing is hard to evidence (Article 11, 24–25). Single-server, stateful, JDK-dependent runtimes are difficult to subject to the kind of chaos-engineering and failover testing that DORA’s resilience testing programme expects. Many institutions discover during their first DORA-era recovery test that their actual measured RTO for Forms applications materially exceeds the documented target — sometimes by hours, occasionally by days. Auditors are now asking for evidence of tested RTO/RPO, not just documented RTO/RPO.
Patch latency creates a documented vulnerability window (Article 9). Oracle ships Critical Patch Updates quarterly. The January 2026 CPU included 51 Fusion Middleware patches, 47 of them remotely exploitable without authentication. Forms 14c and 12.2.1.19 are the only versions receiving security patches; older versions on Sustaining Support do not. The lag between Oracle releasing a patch, the bank or insurer’s change management process applying it across production, DR, and non-production environments, and the next supervisory cycle reviewing the patch evidence is the window that auditors are now measuring.
Threat-led penetration testing is difficult to perform meaningfully (Article 26–27). TLPT against a Forms application is awkward. The attack surface is unusual (signed JAR, FSAL launcher, WebLogic, the Forms server, the database). Penetration testers experienced in modern web and API testing often have limited Forms-specific experience. Reports tend to come back with a high proportion of “out of scope” or “architecture-driven” findings — which is exactly the language a regulator picks up.
Exit-planning credibility is weak (Article 28, 30). DORA requires documented exit strategies for ICT third-party arrangements supporting critical functions. Oracle has been formally designated by the ESAs among the critical ICT third-party providers. That designation does not prohibit using Oracle products — but it raises the bar for the exit plan. A loan-servicing system running on Oracle Forms, Oracle WebLogic, Oracle JDK, Oracle Database, and Oracle Cloud Infrastructure has a multi-vendor exit story that is, on inspection, not credible without years of preparation. Supervisors are increasingly asking what “exit from this stack” would actually look like, not whether it has been documented in the abstract.
Concentration risk is escalating, not flat (Article 28). The Oracle Java SE Universal Subscription, the move to JDK 17/21 LTS for Forms 14c, the wind-down of older Fusion Middleware versions, and the consolidation of Forms into a narrowing version window — these are tightening the dependence on a single critical third-party provider, not loosening it. Risk committees are now being asked to explicitly approve increasing concentration on a designated critical TPP, with the documentation required.
The first full audit cycle under fully-applicable DORA is now in flight. Patterns are emerging from supervisory letters, JST findings, and Section 166 reviews across multiple jurisdictions.
Concentration risk is being scrutinised entity by entity, not at the sector level. Where in previous years a generic acknowledgement of “we use Oracle / Microsoft / AWS” was acceptable, supervisors are now asking for the specific list of critical or important functions supported by each designated critical TPP, the documented exit strategy for each, and evidence that the exit strategy has been tested or at least exercised.
RTO/RPO actuals are being challenged. Several supervisors have moved from accepting documented RTO/RPO targets to requiring tested-and-evidenced RTO/RPO. For Forms applications, this is where the gap between target and actual most often surfaces. A documented 4-hour RTO that tests to 11 hours under controlled failover conditions is now a finding, not a footnote.
Sustaining Support is being treated as a vulnerability. Where Forms applications are running on Fusion Middleware versions no longer receiving security patches, supervisors are increasingly requesting either (a) a documented migration plan with a fixed end date or (b) compensating-control evidence at a level that most institutions struggle to produce. “We are aware and monitoring” is no longer accepted as a closing position.
Incident reporting capability is being stress-tested. DORA’s four-hour classification window is tight. For incidents originating in or affecting legacy Forms applications, several institutions have discovered that the time from incident detection to formal classification routinely exceeds 24 hours, because the application’s logging and forensic capabilities do not support faster determination. This becomes a finding under Article 19.
The supervisory tone matters. National competent authorities have signalled clearly that the first cycle is intended to be calibration, not aggressive enforcement — but that subsequent cycles will be measured against documented remediation plans from the first cycle. The institutions that respond to first-cycle findings with credible, time-bound remediation get cooperative dialogue. The institutions that respond with “we’ll look at it” do not.
A typical mid-size financial-services Forms estate (100–250 applications) takes 12–24 months to migrate. A large estate (500+ applications) takes 18–36 months, often phased over a longer period. Programme initiation — assessment, business case, board approval, vendor selection, contracting — adds 3–6 months before delivery starts.
That arithmetic produces a planning problem most institutions have not yet confronted. An institution that initiates programme planning in Q2 2026 is realistically looking at:
That timeline crosses two to three full DORA supervisory cycles before producing the evidence pack that closes out the Forms-related findings. The institutions that started programmes in 2024 are now mid-flight and are entering the 2026 audit cycle with credible progress to demonstrate. The institutions that wait until late 2026 to start are positioning themselves to face three more supervisory cycles with the same findings open.
Counting backwards: to close out Forms-related DORA findings by the 2028 supervisory cycle, programme initiation needs to happen no later than mid-2026 for a mid-size estate, and no later than early 2026 for a large estate.
A migration programme that produces a technically modern application but fails to address the DORA-specific gaps is a missed opportunity at best. The remediation worth doing is the one that addresses the architecture-driven findings, not just the user-interface complaints.
Instrument for monitoring, not just for users. The replacement architecture — whether APEX, Java, or hybrid — should emit structured event streams that integrate with the SIEM, support real-time anomaly detection, and produce the audit trail granularity that Article 9 contemplates. This is a design decision made at programme inception, not a feature added later.
Build testable RTO/RPO from day one. Stateless services, infrastructure-as-code, automated failover, regular chaos-engineering exercises — these are how RTO/RPO becomes a tested number rather than an aspirational target. The architecture should support DORA Article 25’s resilience testing programme, including TLPT scope, without architectural retrofit.
Reduce stack concentration where it materially matters. This is the most strategically charged decision in the programme. For some institutions, the right answer is to stay on Oracle Database and migrate to APEX — accepting continued Oracle dependence at the database tier but eliminating Forms, WebLogic, and Java SE Subscription exposure.
For others, particularly those with strong policy preferences against concentration on a designated critical TPP, the right answer is to migrate to a more diversified stack (Java microservices, containerised, on a non-Oracle cloud) even at higher initial programme cost. Both are defensible. The wrong answer is to make the decision without consciously addressing the concentration question.
Produce an exit-tested architecture. DORA Article 28 expects exit strategies that are credible, not theoretical. The migration is itself the exit from Forms — but the destination should be one from which a further exit is also conceivable. Open standards, portable code, documented data formats, and minimal proprietary lock-in at the application tier matter for the next supervisory cycle, not just this one.
Migration programmes that produce strong DORA evidence look different from migration programmes that produce strong technical outcomes alone. The discipline is to produce both in parallel and to involve Internal Audit, Risk, and Compliance from programme inception, not at UAT.
The evidence pack that closes findings, wave by wave, typically contains:
This evidence pack is what gets handed to supervisors and external auditors at each cycle. The institutions that build it as they go close findings smoothly. The institutions that try to assemble it retrospectively at the end of the programme find that the evidence is incomplete and that the early-wave decisions can no longer be reconstructed.
For institutions not yet in flight, three concrete steps make sense in this order.
First, baseline your Forms estate against DORA explicitly. Not a generic legacy inventory — a DORA-articulated assessment that classifies each Forms application against Article 8 criticality, documents measured (not target) RTO/RPO, identifies monitoring and detection gaps, and explicitly addresses concentration risk on Oracle as a designated critical TPP. The baseline produces both the regulatory remediation plan and the migration business case.
Second, get Risk, Compliance, and Internal Audit into the programme governance from day one. The DORA evidence pack is materially cheaper to produce as you go than to assemble retrospectively. The institutions getting this right are running joint IT-and-Risk steering committees, with Internal Audit performing pre-implementation reviews on each wave rather than post-implementation audits.
Third, commission an independent migration path assessment. The destination decision — APEX, Java microservices, hybrid, with explicit consideration of concentration risk — is the one with the largest downstream consequences.
A four-to-eight-week structured assessment, performed independently of the eventual implementation contract, produces a defensible plan and protects the institution from the much more common error of letting the destination be chosen by the vendor relationship rather than by the analysis.
The next audit cycle is already in flight. The one after that is closer than it looks. Institutions that begin programme initiation in the first half of 2026 are positioning themselves to close DORA-related Forms findings by 2028. Institutions that wait are positioning themselves to face the same finding through three more cycles.
Pretius runs DORA-aligned Forms migration assessments and delivery programmes for banks, insurers, asset managers, and payment institutions across the EU and UK. We are vendor-neutral by design, and our assessments produce the regulator-credible evidence pack alongside the technical plan. Book a 30-minute discovery call to discuss your specific estate, or request a sample redacted migration path assessment to see what the deliverable actually looks like.
