IT Platforms for Banking and Financial Services
DORA Article 9 requires demonstrable technical risk management at the system level. Your JBoss cluster processes payment transactions daily. What do you show the BaFin examiner?
DORA has placed IT operations directly under banking supervision. Core banking platforms running on JBoss EAP and RHEL need documented baselines, machine-readable audit trails, and automated compliance evidence. Not as project documentation provided after the fact. As an operational standard.
What DORA actually requires of your IT platform
DORA is not a process framework alone. Article 9 mandates technical measures at the system level. For JBoss platforms in banks, this translates into concrete operational requirements that manual operations cannot meet.
- Article 9 — ICT risk management Technical measures for identifying, protecting against, and detecting risks at the system level. Hardening standards must be defined and demonstrable, not merely intended.
- Article 9 — Change control Every change to an ICT system must be controlled, documented, and traceable. Ticket-based manual change management does not meet this standard.
- Article 11 — Operational resilience ICT systems must be recoverable to a defined state. Without a defined target state, there is no reproducible recovery path to demonstrate to supervisors.
- Article 17 — Incident classification Incidents must be traceable in relation to the configuration state of affected systems. Configuration drift is a direct contributing factor to incident risk.
- Defined baseline per instance Every JBoss EAP instance needs a documented target state: hardening standard, policy ID, scope, and exception log. Not in a wiki. As a versioned artifact.
- Machine-readable audit trail Every configuration change to JBoss or RHEL needs an author, timestamp, justification, and approval where required. Git-based configuration management is not optional — it is the requirement.
- Documented exceptions Where hardening rules cannot be applied for operational reasons, a risk decision with written evidence is required. Not a ticket. A policy exception with an ID and an approval record.
- Traceable configuration state In the event of an incident, the exact configuration state at the time of the incident must be reconstructable. This requires continuous state tracking at the system level.
What a typical banking platform looks like
Core banking platforms are not greenfield installations. They have grown over years, maintained by different teams, and now carry the weight of regulatory requirements that did not exist when they were built. DORA requires this to change.
Core banking and payment processing
JBoss EAP runs as the middleware layer beneath core banking applications: account management, payment processing, and credit scoring. Business-critical. Narrow maintenance windows. Zero tolerance for unplanned downtime.
Problem: Configurations have grown ad hoc, are inconsistent across instances, and have no defined target state. Hardening is undocumented. Changes are scattered across tickets and wiki pages.
Operating system foundation
RHEL servers form the base for JBoss EAP and other system components. Manually maintained, with varying configurations across teams and environments.
Problem: No uniform hardening baseline. Security patches applied reactively. Configuration knowledge tied to individuals. When people leave, context leaves with them.
Employee access and identities
Windows servers and Active Directory control employee access and permissions. GPOs managed manually, groups accumulated historically over time.
Problem: Permissions not systematically maintained. No automated compliance checks. Changes are difficult to trace after the fact.
Each of these layers is operated manually by specialists. When those specialists leave, the configuration knowledge leaves with them. DORA requires this pattern to end structurally. Not through documentation projects. Through automation that produces auditability as a technical outcome.
What BaFin examiners find in manually operated environments
BaFin examiners ask specific technical questions. The answers from manually operated JBoss environments follow a familiar pattern.
Compliance frameworks for banking and financial services
Banks operate under a dense web of overlapping regulations. lennlay addresses the technical platform layer — the area where supervisory examinations most consistently reveal evidence gaps.
Digital Operational Resilience Act. ICT risk management, resilience testing, incident reporting, and third-party oversight. Articles 9 and 21 directly target the technical platform layer.
IT systems and processes with adequate documentation. Direct BaFin requirement. Operating platforms without traceable documentation is a MaRisk non-compliance finding.
Supervisory requirements for IT in banking. Hardening, documentation, change control. BAIT operationalizes MaRisk at the technical level and serves as a direct basis for examination.
EBA Guidelines on ICT and Security Risk Management. The European framework underpinning DORA and national requirements. Covers ICT risk management at the system level.
Banks above a defined threshold qualify as critical infrastructure. Special obligations for IT security measures, evidence documentation, and mandatory reporting to the BSI.
NIS2 implementation act. Banks as essential entities. Technical security measures, risk management requirements, and mandatory incident reporting obligations.
Concrete services for regulated banking platforms
No generic platform promises. These six service areas directly address the evidence gaps that BaFin examiners consistently find in JBoss environments.
Defined JBoss baselines
CIS Benchmarks-referenced hardening for JBoss EAP instances. A policy artifact with an ID, effective date, scope, and exception log. Machine-readable, auditable, and reproducible. Not in a wiki. As a versioned document with a full change history.
Automated audit trail
Git-based configuration management. Every change to JBoss or RHEL is a commit: author, timestamp, justification, and approval. BaFin examiners can query any past configuration state at any point in time.
Compliance scan and report
Automated scanner runs against live JBoss and RHEL instances. Structured output ready for direct use by BaFin examiners and internal audit. No manual assembly. No scrambling before an examination.
GIaaS JBoss baseline
Hardened JBoss EAP as a managed, policy-governed artifact. Policy, build, package, deliver. Not maintained by your team. Owned, versioned, and lifecycle-managed by lennlay. GIaaS does not sell images. GIaaS sells security, accountability, and audit confidence.
EaaS for critical phases
Marcel König (RHCA/RHCE) and Matthias Siegl (RHCE) available for embedded engagements. Migration support, DORA readiness, platform hardening. Certified Red Hat experts with a defined scope and transparent approach.
Lifecycle management
JBoss EAP EOL tracking, security updates structured and traceable. No reactive patch management. Migration from JBoss EAP 7 to EAP 8 with a documented transition state and a clear rollback plan.
Which situation fits yours?
DORA is in force. The examination is coming.
DORA has applied since January 2025. Your platform documentation does not yet meet the requirements of Article 9. Time is running. BaFin examiners will ask for specific technical evidence — not concept papers.
lennlay delivers within 4 to 8 weeks: documented JBoss baselines, an automated audit trail, and a first compliance scan report ready for examination use.
The last audit found gaps. The next one expects evidence of closure.
Internal audit or an external examiner has raised findings on platform hardening, documentation, or change control. A remediation plan is expected. The follow-up examination will want to see technical implementation, not updated documents.
lennlay implements the remediation measures technically and delivers the evidence documentation the follow-up examination expects.
Core banking runs on JBoss 7.x. End of support is approaching.
JBoss EAP 7 is reaching end of life. The migration need to EAP 8 is known. The risk: migrating during live core banking operations without a defined transition state. A production stop is not an option.
lennlay manages the migration with defined transition states, a rollback plan, and complete documentation for internal audit and the supervisory authority.
Platform check for regulated financial environments
15 minutes is enough to assess where your JBoss platform stands today and what DORA specifically requires of it.
Non-binding · No sales pitch · Confidential
