IT where every change is traceable
At banks and insurers an auditor can ask afterwards who did what, and when. We work with change windows, four-eyes approval on production and logging that survives an audit, so a security update does not turn into a finding.
Here the trail matters as much as the result
Doing it right is half. The other half is being able to show afterwards that it went that way.
In a financial environment a change is rarely just a technical act. It comes with a request, an approval from somebody other than the person doing it, a window in which it is allowed, and a record that can still be followed months later. That feels slow if you come from another sector, but it is exactly what a regulator expects and what makes an incident explainable afterwards.
We set management up for that from the start. Not by putting a form on top of it, but by letting the evidence come out of the work itself: who requested the change, who approved it, when it ran, what the fallback was and whether it was used. That is not extra weight; it is the administration you need anyway, only without somebody keeping it separately.
What DORA asks of you
The Digital Operational Resilience Act has applied to financial institutions in the EU since January 2025 and moves the conversation from security to demonstrable resilience. You need to know which ICT services are critical, who supplies them, what happens if one fails and whether your recovery has ever been tested. Your suppliers fall under it too: outsourcing does not move the responsibility with it.
What we do about that is concrete. We record the recovery time per service, test it and show the outcome; we keep a register of what we run for you and where it sits; and we make sure you have an exit that exists in more than principle. Alongside DORA there is NIS2 and the GDPR, and those three ask partly the same things in different words. Our own processes are covered by ISO 9001, ISO/IEC 27001, ISO 14001 and Kiwa NEN 4400-1.
Access is at its strictest here
Who can reach which data is not a setting in this sector but a decision. Rights follow the role rather than the person, elevated rights apply temporarily rather than permanently, and every use of them can be traced. Speed matters at joining and leaving: an account still alive after somebody has gone is the finding that recurs most often, and the easiest one to prevent.
What we handle in financial environments
You choose what you need. It all sits under one contract, one report and one point of contact.
- Change management with four-eyes approvalEvery production change has a requester and a second approval, a recorded window and a fallback thought through in advance rather than during.
- Logging that survives an auditRecording who could reach what, when it happened and which elevated rights were used, retained and searchable without hunting.
- Role-based access, temporary where it can beRights follow the role, elevated rights apply for a bounded period, and accounts close immediately when permanent or contracted staff leave.
- Demonstrable recoveryRecovery times agreed per system, tested annually and with the outcome on paper, so under DORA you can show it works rather than that it exists.
- Sight of your ICT chainA current overview of what we run for you, where it sits and what happens if a part fails, in a form that fits your own register.
- Exit without dependencyDocumentation, passwords, licences and setup are yours and come with you. Under DORA an exit plan that works is a requirement, not a wish.
How we take over a financial environment
Carefully and in this order, because here a surprise during the transition becomes a finding.
Look first, touch nothing
We walk along, read the existing procedures and the last audit findings, and map which changes are in flight. Only once that picture is right does anything get touched.
Recording the chain and the frameworks
Which ICT services are critical, who supplies them, which link is fragile and what DORA, NIS2 and the GDPR actually ask. That sets the order for everything else.
Agreeing windows, approvals and response times
When changes are allowed, who gives the second approval, what response time belongs to which service. That goes into an SLA in plain language, with 24/7 cover where it is needed.
Showing rather than claiming
The reporting gives volumes, lead times and recurring causes, and the recovery test produces an outcome on paper. Both are usable in your own accountability.
The services that come up most here
These building blocks come up most often in a financial environment.
Looking further
Recognise the picture but work in another industry? Have a look at the other sectors.
Tell us which finding you do not want again
Name the systems that are critical and the requirements you have to meet. We build the change process, the record keeping and the recovery test around those.