Now in its second year of enforcement, the Digital Operational Resilience Act (DORA) is being taken seriously by financial services organizations across Europe. One of the defining characteristics of the regulation is that it applies equally to a one-person security function and a team of fifty. The core requirements remain the same; DORA does not scale with your organization's size.
What does change is how those requirements are met. As we discussed in our previous blog, organizations that invested early in preparing for DORA are now seeing the benefits. If 2025 was the year to establish the framework, then 2026 is the year that the framework is being tested by auditors and regulators.
Lean Teams
For lean security teams, organization and automation are often more valuable than size. A well-prepared small team is in a stronger position than a larger team still dependent on manual processes. Those manual processes are also the first to fail under DORA. Maintaining Excel-based asset registers, manually collecting key risk indicators (KRIs), and assembling evidence packs at the last minute simply do not scale for ongoing compliance.
DORA expects continuous evidence collection rather than periodic snapshots. Auditors want to see the current state of your environment, not how it looked last quarter. Evidence should already exist when an auditor arrives - it should not be assembled in response to an audit request.
Where controls cannot be fully implemented, document the constraint and record the compensating control. Don't exclude an asset or ignore a gap in the hope that it goes unnoticed. A documented exception is far easier to defend than an undocumented omission.
The same principle applies to audit evidence. Build your evidence trail continuously rather than immediately before an audit. If you're creating your audit trail after receiving an audit notification, you've already missed one of DORA's fundamental expectations.
For lean teams, automation is no longer a nice-to-have - it is essential. Automated evidence collection, continuous monitoring, and automated KRI reporting allow small security functions to remain compliant without becoming overwhelmed by administrative work.
This becomes particularly important when dealing with regulators such as BaFin, which can request evidence at any time. Being permanently audit-ready is significantly easier than preparing under pressure.
Documentation Is Evidence, Not the Goal
One of the biggest misconceptions about DORA is that compliance is achieved by producing documentation. In reality, documentation is simply the evidence that your operational processes are working.
Policies, procedures, and risk registers are important, but regulators are increasingly looking for proof that those documents reflect the day-to-day reality of your environment. If your vulnerability register says critical vulnerabilities are remediated within seven days, your evidence should demonstrate that this is consistently happening. If your ICT risk policy states that assets are continuously monitored, auditors will expect to see the monitoring data rather than simply the policy itself.
For lean teams, this means focusing less on creating additional paperwork and more on ensuring that existing operational activities automatically generate evidence. Every configuration scan, vulnerability assessment, policy check and remediation activity should contribute towards demonstrating compliance.
Instead of treating governance and security operations as separate activities, DORA encourages organizations to integrate them. The stronger the connection between day-to-day security work and compliance evidence, the less time small teams spend preparing for audits and the more time they can devote to reducing operational risk.
A good example comes from a European bank Mondoo helped, where a lean security team achieved DORA compliance within a €20 billion financial institution. Using Mondoo, the team established its scan results as the hardening baseline, documented exceptions for shared infrastructure, and automated KRI collection that had previously required significant manual effort. When auditors requested evidence, the team was able to generate the required reports immediately rather than spending days compiling documentation.
Start Small and Grow
Their approach also demonstrates another important lesson: start small and expand gradually. Rather than attempting to cover every system simultaneously, focus on one environment or asset type first. Build a robust process, then extend it across the organization. One control implemented properly is worth far more than several implemented inconsistently.
If you're unsure where to begin, your existing scan results provide an excellent baseline. Instead of trying to map DORA onto hundreds of existing controls, start with what your environment already tells you. Define those findings as your baseline, validate each requirement against your environment, and document any justified exceptions.
This approach shifts vulnerability management away from simply identifying issues and towards measurable remediation. DORA is ultimately concerned with reducing operational risk, not producing reports.
One of the biggest European Banks also illustrates the realities of shared infrastructure. It relies on a shared IT service provider for many core services and technology platforms. While that provider manages much of the underlying infrastructure, responsibility for DORA compliance remains with the bank itself.
Document the Differences
Shared infrastructure is not an exemption from compliance. Where platform configurations differ from recognized frameworks such as the CIS Benchmarks, organizations should document those differences, record the associated risk, and explain the compensating controls that are in place.
This principle extends to third-party risk management more broadly. DORA requires organizations to continuously monitor ICT suppliers, contracts, and outsourced services. Supplier registers cannot become static documents. Every new supplier, contract amendment, and service exit should be reflected in the system continuously. A spreadsheet last updated eighteen months ago is unlikely to withstand regulatory scrutiny, particularly as supervisory authorities increasingly automate cross-checking and evidence validation.
It's also important to remember that DORA's scope continues to expand. From January 2027, Germany's Financial Market Digitalization Act (FinmadiG) will extend DORA to include factoring institutions and financial leasing providers that were previously outside the European framework.
Although these organizations can adopt a simplified ICT risk management framework, they will still be required to comply with DORA. At the same time, legacy German supervisory frameworks such as BAIT, VAIT, ZAIT, and KAIT will be fully retired, making DORA the single operational resilience framework across the German financial sector.
Conclusion: Operational Maturity Outperforms Scale
Ultimately, DORA is not a project with a finish line. It is an operational discipline built around continuous monitoring, continuous evidence collection, and continuous improvement. Organizations that treated DORA as a one-off compliance exercise are already discovering that maintaining compliance is far more challenging than achieving it.
The organizations succeeding under DORA are not necessarily those with the largest security budgets or teams. They are the ones who have embedded resilience into their daily operations, replaced manual effort with repeatable processes, and can demonstrate compliance at any time.
For lean security teams, perhaps DORA's biggest lesson is that operational maturity will always outperform operational scale. This is no longer about preparing for the next audit; it is about being ready every day.
