Situation
A credit union in Šiauliai, Lithuania: 45 employees, two branches and online banking for members. The IT estate is small: a few servers, a core banking system hosted by an external vendor, and Microsoft 365 for e-mail and documents. One person is responsible for IT and also administered part of the business systems.
The DORA regulation (EU 2022/2554) has applied since January 17, 2025, and credit unions fall within its scope. During a scheduled inspection the supervisory authority asked for the documents of the ICT risk management framework, the incident logging process and evidence of resilience testing. The union had a risk assessment from earlier years, a few policies, and backups that were made but had never been restored from scratch.
The finance director came to us with a specific question: what do we need on paper and what do we need in reality, so that the inspection finds no non-compliance? The deadline was three months, ahead of the follow-up meeting with the supervisor.
What was needed
- An ICT risk register linked to business processes and critical systems.
- An incident management process with classification and the deadlines for notifying the supervisory authority.
- A register of third parties (ICT providers) with contract reviews and risk assessment.
- A working recovery plan: not only backups, but a tested recovery with a recorded time.
- A resilience testing programme that can be repeated every year without outside consultants.
- All of this with the resources of a small organisation and without a new hire.
What we did
Weeks 1-2: gap analysis
We started by reviewing the existing documents and infrastructure against a DORA requirements map. We compiled a list of critical functions: deposit and loan accounting, payments, member service, and reports to the supervisory authority. For each function we assigned systems, providers and responsible people. It turned out that the core banking vendor’s contract specified neither an RTO nor an audit right, which became a separate piece of work with the union’s lawyer.
Weeks 3-5: risk register and processes
We carried out a risk assessment using our methodology, aligned with ISO 27001 requirements and the DORA ICT risk management framework. The register ended up with 38 risks, 7 of them high. We prepared an incident management procedure with a classification that follows the DORA logic for reporting major incidents, and a simple logging form in the Microsoft 365 tenant. The provider register contains 14 ICT providers, each with a criticality score and the result of a contract review.
In parallel we trained the staff: two-hour sessions on recognising and logging incidents, and a separate session for management on its role during a recovery. This matters because DORA requires not only documents but also evidence that people know what to do.
Weeks 6-8: PlanB recovery
The technical part was PlanB infrastructure recovery in the MDP CLOUD cloud. The union’s server backups were already made with Veeam, but only to local storage. We added a copy in our data centre in Lithuania, and in the PlanB environment we prepared a pre-configured network, VPN and domain controller so that nothing has to be built from scratch during a recovery. The most complicated part was the core banking system at the external vendor: its recovery depends on the vendor, so we included the vendor’s contacts, escalation path and contractual RTO in the plan.
Weeks 9-10: drills
We carried out two recovery drills. In the first we restored the file server and the domain controller in the PlanB environment. It took 5 hours, an hour of which was lost to an incorrect DNS record. We corrected the procedure, and in the second drill all systems managed by the union were available within 4 hours. Both times we recorded the time, the participants, the problems and the decisions made, which is exactly the kind of report the supervisor asks for.
Result
The union submitted a document set to the supervisory authority: the ICT risk register, the incident procedure, the provider register with 14 assessed providers, the business continuity and recovery plan, and the reports of both drills. At the follow-up meeting there were no remarks on ICT risk management. The core banking vendor’s contract was amended with an RTO commitment and an audit right. That took the longest, but without it the provider register would have stayed a formality.
The most important number is the 4-hour RTO, which is not a promise but a measured result. Drills now take place twice a year on an agreed calendar; the next one is already scheduled with the person responsible for IT, with us taking part only as observers.
“Until then we had backups and believed they worked. Now we have a report that says how many hours it took and what did not work.”
The measurement is simple: each drill report records the actual recovery time, and the risk register is reviewed every quarter together with our DORA consultant.
What we would advise in a similar situation
- Start with critical functions, not document templates. The supervisor asks what happens to members if a system stops, not how many pages a policy has.
- Check ICT provider contracts early. A missing RTO or audit right takes months to negotiate.
- Test recovery at least twice before submitting to the supervisor. The first drill almost always reveals an error that was not in the plan.
- Write the drill report so that a board can understand it: the time, what did not work, what was changed.
