DORA has been live for over a year now, and the conversations we have with CySEC-regulated clients have shifted accordingly. The first wave was “what is this?” and “do we even have to comply?”. The second wave, the one we are mostly in now, is “we technically comply, but a supervisor asking the right question would expose us in five minutes.” This post is the version we tell those clients in a meeting.
It is written for one specific audience: technical leads and CTOs of CySEC-regulated investment firms in Cyprus whose back-office or middleware runs on PHP or Symfony. The conceptual parts apply more broadly, but the worked examples and the regulatory anchors are tuned to that setup.
What DORA is, briefly
The Digital Operational Resilience Act is EU Regulation 2022/2554, plus an accompanying directive amending several sector directives. It became applicable across the EU on 17 January 2025. It is a regulation, not a directive, so it applies directly in member states without national transposition. Cyprus, as an EU member state, is in scope on the same timeline as everyone else.
DORA exists because financial supervisors got tired of seeing ICT incidents handled as an operational footnote. It bundles what used to be scattered across guidelines, supervisory expectations, and informal good practice into a single binding regime with five concrete pillars: ICT risk management, ICT incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements.
The relevant European Supervisory Authorities (the EBA, ESMA, and EIOPA, together the ESAs) have issued a set of Regulatory Technical Standards and Implementing Technical Standards that put concrete numbers and templates behind the high-level text. CySEC, the national competent authority for investment firms in Cyprus, supervises compliance for CIFs and has published its own circulars and guidance pointing firms at the relevant ESA outputs.
For a PHP-shop CTO reading this, the practical message is: DORA is not a checklist your compliance officer handles. Almost every pillar lands on engineering decisions. The compliance team can run the paperwork, but they cannot answer the technical questions a supervisor will ask if you ever sit across from one.
Who it applies to in Cyprus
The short version: most CIFs are in scope, with proportionality.
The long version: DORA applies to a list of financial entities defined in Article 2, including credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central counterparties, trade repositories, fund managers, and several others. For Cyprus, that pulls in the CySEC-regulated categories that map to DORA’s financial-entity list, including CIFs, central securities depositories, trading venues, CASPs, AIFMs, and UCITS management companies. It also covers banks and relevant payment or e-money entities supervised by the Central Bank of Cyprus, plus Cyprus operations of EU credit institutions where the DORA scope criteria are met.
Proportionality is built in. Smaller and less complex entities have a lighter regime under the simplified ICT risk management framework. The thresholds and definitions for who counts as “microenterprise” or who falls under the simplified track are set in the text and in the ESA RTS, not in our heads. We do not eyeball this for clients. We confirm in writing against the current criteria.
For most readers of this post, the realistic case is “a small or mid-sized CIF whose PHP back-office runs in the EU, with a handful of critical ICT third-party providers, no internal model trading, and a compliance officer who already has too much on their plate.” That setup is firmly in scope, with significant proportionality on the testing pillar but minimal proportionality on incident reporting and third-party risk.
The five pillars and what they mean for a PHP back-office
ICT risk management
DORA expects a documented, governance-approved ICT risk management framework that covers the full lifecycle of the ICT assets used by the firm. For a Symfony back-office, the framework needs to be specific enough to actually describe your environment, not generic copy-and-paste.
The questions that supervisors are getting comfortable asking, and that you should be comfortable answering, look like:
- Which ICT assets support which critical or important functions, and where is that mapping kept up to date?
- Who approves significant changes to the production environment of your back-office, and is that approval flow auditable?
- What is the recovery time objective and recovery point objective for the systems that touch client funds or client positions, and how is that tested?
- How is access to production systems segregated from development, and how is privileged access logged?
For a PHP team, “the framework” usually maps to: an up-to-date system inventory (often a spreadsheet, sometimes a CMDB), documented deployment and change procedures (usually living in a wiki and in the CI pipeline), explicit RTOs and RPOs per critical service, and an access management story that survives an outside reader. The Symfony pieces themselves are easy. The discipline of keeping the documentation honest is the hard part, and it is the part supervisors will probe first.
ICT-related incident reporting
This is the pillar that surprises engineering teams most often, because it forces classification and reporting work on a clock.
Under DORA, ICT-related incidents must be classified using criteria defined by the ESAs, including impact on clients, geographical spread, duration, economic impact, data losses, and criticality of services affected. “Major ICT-related incidents” trigger a formal reporting flow to the competent authority on a defined timeline, with an initial notification, an intermediate report, and a final report.
In engineering terms, that means three things:
- You need logs and observability that are good enough to reconstruct the incident timeline and impact after the fact. Symfony Monolog config and your application performance monitoring stack are not optional for this. Centralised, searchable, time-aligned, retained for at least the period implied by the reporting cycle.
- You need a classification process that a non-engineer can run with engineering input. Most teams underbuild this and discover at first incident that the compliance officer cannot tell whether something is “major” without three hours of engineer time they do not have.
- You need a tested communication chain so that when a major incident happens, the timeline obligations do not slip while people argue over who emails whom.
Significant cyber threats are also reportable on a voluntary basis under DORA. Most firms ignore this. Some choose to use it strategically, especially around supply chain incidents that they want on the record.
Digital operational resilience testing
Every entity in scope has to do a basic programme of digital operational resilience testing, proportionate to its size and risk profile. This includes vulnerability assessments, network security testing, source code reviews where appropriate, performance testing, and scenario-based testing.
For a PHP back-office, the practical implication is: you need an actual testing programme, not “we run PHPStan in CI”. PHPStan and similar static analysis are useful as part of the picture, but the regulator is asking for a documented, scheduled, evidence-producing programme that covers more than just code linting.
A subset of higher-risk entities identified by the competent authority is also subject to threat-led penetration testing, conducted at minimum every three years, under a framework that has clear lineage from TIBER-EU. Whether you are in this subset is a question to answer in writing against the current criteria, not a question to guess. Most small CIFs are not in scope for TLPT. Most of the firms whose PHP back-offices we have worked with were not. The ones who were knew it.
ICT third-party risk management
This is the pillar that lands hardest on a typical PHP stack.
DORA expects a structured approach to ICT third-party providers, including a Register of Information that has to be maintained and submitted annually to the competent authority. For CySEC-regulated entities, CySEC’s 2026 guidance gives 28 February as the annual submission deadline, with a 31 December reference date. The register has to list ICT services used, criticality of each, contractual arrangements, location of data processing, and several other fields defined in the ESA ITS.
For a Symfony codebase, the real-world third-party population is larger than most teams initially realise. It includes:
- Your hosting provider and any managed Kubernetes or PaaS layer.
- Your database hosting (managed PostgreSQL, MySQL).
- Your email and transactional message providers.
- Your error tracking, APM, and observability platforms.
- Your CI/CD platform.
- Your authentication providers if you use one.
- Critical third-party libraries you depend on for regulated workflows (note: package dependencies are not always in scope as “ICT third-party services” under DORA’s definition, but the supervisory expectation is that you can describe them and the risks they carry).
The contractual content for arrangements supporting critical or important functions is non-trivial. DORA defines specific mandatory contractual provisions, including service level descriptions, location of data processing, audit rights, exit strategies, and cooperation with supervisors. If you signed a standard SaaS terms-of-service two years ago, those terms almost certainly do not satisfy DORA’s mandatory content for critical-function providers. You will need to renegotiate, or move providers, or accept a documented residual risk.
Critical ICT third-party providers can be designated by the ESAs and put under direct oversight. The first Union-level CTPP list was published in November 2025 and includes major cloud providers. Most providers in a typical PHP back-office are not designated, but the ones that are bring obligations that change the texture of the relationship.
Information sharing arrangements
DORA encourages, but does not require, financial entities to participate in information sharing arrangements on cyber threats and indicators of compromise. For a small CIF with a PHP back-office, this pillar is mostly procedural. Decide whether you participate, document the decision, and revisit it.
Proportionality: what smaller CIFs realistically have to do
The temptation to read DORA as “we have to do all of this” leads to over-engineering and missed deadlines. The text and the ESA RTS build in proportionality at multiple points.
A genuinely small CIF, running a Symfony back-office on a single EU region with a handful of providers and no internal trading models, realistically has to:
- Maintain a real, up-to-date ICT risk management framework, governance-approved, with the documents and inventories that prove the framework exists in practice and not just on paper.
- Run an incident classification and reporting process that can meet the DORA timelines, including communication chains tested at least annually.
- Run a documented resilience testing programme proportionate to the firm’s size, typically vulnerability scans, configuration reviews, scenario-based exercises, and source code review where the firm develops in-house. TLPT is usually out of scope.
- Maintain a Register of Information for ICT third-party providers, with contractual provisions for critical-function providers brought up to DORA’s required content.
- Decide and document the firm’s position on information sharing.
That is achievable for a small team. It is not achievable on the side of a sprint. Most firms we work with allocated dedicated engineer time over multiple quarters to get there, and we would not advise trying to fold it into a normal product roadmap.
What this actually looks like in a Symfony codebase
A few patterns we have seen work.
Structured logging is non-negotiable. Monolog with JSON formatting, channel separation between application, audit, and security events, centralised collection (we have used Elastic, Loki, and CloudWatch in different stacks), and retention configured to match the reporting cycle expectations. If your audit trail lives in var/log/prod.log on a single VM, that is a finding waiting to happen.
Audit logging belongs in domain code, not in middleware. A real audit trail covers business events (“user X opened position Y at time Z under role R”) and links them to system events (“HTTP request id, deployment hash, source IP”). Doctrine listeners can capture entity changes for free; the harder part is correlating to business actions. We tend to publish audit events through Symfony Messenger to a dedicated audit consumer, separate from the main app database, with retention controlled independently.
Configuration management is part of the framework. DORA expects documented control over significant changes. Your CI pipeline, your infrastructure-as-code repository, and your deployment approval flow are part of the evidence base. If they live in three different systems with no single audit story, the framework on paper does not match the framework in practice.
Backups and disaster recovery have to be tested, not just configured. Symfony, PostgreSQL, and a managed backup is the easy part. Restoring into a clean environment, validating data integrity, and timing the restore is the hard part. We schedule at least one full disaster recovery rehearsal per year for clients in scope, and we keep the artefacts (run logs, timing, decisions made) for the supervisor.
Third-party inventory lives next to your dependency graph. We have moved several clients off “the compliance team maintains the register” toward “the engineering team owns the register and the compliance team reviews it”. The register has to reflect production reality, and engineering is the only function that knows production reality.
Common mistakes we see
A short list, written from clients we have helped clean up:
- Treating DORA as a documentation exercise. Documents that do not match the system are worse than no documents at all.
- Assuming SaaS terms of service from before 2023 are DORA-compliant. They almost certainly are not, for critical-function providers.
- Mapping “critical or important function” too narrowly. Trading, custody, and client onboarding are obvious. Reporting pipelines that feed regulators are sometimes missed, and they tend to qualify.
- Underestimating the time required to classify an incident under DORA criteria. Build the runbook before the incident, not during.
- Confusing the Register of Information with a generic vendor list. The register has a specific structure defined in the ESA ITS. Use the template, not a freeform spreadsheet.
The honest summary
DORA is not a technical regulation in the sense of telling you what code to write. It is a governance regulation that lands on engineering because almost everything it asks for is implemented in your stack and your processes, not in your policies. For a CySEC-regulated firm running a PHP or Symfony back-office in Cyprus, compliance is doable, but it is engineering work, not paperwork.
If you are reading this and your firm has not yet treated DORA as an engineering responsibility, the simplest first step is to ask: “Who, on the engineering side, can answer a supervisor’s questions about our ICT risk framework, our incident classification process, our resilience testing programme, and our third-party register?” If the answer is “we’d have to get back to them”, you have your starting point.
We help firms in exactly this position, and we would rather have an early honest conversation than an expensive remediation later.
References
- DORA, Regulation (EU) 2022/2554: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Companion Directive (EU) 2022/2556: https://eur-lex.europa.eu/eli/dir/2022/2556/oj
- ESAs joint guidance on DORA RTS and ITS: https://www.esma.europa.eu, https://www.eba.europa.eu, https://www.eiopa.europa.eu
- CySEC, circulars and guidance on DORA implementation: https://www.cysec.gov.cy
- TIBER-EU framework, ECB: https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu
