/802-regulations-dora

name: 802-regulations-dora
description: Use when reviewing, designing, or modifying Java enterprise systems that may support financial entities, critical ICT services, third-party ICT provider integrations, or operational resilience obligations under DORA. This should trigger for requests such as Review a Java platform for DORA ICT risk controls; Design operational resilience evidence for a financial service; Add incident, continuity, backup, recovery, or third-party ICT controls; Assess resilience testing and monitoring before production release. Part of Plinth Toolkit
license: Apache-2.0
metadata:
  author: Juan Antonio Breña Moral
  version: 0.18.0

DORA Regulation for Java Enterprise Digital Operational Resilience

Use this Skill to review Java enterprise applications, platforms, integrations, or operational workflows that may support financial entities, critical ICT services, important business services, or outsourced ICT provider relationships.

Apply this Skill to determine what engineering controls, operational evidence, and escalation paths are needed before the system is released, connected to production dependencies, or relied on for regulated financial operations.

This Skill is not legal advice. It helps Java engineers, architects, tech leads, platform teams, and reviewers identify when DORA concerns may apply and how to translate operational resilience expectations into enterprise architecture controls such as ICT asset inventories, incident detection, monitoring, backup and recovery, continuity plans, change control, third-party risk evidence, resilience testing, and audit-ready operational records.

The purpose of this Skill is to increase awareness of potential gaps in the system and create engineering evidence for qualified review. The response produced by this Skill does not represent legal advice, a legal opinion, or a final regulatory determination.

The main question is:

> When does a Java enterprise system require DORA-aware operational resilience controls, and what should developers build differently?

External reference: [DORA Regulation (EU) 2022/2554](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554).

DORA chapters summary reference: [DORA chapters summary](references/802-regulations-dora-chapters-summary.md).

Java engineering examples reference: [DORA engineering examples](references/802-regulations-dora-engineering-examples.md).

Questionnaire asset: [DORA engineering review questionnaire](assets/questions/802-dora-engineering-review-questionnaire.md).

Report template asset: [DORA engineering review report template](assets/reports/802-dora-engineering-review-report-template.md).

Scope

This Skill applies to:

• Java systems supporting financial entities, payment flows, trading, lending, insurance, investment, accounting, or regulated operations
• Platforms that provide ICT services to financial entities or important business services
• Spring Boot, Quarkus, Micronaut, and framework-agnostic Java services with operational resilience requirements
• Systems with critical databases, message brokers, job schedulers, batch workloads, APIs, IAM, secrets, observability, or infrastructure dependencies
• Third-party ICT provider integrations, cloud services, SaaS platforms, managed databases, messaging platforms, and external operational dependencies
• Incident detection, response, backup, recovery, continuity, change control, resilience testing, and operational evidence workflows

DORA Engineering Review

Treat DORA applicability and interpretation as governance decisions for legal, compliance, security, risk, resilience, and business-continuity owners.

Engineering teams should still create evidence that makes those decisions reviewable:

• Which business service depends on the Java system
• Which ICT assets, data stores, integrations, credentials, and providers are in scope
• Which incidents can be detected, triaged, reported, and reconstructed
• Which backups, recovery targets, continuity plans, and rollback paths exist
• Which third-party ICT risks are documented and monitored
• Which resilience tests prove controls work before production reliance

Constraints

Translate DORA concerns into engineering controls for Java enterprise systems. Do not provide legal advice or replace review by legal, compliance, security, risk, resilience, business-continuity, or procurement owners.

• **NOT LEGAL ADVICE**: Frame findings as operational resilience controls and escalation points; recommend qualified review for applicability, entity classification, reporting obligations, outsourcing, and regulatory interpretation
• **SCOPE FIRST**: Identify whether the system supports a financial entity, important business service, critical ICT function, or third-party ICT provider relationship before recommending controls
• **ICT INVENTORY**: Require traceable inventories for applications, data stores, queues, jobs, dependencies, credentials, providers, deployment environments, and operational owners
• **INCIDENT READINESS**: Verify detection, triage, severity classification, escalation, evidence capture, customer or regulator handoff, and post-incident review paths
• **RESILIENCE CONTROLS**: Review backup, restore, continuity, failover, rollback, capacity, monitoring, alerting, logging, and change-control evidence
• **THIRD-PARTY ICT RISK**: Do not treat cloud, SaaS, managed database, messaging, observability, IAM, or payment providers as invisible dependencies; record contracts, controls, SLAs, exit paths, and monitoring evidence
• **TEST EVIDENCE**: Prefer tested recovery procedures, chaos or failover exercises, incident drills, and restore verification over untested runbooks
• **AUDITABILITY**: Preserve operational evidence for incidents, changes, approvals, provider outages, recovery tests, monitoring signals, and control exceptions
• **TRUSTED EVIDENCE FIRST**: Answer questionnaire items from trusted local project evidence or maintaine