In this article
The Digital Operational Resilience Act has been in force across the EU since January 2025. Its ICT risk management requirements highlight software change:
Article 9(4)(e) asks that changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner, and the supporting technical standards go further still.
These are the areas where Cytix works and this guide will show you how.
Operationalising DORA in your SDLC
Most organisations can evidence a controlled security decision for the changes they reviewed. The difficulty is evidencing the volume that went through untouched and where there’s no record of why.
Cytix puts a security decision against every change as it happens. Each ticket, PR and release is read for context, then run through three questions:
does it matter?
what could go wrong?
what is a proportionate security response?
Every question is then reported back to the change that triggered it. That way, the decision, the reasoning and the outcome stay attached to the change that caused them.
DORA requirements and how Cytix maps to them
How Cytix maps to DORA (Regulation (EU) 2022/2554) and the ICT risk management technical standards (Commission Delegated Regulation (EU) 2024/1774).
Clause
Requirement
How Cytix Maps
Article 6 (1)
Maintain a documented ICT risk management framework
Cytix supplies the change-level layer of that framework: a recorded risk qualification for every software change, feeding the framework you already operate rather than replacing it.
Article 8 (1)
Identify and classify ICT-supported functions, assets and dependencies
Every ticket, PR and release is read for context; the asset, the environment, the history. The picture of what changed stays current instead of being reviewed on a cycle.
Article 8 (2)
Identify sources of ICT risk on a continuous basis
Cytix reviews application changes continuously, using SDLC telemetry and contextual analysis, to identify the ones that could introduce exploitable risk.
Article 9 (2)
Monitor and control the security of ICT systems and tools
Cytix evaluates changes affecting security-relevant functionality, including access control logic, cryptography and externally exposed interfaces. It works on change, not on the running estate.
Article 9 (4) (e)
Changes recorded, tested, assessed, approved, implemented and verified in a controlled manner
Cytix covers assessed, tested and verified, and records each against the change that caused it. Approval and implementation stay in your own change process, under your policy.
RTS Article 17 (1) (a)
Verification of whether ICT security requirements have been met
Cytix assesses each change against security requirements before release, and the result is attached to the change rather than filed separately.
RTS Article 17 (1) (h)
Identify a change’s potential impact on existing ICT security measures
Cytix performs security impact analysis on each change, identifying effects on authentication, authorisation, privilege handling and sensitive data processing.
RTS Article 17 (1) (f) and (g)
Manage emergency changes with adequate safeguards, and re-evaluate them afterwards
Emergency changes force bad decisions. Cytix fast tracks the security response so the right decision is also the fastest, and leaves the post-implementation record those changes need.
RTS Article 10
Vulnerability and patch management
Cytix tests changes as they are introduced, tracks identified vulnerabilities through remediation and retests to confirm closure. The article also requires weekly automated scanning of assets supporting critical or important functions, oversight of third-party vulnerability handling, open-source library tracking, responsible disclosure and patch management, which sit outside Cytix.
Articles 17 to 19
Incident management, classification and reporting
When an incident traces back to a change, the decision, the reasoning and the outcome are already attached to that change, so the causation narrative does not have to be reconstructed from tickets and old reports. Cytix does not file regulatory reports.
Article 24 and Article 25
Operate a digital operational resilience testing programme, including tests of all systems supporting critical or important functions at least yearly (Art 24(6))
Cytix directs where testing effort goes by change risk and runs the resulting testing. The programme itself, its scope, and the at least yearly testing under Article 24(6) remain yours.
Defining Cytix's role
Cytix is a software change risk platform. It doesn’t approve your changes, file your regulatory reports, run your resilience testing programme or carry out threat-led penetration testing.
What it does is make the change risk understandable, route a proportionate response, and leave evidence attached to the change, so that the parts of DORA that turn on software change have a record behind them rather than a reconstruction.
If your organisation is outside the EU
DORA binds EU financial entities. It reaches firms elsewhere two ways: through EU group entities whose obligations become the group standard, and through the Article 30 contract terms EU customers flow down to their suppliers. If either applies to you, the change management requirements above are the ones that land first.
Sources
Regulation (EU) 2022/2554 (DORA), full text on EUR-Lex: eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
Commission Delegated Regulation (EU) 2024/1774, RTS on ICT risk management framework: eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng
Working on DORA compliance?
Link every security decision back to the individual change that triggered it. So compliance is an every day guarantee, whatever the release.
