Proportionality trap: simplified DORA framework for a mid-sized payment institution
Helios Pay is an EU-authorised payment institution with 48 employees, 2.1 million card and account-to-account transactions per month, and no proprietary data centre. Its core ledger runs on two IaaS tenants from different hyperscalers, but both rely on the same identity provider and the same payment switch vendor. The board has read that DORA offers a 'simplified ICT risk management framework' and wants to adopt a one-page policy, arguing that Helios is small. The current control set consists of an annual external penetration test, a shared incident spreadsheet, and an outsourced service desk with a four-hour response target. Last quarter a misconfigured load balancer caused a 3-hour outage affecting 60,000 clients. The compliance officer asks you whether the simplified framework is available and whether the board can reduce oversight to a single annual review.
1. Can Helios rely on DORA's simplified ICT risk management framework? Explain what facts determine eligibility and what you would verify before advising the board.
Read the worked answer
Start by separating 'small' from 'eligible'. DORA's simplified framework is not a general small-entity exemption; it applies only to the categories listed in Article 16, and eligibility depends on legal status and applicable exemptions, not headcount or transaction volume alone. For a payment institution, verify whether it is exempt under PSD2 and whether the competent authority treats it as within the simplified scope. Also confirm whether Helios is part of a group or provides services that bring it into the full framework.
If Helios is not eligible, the full framework applies. If it is eligible, 'simplified' still requires a documented, risk-based framework: governance and accountability, identification of ICT assets and dependencies, protection, detection, incident management, business continuity, and third-party oversight proportionate to risk. A one-page policy with an annual review would not satisfy the minimum. The board can delegate operational tasks but not accountability. My advice would be conditional: confirm eligibility in writing, then map the existing controls to the required elements and close gaps before reducing oversight.
2. Assume Helios is not eligible. Identify the minimum management-body responsibilities that cannot be delegated to the outsourced service desk.
Read the worked answer
The management body remains accountable even when operations are outsourced. Under DORA governance requirements it should:
- approve and periodically review the ICT risk management framework and the ICT risk appetite;
- ensure the framework is supported by adequate budget, staff and training;
- define roles and reporting lines, including an independent ICT risk function and a clear owner for incident management;
- approve the third-party strategy and material outsourcing arrangements;
- oversee incident reporting, business continuity and testing outcomes, and challenge remediation. The outsourced service desk may execute incident intake, first-line checks or technical recovery, but it cannot own risk acceptance, classify major incidents without internal validation, approve exceptions, or decide whether to notify the competent authority. Those are internal control decisions. A single annual board review is too weak: the board should receive risk reporting at least periodically and after major incidents, and minute its challenges and decisions. This preserves accountability while allowing proportionate outsourcing.
3. What should the framework say about the shared identity provider and payment switch dependency?
Read the worked answer
The framework should treat these as critical dependencies, not just vendor contracts. First, identify the services, data flows and fourth parties behind the identity provider and payment switch, including whether both hyperscalers fail in the same way. Second, assess impact through a business impact analysis for the payment services: maximum tolerable downtime, recovery objectives, manual fallback and customer communication. Third, define concentration risk and exit options: contractual audit rights, service levels, subcontracting notice, data portability, and tested alternatives. Fourth, include scenario testing for identity-provider loss and payment-switch failure, not only cloud-region loss. Fifth, record the arrangements in the register of information. The board should approve tolerances for these dependencies and receive evidence that recovery assumptions have been tested. The point is to show that Helios understands correlated failure, not merely that it has two cloud logos.