DORA for investment firms: which regime applies to your firm
Most investment firms are in full DORA scope under Article 2(1), so the default assumption should be the full regime unless your firm qualifies for a narrower one. Small, non-interconnected investment firms may fall under the simplified ICT risk framework that Article 16(1) provides, which disapplies Articles 5 to 15 for those firms. The compliance lead's first task is to establish, in writing, which side of that line the firm sits on, because a regulator, client or contract now expects evidence that matches the regime that applies.
The classification decides the cost, the testing duties and the evidence you must produce. A full-scope firm must maintain the complete ICT risk management framework, the incident process and the testing programme, and must manage ICT third-party risk under a documented strategy. A firm in the simplified regime works from the requirements of Title III of Delegated Regulation (EU) 2024/1774, and it is relieved of threat-led penetration testing and of the third-party strategy under Article 28(2). Ask your legal or regulatory advisers to confirm the interconnectedness and size tests against your authorization, group structure and the MiFID II exemptions your firm relies on, and record the reasoning so an assessor can follow it.
The organization owns its controls and the management body remains accountable for them. An implementation partner can prepare systems, configurations and evidence for either regime, but only the competent authority supervising the firm, or an independent auditor where one is engaged, reviews that work and forms a view on it. Ask any partner to show how its scope will map to the regime you confirmed, and to name which evidence it will produce and which items the firm must still sign off internally.
What changes between full scope and the simplified framework
Investment firms that fall outside the simplified regime carry the complete DORA obligations. The ICT risk management articles apply in full, so the management body, the ICT risk management framework and the recovery arrangements must meet every requirement in Chapter II. The same firms also face the threat-led testing and third-party strategy requirements, because the exclusions in Article 16(1) do not reach them.
- ICT risk management framework: Articles 5 to 15 apply in full, covering governance, the framework itself, identification, protection, detection, response, recovery and learning.
- Register of information: Full scope firms maintain a register of their ICT third-party arrangements. Confirm the format and submission cycle with your competent authority.
- Incident reporting: Chapter III applies, including incident classification and reporting of major incidents.
- TLPT: The exclusion in Article 26(1) does not apply. Ask your competent authority how the threat-led testing selection criteria apply to your firm.
- Third-party strategy: The exclusion in Article 28(2) does not apply, so the firm must adopt and maintain a strategy on ICT third-party risk.
Confirm with your competent authority that your firm is in the full scope regime before you scope any remediation work.
Small and non-interconnected investment firms can fall under Article 16(1), which disapplies Articles 5 to 15. In their place, Title III of Delegated Regulation (EU) 2024/1774 (Articles 28 to 41) sets a simplified ICT risk framework. Article 28 of that delegated regulation makes the management body responsible for ICT risk, roles, objectives and a budget reviewed at least yearly.
- ICT risk management framework: The simplified framework covers governance, an information security policy, asset classification, ICT risk management, access control, operations security, security testing, change management, business continuity and a review report.
- Management and audit: The control and internal audit functions must be independent, and critical audit findings must be remediated in time.
- Register of information: Confirm with your competent authority whether and how the register of information applies to your firm under the simplified regime.
- Incident reporting: Articles 5 to 15 are the articles disapplied under Article 16(1), and Chapter III is not among them. Confirm with your competent authority how the incident classification and reporting duties apply to your firm.
- Exclusions: Entities under Article 16(1) are excluded from threat-led penetration testing under Article 26(1) and from the requirement to adopt a third-party risk strategy under Article 28(2).
The simplified regime depends on meeting the Article 16(1) criteria, so document your firm's status and get the authority's view in writing.
Choosing between the two regimes is a classification decision, not a self-declared one. The test depends on whether the firm is small and non-interconnected, and that status should be evidenced and reviewed as the business changes. The MiFID II side also matters, because Directive (EU) 2022/2556 aligns MiFID II requirements on ICT systems, algorithmic trading resilience, business continuity and regulated markets with DORA.
- Scope basis: Article 2 defines the financial entities in scope. Record the entity type and the legal basis for scope in a document the management body approves.
- Small and non-interconnected status: Confirm the criteria your competent authority applies to small and non-interconnected investment firms, and record the evidence for each criterion.
- MiFID II exemptions: Persons exempted under Articles 2 and 3 of MiFID II are excluded from DORA under Article 2(3). Confirm whether your firm relies on either exemption.
- MiFID II amendments: Map your existing MiFID II ICT, algorithmic trading and business continuity controls against the DORA requirements that apply to your regime.
- Periodic review: Reassess the regime when the firm's size, activities or interconnections change, and inform the authority if the classification changes.
Ask your competent authority to confirm the classification in writing, because the outcome determines which obligations apply to your firm.
How the MiFID II amendments in Directive (EU) 2022/2556 reach your firm
This sequence turns the MiFID II provisions that Article 6 of Directive (EU) 2022/2556 aligns with DORA into a short, confirmed list of duties your firm must evidence under both regimes. The output is one shared map that compliance, risk and IT can use without duplicating documents.
Inventory the MiFID II provisions in scope
Start with the MiFID II obligations your firm already runs on, focusing on ICT systems and security, the resilience of algorithmic trading, business continuity and the operation of regulated markets where your firm is involved. Compliance leads should pull the current MiFID II policies, the authorisation file and the relevant sections of your procedures, then list each obligation by reference. The output is a register of MiFID II requirements that touch technology, reviewed and signed off by the compliance function.
Read Article 6 against each listed provision
Work through Article 6 of Directive (EU) 2022/2556 and record, for each MiFID II requirement in the register, whether it is aligned with DORA, replaced by a DORA duty, or left unchanged. Legal counsel or the compliance lead should own this reading, because the directive changes the wording of existing provisions and the result decides which rules your firm applies. The check is complete when every register line carries a documented reading and a named reviewer.
Map MiFID II obligations to DORA duties
Build a crosswalk that pairs each MiFID II requirement that now points to DORA with the DORA duty that governs the same activity, such as the ICT risk management framework in Chapter II, incident handling in Chapter III or resilience testing in Chapter IV. Assign the technology risk owner to confirm the technical scope and the compliance lead to confirm the legal wording. Done means each row names one DORA article or technical standard and one accountable owner, with no gap left blank.
Identify overlapping documents and controls
Compare the policies, procedures and records that already serve MiFID II, such as ICT security policies, business continuity plans, algorithmic trading controls and testing reports, with what DORA requires. Where one document can satisfy both regimes, keep one version and cross-reference it. Where a DORA element is missing, record it as a gap for the documentation plan. The output is a document register that shows which files serve both regimes and which still need work.
Confirm with the regulator which provisions apply
Write to your competent authority, which for investment firms is generally the national authority that supervises MiFID II, and ask it to confirm which MiFID II provisions now refer to DORA for your firm and whether any national guidance or supervisory expectations apply. Record the reply in the compliance file. Do not rely on this page or on a secondary summary alone, since national practice and the wording of the directive as transposed decide the answer. The check is complete when the written confirmation sits on file with the crosswalk.
Assign ownership and approval for merged documents
Set out who in the management body, the risk function and the IT function approves each merged or cross-referenced document, and how changes are tracked when either regime changes. The management body remains responsible for ICT risk under the simplified framework where it applies, so its approval should be recorded in the minutes. The output is an ownership table and an approval log that a supervisor or external auditor can trace.
Verify the evidence set and schedule a review
Test a sample of the mapped controls against the evidence it should produce, such as access logs, continuity test records, incident registers and algorithmic trading kill-switch tests, and confirm the records are complete and traceable to the crosswalk. Schedule the next review of the register and the regulator confirmation whenever the directive, the delegated regulations or national rules change. The check is complete when the evidence set maps back to each MiFID II and DORA line without gaps.
What the simplified ICT framework still requires of management
Investment firms that qualify for the simplified ICT risk framework are relieved of much of the full DORA build, but the management body keeps personal responsibility for ICT risk. The cards below set out the governance duties that remain and the records that show each one is being met.
Management body accountability
The management body must own ICT risk as a board-level matter rather than delegating it entirely to IT. Check that minutes record the body's discussion and approval of the ICT risk approach, and that members can explain the firm's main ICT risks without reading a briefing note. Ask who on the board holds the ICT remit and whether that person has the knowledge to challenge the operations team.
Defined ICT roles and objectives
Each ICT responsibility needs a named owner, and the objectives those owners work toward need to be written down. For a small firm this often means a short responsibility matrix that maps security, access, change and continuity to specific individuals, including any outsourced provider's contact. Evidence is the signed matrix and objectives tied to the firm's business services.
Annual ICT budget review
The ICT risk budget must be set and reviewed at least once a year, so that the firm can show it funds the controls its risk assessment calls for. Compare the approved budget with actual spend on security tooling, backup, testing and staff training. Ask whether a shortfall triggered a documented decision to accept risk or to reallocate funds.
Independent control function
The simplified regime still expects control and internal audit functions to be independent of the operations they review. In a firm with few staff, independence can come from separating reviewer from doer, or from an external reviewer on a defined engagement. Confirm who performs ICT control checks, that they do not approve their own changes, and that their reporting line reaches the management body.
Internal audit of ICT controls
Internal audit must test whether ICT controls work as written, not only whether policies exist. Plan the audit scope around the firm's critical services and keep work papers that show sampling, findings and follow-up. Where the firm is too small for a full internal audit team, ask whether an external firm can perform the review under a fixed-scope engagement with a written report.
Timely remediation of critical findings
Critical audit findings must be fixed within a time frame the management body has approved, and the fixes must be verified. Keep a findings register with severity, owner, due date, closure evidence and a record of any extension approved by management. Regulators reviewing a firm will usually look first at whether critical findings from a prior cycle are closed.
Who is paid for what in a DORA project for an investment firm
This table compares the cost components of a DORA project for an investment firm, showing who is paid for each, whether it is one-time or recurring, and what drives it up. No figures have been published for these components in the sources we rely on, so request written, scoped quotes from each party before committing budget.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal staff time | Your own staff (compliance, IT, security, risk, management body) | One-time for setup, recurring for annual review and reporting | Firm size, number of ICT systems, how much documentation already exists, and whether a simplified-regime exemption applies |
| Implementation partner for systems and evidence | External partner such as DeployOpen, scoped in writing | Mostly one-time, with optional recurring retainer for upgrades and testing | Number and complexity of in-scope systems, gaps against the simplified framework, and how much hardening and documentation is needed |
| Tooling and licences | Software vendors and hosting providers | Recurring subscriptions, plus one-time setup where tools are installed | Choice between self-hosted open-source tools and commercial products, and the size of your environment |
| Security testing | Independent testers chosen by your firm | Recurring, usually on a set cycle | Scope of systems tested, whether third-party providers are involved, and remediation effort after findings |
| Independent auditor or assessor | Auditor or certification body, only where a report or attestation is required | Recurring if reports are needed each cycle | Scope, the assurance type your counterparties request, and the volume of evidence to sample |
| Management body and governance time | Internal board or senior management time | Recurring, as the budget and ICT risk objectives must be reviewed at least yearly | Complexity of the ICT risk picture and how often the body needs to review remediation of audit findings |
| ICT third-party due diligence and contract work | Internal legal and procurement staff, and sometimes outside counsel | One-time per contract, recurring at renewal | Number of ICT providers, whether any support critical or important functions, and the need for exit planning |
How to plan a DORA readiness project for an investment firm
The sequence moves an investment firm from a confirmed regulatory scope to a documented, management-approved ICT risk framework that is ready for supervisory review. Each phase closes with a named output so the firm can see what is finished before the next phase starts.
Confirm scope and regime with the competent authority
The firm first establishes which DORA regime applies. Investment firms in scope of DORA under Article 2 must determine whether they fall under the full framework or the simplified regime for small and non-interconnected firms under Article 16(1). The compliance lead, with legal counsel, checks the firm's authorization, size and interconnectedness, and confirms the position with the national competent authority where the answer is unclear. The output is a written scope memo that names the regime, the MiFID II services in use and any exemptions relied on. The step is done when the management body has approved that memo.
Run a gap analysis against the applicable requirements
The team maps the firm's existing ICT systems, policies and practices against the requirements that apply to its regime. A full-scope firm compares itself against Chapter II of DORA and the detailed rules in Delegated Regulation (EU) 2024/1774. A firm on the simplified regime works from Title III of that delegated regulation, which covers governance through to the review report. The output is a gap register that lists each requirement, the current state, the owner and the remediation option. The step is complete when every applicable requirement has a status and a named owner.
Build the ICT risk management framework and inventory
The firm sets up its ICT risk management framework, including the asset inventory, classification of ICT assets and functions, and the risk assessment that supports them. Where the firm relies on self-hosted open-source platforms, the inventory should record where each component runs, who operates it and which business functions depend on it. The output is an approved framework document and a current asset register that the technical team can reconcile against live systems. Confirm that the inventory covers the ICT services used by critical or important functions.
Prepare policies, procedures and evidence
The firm writes or updates the policies that DORA's technical standards expect, such as information security, access control, change management, business continuity and backup. Each policy should name an owner and describe the procedure that produces evidence. Evidence examples include access review records, change tickets, backup restore logs and vulnerability scan reports. The output is a policy set with a control-to-evidence map that shows where each claim can be verified. The step is done when a reviewer can trace each policy statement to a retained artifact.
Test controls and remediate findings
The firm tests the controls it has documented, using the security testing and resilience testing its regime requires. For many investment firms this includes vulnerability assessment, penetration testing of exposed systems and a backup restore exercise. Testers should work from an agreed scope and report to the control owner. The output is a test report per control area with findings classified by severity, along with a remediation plan that has an owner and a closure date for each item. Confirm that critical audit findings are remediated in time, as the simplified regime requires.
Obtain management body approval and annual review
The management body reviews the framework, policies, risk assessment and test results, then formally approves them. Under the simplified regime, Article 28 of Delegated Regulation (EU) 2024/1774 makes the management body responsible for ICT risk, roles, objectives and a budget reviewed at least yearly. The output is a signed minute recording the approval, the allocated budget and the named roles. Confirm that the minutes reflect substantive discussion rather than a formal sign-off, since supervisors look for that difference.
Hand over to operations and schedule the review cycle
The project closes with a handover to the people who run the controls day to day. The firm assigns control owners, sets up the calendar for recurring evidence collection, and schedules the annual review that the framework requires. Where a partner prepared systems and documents, the handover includes configuration records, runbooks and the evidence index. The output is a handover pack and a dated review calendar. The project is complete when the operations team can produce each piece of evidence without the project team's help.
Who owns DORA controls and who prepares the evidence
The investment firm's management body owns its ICT risk framework, even when technical tasks are delegated to staff or outside partners. Under the simplified regime, Article 28 of Delegated Regulation (EU) 2024/1774 makes the management body responsible for ICT risk, roles, objectives and a budget, reviewed at least yearly. Staff run the controls day to day and create the records that show those controls operate.
- Approval and accountability: The management body approves the ICT risk policy and budget, and remains accountable for them after a partner builds the controls.
- Named roles: Assign owners for access reviews, backups, change approval and incident handling, and record the individuals who hold each role.
- Annual review: Review ICT objectives and the budget at least once a year and minute the decision, including any changes.
- Independent internal functions: Keep control and internal audit functions independent of the people who run the systems they check.
- Retained knowledge: Staff must be able to explain, operate and evidence the platform once the project closes, without relying on the partner.
Check that board minutes, the role register and the budget approval exist, name individuals inside the firm, and show that the management body reviewed the framework rather than only receiving a summary.
An implementation partner such as DeployOpen prepares systems, controls and evidence inside the firm's own environment. The partner builds and documents; the firm decides, approves and signs. DORA sets no certification scheme, so no partner, consultant or vendor can grant DORA compliance, and DeployOpen does not issue audit reports, attestations or certifications.
- Deployment and hardening: Install and configure self-hosted open-source platforms in the firm's own cloud accounts, data centers or private networks, including logging, access and backup settings.
- Evidence preparation: Produce configuration exports, runbooks, test results and change records, organized against the firm's own control list.
- Documentation drafts: Draft policies and procedures for the firm to review, amend and approve through its governance process.
- Testing delivery: Run the security testing the firm commissions and deliver findings to the firm for remediation and tracking.
- Handover: Document operating procedures so the firm's staff can run, monitor and evidence the platform without the partner present.
What is commonly outsourced is the build, the testing and the first drafts of documentation. Confirm in the written scope which deliverables the partner prepares, which the firm approves, and who signs each artifact.
Firms that want independent assurance engage an auditor or assessor that is separate from the people who designed and operated the controls. The auditor tests design and operating effectiveness against the firm's documented obligations and issues its own findings or opinion. DORA itself provides one authority-issued attestation: that a threat-led penetration test met the requirements (Article 26(7)), and that applies only to entities that are in scope for TLPT.
- Assessment scope: Test whether controls are designed correctly and operate over a period, sampling evidence rather than accepting a single snapshot.
- Independence: Where the firm wants to rely on the work, the auditor should not have implemented the controls under review. Ask how the auditor manages conflicts of interest.
- Reports: Only the independent auditor issues findings reports or opinions addressed to the firm. A partner's test results are inputs, not assurance.
- Scoping the engagement: Fees and duration depend on the number of controls, sample sizes and evidence quality. Request a quote built from a written scope.
- Limits of assurance: An auditor's work does not replace supervisory review by the competent authority.
Before engaging an auditor, confirm with your competent authority and your clients' contracts what form of independent assurance they expect and whether they will accept it.
The national competent authority for each type of financial entity, listed in Article 46, supervises DORA compliance. For investment firms, that authority also supervises under MiFID II. It uses the powers in Article 50 to request information, inspect and require remedial measures. It does not certify firms, and it does not pre-approve partner deliverables, so the firm must be able to demonstrate its own compliance on request.
- Information requests: Authorities may ask for ICT risk documentation, incident records, testing results and the register of information.
- Inspections: Expect on-site or remote inspection. Keep evidence in an accessible location with a clear index.
- Remediation: Authorities can require remedial measures. Track remediation as an operating task with owners and deadlines.
- Named contact: Confirm which team in the authority handles DORA questions for investment firms, since MiFID II and DORA may sit with different desks.
- Delivery records: Keep records showing who prepared, reviewed and approved each artifact, including the partner's role.
Confirm your authority's expectations on format, retention and submission channels before the first request arrives, not during it.
Questions investment firms ask about DORA scope and effort
Can a small investment firm decide on its own that the simplified DORA regime applies?
Not by simple self-declaration. The simplified ICT risk framework applies only to small and non-interconnected investment firms that fall under the relevant exemption in Article 16(1), and the firm must confirm that its profile fits those conditions. Confirm the classification against the wording of Article 16 and your national competent authority's guidance before you rely on it. If the firm qualifies, Title III of Delegated Regulation (EU) 2024/1774 sets out the simplified requirements, and the management body remains responsible for ICT risk, roles, objectives and a budget reviewed at least yearly. Ask outside advisers to document the reasoning so an assessor can follow it.
Does threat-led penetration testing apply to an investment firm?
Usually not if the firm falls under Article 16(1). Entities covered by that provision are excluded from threat-led penetration testing under Article 26(1). Firms outside that exemption must assess whether they are in the TLPT population set by their competent authority, which depends on criteria the authority applies. Even when TLPT does not apply, every in-scope firm still runs the basic testing programme. Confirm your status with your regulator, and if TLPT is required, plan around the TIBER-EU process and the requirements for testers in Delegated Regulation (EU) 2025/1190.
What evidence must an investment firm be able to produce for DORA?
The firm must be able to show its ICT risk management framework, a governance record with management body approval, an asset inventory, the incident management process and reporting records, the testing programme and its results, and its ICT third-party arrangements. Under the simplified regime, that includes an information security policy, asset classification, access control records, backup and business continuity evidence, and a review report. Assessors look for dated, approved documents and logs that show the controls operate, not just that they are written down. Inventory these artifacts early, because they are often the largest source of rework.
Does an ISO 27001 certificate satisfy DORA?
No. An ISO/IEC 27001 certificate is a certification of an information security management system issued by an accredited certification body. It does not establish DORA compliance, and DORA sets no certification scheme. Competent authorities supervise DORA using their powers under Article 50, and the only authority-issued attestation the Regulation provides for concerns threat-led penetration testing under Article 26(7). An ISO 27001 scope can still supply useful inputs, such as asset registers, risk assessments and access reviews, but the firm must map those inputs to DORA's own requirements and check the gaps.
What drives the cost of DORA readiness for an investment firm?
The main drivers are the firm's size and complexity, whether it is in full scope or the simplified regime, how many ICT systems and third-party services it depends on, and how much of its documentation and evidence already exists. Costs fall into one-time work (gap analysis, policy writing, system hardening, testing and register setup) and recurring work (testing, reviews, incident handling and provider oversight). Ask any provider for a fixed-scope written proposal that lists systems, deliverables and assumptions, and request separate line items for internal staff time, external implementation and independent assessment. No public figure for these costs is supplied here, so treat any single number with caution.
How long does DORA readiness take for an investment firm?
The duration depends on the firm's starting point, its scope and how quickly decisions move through the management body. A firm with current ISO or SOC documentation, a clear asset inventory and a stable provider base usually has less to build than one with fragmented systems and no formal risk framework. DORA has applied since 17 January 2025, so firms that have not yet completed their gap analysis should prioritize scope confirmation, the register of information and the policy set. Ask for a phased plan with milestones, and confirm the timeline with your competent authority if you face any open supervisory questions.
Does an investment firm need outside help to comply with DORA?
Not legally. The firm owns its controls, decides its scope and is accountable to its competent authority. Many firms still bring in outside help for specialist work they lack in-house. An implementation partner such as DeployOpen can prepare systems, controls and evidence, and can implement, harden and document self-hosted open-source platforms inside the client's own infrastructure. Only an independent auditor or assessor issues reports, and DeployOpen does not issue audit reports, attestations or certifications. Most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How to choose a DORA partner or assessor for an investment firm
An investment firm needs two different kinds of outside help under DORA: a partner who prepares systems and evidence, and an independent assessor who tests them. The cards below cover the checks that separate a suitable partner from one that creates risk, starting with regulatory familiarity and ending with the questions to settle before signing.
Familiarity with MiFID II and DORA Chapter II
Ask whether the team has worked on the ICT risk management requirements in Chapter II of DORA and on the MiFID II provisions on ICT systems, algorithmic trading and business continuity that Directive (EU) 2022/2556 aligns with DORA. A firm that can explain how the simplified framework in Delegated Regulation (EU) 2024/1774 differs from the full regime is more likely to scope the work correctly. Ask for named examples of prior deliverables, described without client names.
Independence from the audit
The firm that designs or remediates your controls should not also be the one that tests them and issues the assessment. Ask the partner to state in writing whether it has provided any other services to the same entity, and confirm that the independent assessor is separate from the implementation partner. Independence also matters for the internal audit function that DORA expects to be independent for simplified-regime entities.
Experience with ICT and trading systems
Generic IT security experience is not enough for an investment firm. Look for familiarity with order management, market data, trade reporting and connectivity to trading venues, plus the operational realities of recovery and change control in a trading environment. Ask how the partner would test a trading platform without disrupting market hours, and what it would need from your technology team to do so.
Written fixed scope
Most engagements should have a scope, deliverables and timeline agreed in writing before work starts. The scope should name which systems, ICT services and providers are covered, which DORA articles and technical standards each deliverable addresses, and which decisions remain with your board and management body. Vague scopes tend to produce open-ended cost and unclear evidence at the end.
Who issues the evidence
Confirm in writing that the partner prepares systems, controls and evidence, and that only an independent auditor, assessor or competent authority-recognized process issues reports or attestations. Ask which document, log or record each deliverable produces, who signs it, and where it is stored. Be wary of any partner that offers to issue a DORA certificate, since DORA sets no certification scheme.
What the partner will not do
Ask the partner to list the activities it will not perform, such as signing the management body's risk acceptance, acting as the firm's register of information owner, or making reporting decisions on your behalf. Clear boundaries show that the organization keeps ownership of its controls and its regulatory communications. Confirm in the contract how the partner handles access to live trading environments and client data.
Where investment firm DORA projects usually stall
The most common stall is scope confirmation that happens too late. Many investment firms start building controls before they have settled which DORA regime applies to them, then discover that the simplified framework changes which documents, testing and governance steps are needed. Confirm your classification with your national competent authority early, and record the answer in writing. Where the authority's position is unclear for your firm's activities, document your reasoning and the question you put to the regulator, so the decision can be defended in supervision.
A second stall is treating the simplified regime as a full exemption. Under Article 16(1), small and non-interconnected investment firms are disapplied from Articles 5 to 15, but the Title III framework in Delegated Regulation (EU) 2024/1774 still asks for governance, an information security policy, asset classification, access control, business continuity and a review report. Firms that assume they can skip these areas usually find gaps during their first supervisory request. Map each simplified-regime requirement to a named owner and an existing record, even if the record is short.
Weak management body documentation and underestimated third-party inventories cause the most rework. Under Article 28 of Delegated Regulation (EU) 2024/1774, the management body remains responsible for ICT risk, roles, objectives and a budget reviewed at least yearly, so minutes and approvals must show that review actually happened. Separately, firms often list only obvious cloud subscriptions and miss open-source components, market data feeds and outsourced administration. Build the full ICT service inventory before drafting contracts. Your next step is to confirm classification with the authority, then request a written scope from your implementation partner that lists deliverables, owners and dates before any work starts.
How DeployOpen scopes and prepares DORA evidence
DeployOpen works on DORA for investment firms by first fixing which investment firm obligations apply, then preparing the systems and evidence those obligations need. The organization keeps ownership of its controls, and an independent auditor or assessor, not DeployOpen, issues any report or attestation.
How we scope
- Confirm whether the firm falls under the full DORA regime or the simplified framework for small and non-interconnected firms
- Record which MiFID II exemptions or relief from TLPT and the third-party strategy the firm can rely on
- Agree in writing which systems, ICT services and entities the engagement covers before work starts
How we build
- Prepare the ICT risk management, logging, access and continuity configurations that the firm's chosen regime requires
- Set up self-hosted open-source platforms inside the firm's own cloud accounts, data centers or air-gapped networks
- Test the configured controls and record the results so the firm can show how each one operates
How we hand over
- Deliver the policies, asset inventory and evidence register as documents the management body can review and approve
- Walk the firm's control, internal audit and management staff through how each control is evidenced
- Give the firm the source configurations, runbooks and test records it needs to retain and provide to supervisors
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes
- Update documentation and evidence when the firm changes platforms, providers or its regulatory status
- Coordinate with the firm's chosen independent assessor or consultant when they request additional evidence
