Operational resilience and technical compliance with DORA and NIS2
DORA (Regulation EU 2022/2554, applicable since 17 January 2025) and NIS2 (Directive EU 2022/2555) ask for something a document cannot deliver: managing and classifying incidents, proving that recovery works, knowing which providers you depend on and being able to demonstrate it with evidence. That part is engineering work, and it is the part we do: we build the process, the testing and the automated evidence collection on your infrastructure. It is a technical service that complements, and does not replace, legal or compliance advice.
Last updated:
What the regulation asks for that a document cannot hold
Who it is for
For financial entities and their technology providers, and for companies in energy, transport, health, water, public administration and the other sectors NIS2 treats as essential or important. In practice, for anyone who has to answer in writing to a supervisor, an auditor or a large customer's risk department.
What it solves
The technical side of compliance being improvised. There is a continuity policy, but nobody has ever tried restoring; there is an incident log, but no classification criteria two people would apply the same way; there is a provider list, but no map of which service falls when each one does. When the evidence request arrives, the team spends three weeks taking screenshots.
Where the limit of our work is
We are not legal advisers and we do not interpret the regulation for you: we do not decide whether you are an essential or an important entity, we do not draft the policies management signs, and we do not represent anyone before a supervisor. We work with whoever runs your compliance, take the technical requirements they hand us and turn them into processes, tests and evidence that actually exist.
What gets built
Classifiable incidents
Written severity and materiality criteria, with the decision tree, the notification deadlines and the templates. So that two different people classify the same incident the same way.
Tested recovery
Restore and failover tests on a schedule, with recovery time and recovery point objectives measured and the result recorded. Testing is the evidence; having backups is not.
Mapped dependencies
An inventory of assets and ICT providers, with which service depends on each one, what happens if it fails and what the exit is. Including the fourth-party dependencies nobody usually looks at.
What we hand over
Incident management and classification
A process written down and in use: detection, classification by severity and materiality, roles, deadlines, internal and external communications, and a log with everything that is asked for later. With the notification template prepared in advance, because the day of the incident is not the day to draft it.
Resilience and recovery testing
A test schedule with its scope: restoring backups, failing over between zones or providers, losing an external dependency and controlled degradation. Every test leaves measured objectives, deviations and actions, signed off and filed.
Inventory and dependency map
Assets, services and ICT providers with their criticality, the business function they support and an exit strategy for each one. Maintained as code, not as a spreadsheet that goes stale in three months.
Automated evidence
Evidence collection is automated: change records, test results, backup status, patching, access and periodic reviews are gathered on their own into a repository with dates and traceability. That is the difference between a three-week audit and a three-day one.
What is out of scope, plainly
Legal analysis, entity classification, the policies the management body signs, the relationship with the supervisor, and the threat-led penetration testing of the TIBER framework, which requires an accredited provider. For the first, your adviser; for a technical audit or conventional penetration test, we have a service of our own.
How we work
Technical gap
What the requirements you give us ask for, what is in place and what is missing. In writing, requirement by requirement, without interpreting the regulation.
Processes and criteria
Incident classification, deadlines, templates and roles. Tested against past incidents to see whether they really get applied the same way.
Testing and the map
A first round of recovery tests with measured results, and a dependency inventory maintained as code.
Evidence and the cycle
Automated collection, a test schedule and periodic review. Whatever does not repeat itself stops happening by the second quarter.
Frequently asked questions
Does this make us compliant with DORA or NIS2?
Not on its own, and nobody can promise that. Compliance includes governance, legal analysis and decisions by the management body that are not engineering work. What we do is the technical part — processes, tests, inventory and evidence — which without this is a policy with nothing behind it.
Does it replace our compliance adviser?
No, we work with them. What usually happens is that they pass us the applicable requirements and we return how each one is covered technically, with the evidence that demonstrates it.
Do you run the penetration tests DORA asks for?
We run technical audits and penetration testing as a service of our own. The advanced threat-led testing of the TIBER-EU framework requires an accredited provider, and we are not one: if you are asked for that, it has to be contracted from someone who is.
We supply a bank and they are asking us for this.
That is the most common case. DORA's requirements reach technology providers through the contract, and what you will be asked for is almost always exactly this: incident classification, recovery testing, a dependency map and evidence. It can be prepared before the customer's first audit arrives.
Do we have to change cloud provider to start?
No. Reliability work happens on what you already have, whether that is AWS, Azure, Google Cloud, a European provider or your own hardware. Migration is a separate service and only makes sense if there is a reason for it.
How long before we notice anything?
The noise goes first: an alert review usually shows results within the first few weeks, because a good share of what fires is not actionable. SLOs take longer, because they need measuring, and they are worth nothing until there are a few weeks of data behind them.
Do you sign a non-disclosure agreement?
Yes, if you want one, and nothing we see is used as an example anywhere without written permission. Access is requested at the minimum needed and documented.
What happens if we stop?
You keep everything: the SLOs, the runbooks, the infrastructure code in your repository, the dashboards and the documentation. There is no lock-in and nothing that only we know.
Tell us what you are being asked for
A customer questionnaire, a requirements list or a gap report is enough to start. We reply within 24 working hours.
or write to us at info@esdis.es