DORA ICT risk assessment cost and residual risk acceptance

What DORA requires for ICT risk assessment and residual risk acceptance

Consider a payment institution with a DORA readiness deadline and no written risk methodology yet. The financial entity owns and approves its ICT risk assessment methodology, its risk tolerance level and every decision to accept residual risk. An implementation partner such as DeployOpen can prepare the assessments, the asset-linked evidence and the supporting records, but only the competent authority or an independent auditor judges them. DORA sets no certification scheme, and DeployOpen does not issue attestations or certificates. Article 3 of Delegated Regulation (EU) 2024/1774 requires the ICT risk management policy to provide for approval of the tolerance level and a methodology that identifies threats and vulnerabilities to business functions and ICT assets, using quantitative or qualitative impact and likelihood indicators. Article 8 of DORA adds that sources of ICT risk, including exposure to other financial entities, must be identified continuously and that risk scenarios must be reviewed at least yearly.

The effort behind those obligations depends on the entity. Its size, the number of ICT assets it maintains, and how many critical or important functions depend on third-party providers all change the volume of risk scenarios, the depth of threat monitoring and the number of residual risks that need a named owner. A small entity with a few systems and one hosting provider can often run a compact methodology. A larger institution with legacy platforms and many outsourced services needs a larger register, more frequent reassessment and stronger traceability from each accepted risk to its justification. Ask any partner to show, in writing, which inputs they will require from your asset inventory, threat intelligence sources and third-party register before they quote.

Before work starts, confirm three things with your leadership and your supervisor's expectations. First, who approves the tolerance level and each accepted residual risk above tolerance. Second, how the inventory of accepted risks records its justification and its annual review date. Third, which triggers force a fresh assessment, including each major change to network or information system infrastructure, which Article 8(3) requires for entities other than microenterprises, and the yearly ICT risk assessment of all legacy systems under Article 8(7). Those decisions belong to your organization. A partner can then build the records, dashboards and test evidence that show those decisions were made and reviewed.

Which risk treatment steps and monitoring the RTS expects

Article 3 of Delegated Regulation (EU) 2024/1774 turns risk assessment into a cycle: treat, check, monitor and adjust. The cards below set out each step and the evidence an assessor will ask to see, since a documented methodology alone does not show that risk is actually being managed.

Risk treatment procedure

The policy must describe a documented procedure for identifying and implementing ICT risk treatment measures, including measures that bring risk within the approved tolerance level. Check that each treatment has a named owner, a target date and a link to the risk it addresses. Evidence usually includes a risk register or treatment plan with status history, and the approval records for changes to the plan. Ask whether treatment decisions can be traced back to the tolerance level the management body approved.

Bringing risk within tolerance

Every assessed risk above the approved ICT risk tolerance level needs a decision: reduce it, transfer it, avoid it or accept it. Where the decision is to reduce, the organization should be able to show which controls move the residual rating below tolerance. Evidence includes the re-scored risk after treatment and the sign-off by the role assigned to accept risk above tolerance. Confirm that the tolerance itself is set by the management body, not by the risk team alone.

Checking treatment effectiveness

Article 3 also requires monitoring whether treatment measures are effective and whether tolerance levels are being met. Opening a ticket and closing it does not prove that a control reduces the risk it targets. Look for periodic re-assessment of treated risks, test results that support the claimed reduction, and recorded cases where a measure failed and was redesigned. Assessors tend to probe this step by picking one treated risk and asking for the evidence that it moved.

Monitoring threats, vulnerabilities and the risk profile

The framework must monitor changes in the threat landscape, internal and external vulnerabilities, and the entity's overall ICT risk profile. Practical sources include vulnerability scanner output, threat intelligence feeds, incident trends and advisories from sector bodies. The key evidence is a dated log showing what changed, who reviewed it and whether the risk register was updated as a result. Confirm that monitoring covers both internally hosted systems and the services that third parties run on the entity's behalf.

Reflecting strategy and resilience changes

The risk process must also pick up changes in business strategy and in the digital operational resilience strategy. A new product line, a market expansion or a revised risk tolerance can shift which risks matter most. Evidence includes a documented trigger, such as a board decision or strategy update, followed by a re-run of the relevant risk assessment. Check that the minutes or change records link the strategy decision to the risk register entries it affected.

Continuous identification of risk sources

Article 8(2) requires continuous identification of all sources of ICT risk, in particular exposure to and from other financial entities, along with review of the risk scenarios at least yearly. Map dependencies on shared infrastructure, payment networks, data exchanges and common service providers, since these create risk that an entity's own controls cannot fully contain. Evidence includes the dependency map, the scenario review record and a note of how inter-entity exposure was assessed. Ask whether the map is refreshed when a new connection or provider is added.

How to identify, accept and review residual risk

This sequence turns treated ICT risks into a documented decision: each remaining risk is named, the right person accepts or escalates it against the approved tolerance, and the accepted items are reviewed on a fixed cycle. The output is a risk record that an assessor can trace from the methodology to the final sign-off.

Identify residual risk after treatment
After the treatment measures for each assessed ICT risk are applied, the risk owner re-scores what remains, using the same impact and likelihood indicators as the original assessment. The residual risk is recorded against the affected business function or ICT asset, with the threat, the vulnerability it relies on and the treatment measures already in place. The step is complete when every treated risk has a residual score and a named owner, and none is left as an open question in the register.
Compare residual risk with tolerance
The ICT risk function checks each residual score against the ICT risk tolerance level that the management body approved under the ICT risk management policy. Risks within tolerance are marked as accepted by policy, while risks above tolerance are flagged for a decision and are not left to the owner to close alone. The output is a short list of above-tolerance items, each linked to its asset and treatment record, so the next step has a defined input.
Assign acceptance roles
The policy names who may accept a residual risk above tolerance, and that role is set out in writing with its limits and any required escalation to the management body. Acceptance does not sit with the team that runs the system, so the approver is independent of the day-to-day owner. The output is a documented role matrix that the risk team can show to a competent authority, and it is confirmed before any acceptance is signed.
Record each accepted risk with justification
For each risk the approver chooses to accept, the inventory entry states the risk, the asset, the residual score, the reason for accepting it rather than treating it further, the compensating controls, the approver's name and the date. The entry is signed or approved through the organization's governance workflow, so the decision can be traced. The output is a signed acceptance record for each item, and an entry that lacks a justification or an approver is not counted as accepted.
Maintain the accepted risk inventory
The accepted residual risk inventory becomes the single list that management, internal audit and supervisors read. Entries are updated when the asset changes, when a major change is assessed, when the legacy system review finds new exposure, or when a threat or vulnerability changes the score. The output is a current inventory with version history, so every change to an accepted risk can be explained after the fact.
Review accepted risks at least yearly
At least once a year, the risk function re-examines every accepted residual risk to confirm the justification still holds, the compensating controls still work and the score is still within the approved tolerance. Risks that no longer hold are re-treated, re-escalated or closed, and the review is logged with its attendees and outcome. The output is dated review minutes and an updated inventory, and the minutes should be ready for the framework review that supervisors may request.
Feed review results back into the framework
Findings from the yearly review, incidents and threat monitoring are fed back into the risk assessment methodology and the risk scenarios. Where accepted risks have moved out of tolerance, the policy's treatment procedure is triggered again and the record is updated. The output is a link between the review minutes, the revised risk register and the management body's reporting, which shows that accepted residual risk is managed rather than only recorded.

When a new risk assessment is triggered

DORA does not leave ICT risk assessment to a single annual exercise. Three triggers keep the assessment current: changes to the infrastructure or processes, legacy systems that age out of vendor support, and the threat picture behind the scenarios. Each one needs its own record, owner and evidence.

Major infrastructure or process changes

Article 8(3) requires a risk assessment on each major change in network and information system infrastructure or processes. Examples include moving a core banking workload to a new cloud region, replacing an identity provider, or changing how payments are routed between internal systems. Define in the change policy what counts as major, so change tickets can be sorted into assessed and not assessed. Check that the assessment is completed before the change goes live and that its outcome feeds the residual risk inventory.

Legacy ICT systems review

Article 8(7) requires a specific ICT risk assessment of all legacy ICT systems at least yearly. Legacy typically means systems that are out of vendor support, run unpatched components, or depend on staff who no longer maintain them. Keep a register that marks each legacy system, its end-of-support date, compensating controls and the decision taken, whether to replace, isolate or accept. Note that microenterprises are exempt from this requirement, and smaller entities should confirm their own regime with their competent authority.

Annual review of risk scenarios

Article 8(2) requires continuous identification of all sources of ICT risk, including exposure to and from other financial entities, and a review of the risk scenarios affecting the entity at least yearly. Scenarios should reflect current cyber threats and known ICT vulnerabilities, not last year's list. Record which scenarios changed, which new dependencies or third-party exposures were added, and who approved the updated set. This review is the main input for setting the ICT risk tolerance level.

Threat landscape monitoring

Article 3 of Delegated Regulation (EU) 2024/1774 requires monitoring of changes in the threat landscape, internal and external vulnerabilities and the overall ICT risk profile. A practical process collects vulnerability advisories, threat intelligence and incident lessons, then decides whether each one triggers a new assessment. Document the sources used and the criteria for escalation. Auditors will ask for evidence that monitoring led to action, not only a feed subscription.

Assessment records and sign-off

Each triggered assessment should produce a dated record showing the trigger, the threats and vulnerabilities considered, the impact and likelihood indicators used, the treatment chosen and the approver. Where a change or legacy system leaves residual risk above tolerance, the named role must accept it in the residual risk inventory with a justification. Confirm with your competent authority and internal audit how they expect these records to be stored and retrieved during supervision.

Open-source platform change impacts

When a self-hosted open-source platform is upgraded, reconfigured or moved to new hardware, the change may be a major change under Article 8(3). Upgrade plans, dependency changes and new integrations should be assessed before rollout, with the evidence stored alongside the change record. Ask any implementation partner to provide change assessments as part of the written scope so the organization owns the decision and the partner supplies the analysis.

What a DORA risk assessment engagement costs and who is paid

This table compares the cost components of running DORA ICT risk assessment and residual risk acceptance, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No fees or durations are supplied for this topic, so use the drivers as the basis for asking each provider for a written quote. The main takeaway is that the largest recurring cost is usually management time, not software or outside help.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost up or down
Internal risk owners and board time	The entity's own staff and management body, through salary and time allocation	Recurring, at least yearly for the residual risk review and each risk assessment cycle	Number of business functions and ICT assets in scope, how many risks sit above tolerance, and how often major changes trigger new assessments
Implementation partner for methodology design	External consultant or implementation partner, paid under a fixed-scope written agreement	One-time build of the methodology, scales, tolerance wording and templates	Maturity of the existing ICT risk framework, number of legacy systems, and whether the entity reuses an existing enterprise risk method
Implementation partner for assessment preparation and recurring review	External partner, typically under a retainer or repeated scoped work orders	Recurring, aligned with the yearly review cycle and major change assessments	Volume of change in the infrastructure, quality of the asset inventory, and how much evidence the entity already keeps
Tooling for asset and risk registers	Software vendor (licence) or the entity's own hosting team (self-hosted platform and infrastructure)	Recurring licence or hosting, plus one-time setup and data migration	Number of records, integrations with monitoring and change systems, and whether the platform is self-hosted or licensed as a service
Threat monitoring inputs	Internal security operations or a managed provider, through staffing or subscription	Recurring	Breadth of threat intelligence sources, alert volume, and whether monitoring is in-house or outsourced
Independent review or audit, where chosen	Independent auditor or assessor, paid under their own engagement letter	Periodic, chosen by the entity rather than required as a standalone attestation	Scope of the review, reliance on internal audit under DORA, and whether the review covers legacy systems and third-party dependencies
Remediation of treatment measures	Internal teams or the entity's technology vendors and implementation partners	Varies by risk, often one-time per measure with ongoing upkeep	Number of risks above tolerance, complexity of the affected systems, and whether controls already exist but need tuning

What makes the risk assessment larger or slower

The effort behind a DORA ICT risk assessment depends less on the method than on how much there is to assess. Entity size, asset volume, third-party exposure, change pace and the quality of existing records each widen the work, and they interact, so a large firm with clean registers can move faster than a smaller one with fragmented data.

Entity size and proportionality

Article 4 scales DORA obligations to the size, nature, risk and complexity of the entity, and the RTS allows simplified arrangements for some firms. Confirm early which regime applies, because it changes how deep the methodology, scenario reviews and documentation must go. A firm that assumes the full regime when a simplified one applies, or the reverse, will misjudge both timeline and staffing.

Number of ICT assets

Every server, container cluster, database, endpoint and network device that supports a business function must be identified, assessed for threats and vulnerabilities, and tied to impact and likelihood indicators. Each additional asset class adds scenarios to review. Ask whether the asset data comes from one source or several, since reconciling sources is often the largest single task.

Legacy systems in scope

Article 8(7) requires a specific ICT risk assessment of all legacy systems at least yearly, so older platforms recur in every cycle. Legacy systems often have unsupported components, undocumented dependencies and limited vendor patching, which lengthens each assessment. Identify them early and record the compensating controls and the justification for any residual risk accepted for them.

ICT third parties and their criticality

Each ICT provider that supports a business function adds exposure to assess, including exposure from other financial entities that Article 8(2) requires you to identify continuously. Providers that support critical or important functions warrant deeper scenario analysis and exit consideration. Count providers by criticality tier, not by contract total, to size the work realistically.

Change frequency

Article 8(3) requires a risk assessment on each major change to network and information system infrastructure or processes. Teams that deploy often, migrate workloads or adopt new platforms generate assessments continuously rather than once a year. Agree with engineering what counts as a major change, and route change requests through a standard template so assessments do not depend on memory.

Quality of existing registers

An assessment is only as reliable as the asset, dependency and third-party records behind it. Stale owners, missing dependencies or duplicate entries force analysts to rebuild facts before they can judge risk. Before estimating effort, sample the existing registers, check owners and dependency links against a recent system diagram, and record how many entries need correction.

Business functions to map

Risk must be assessed against business functions as well as technical assets, so each function needs its dependencies traced to systems and providers. The number of functions, and how many are critical or important, sets the number of threat scenarios and impact judgments. Ask stakeholders for a short list of functions and their owners at the start, since disagreement about scope is a common source of delay.

Who owns the risk decisions and who prepares the evidence

The financial entity owns every ICT risk decision. The management body approves the ICT risk tolerance level, and named roles accept any residual risk that sits above that tolerance. Acceptance cannot be delegated to a vendor, a consultant or a system owner who has no authority to commit the firm. The entity also owns the inventory of accepted residual risks, the justifications written into it and the yearly review that keeps it current.

Tolerance approval: The management body approves the risk tolerance level and records that decision in its minutes or resolutions.
Named acceptance roles: Each accepted risk above tolerance has a named role with the authority to accept it, written into the risk policy.
Justifications: Every accepted residual risk carries a written reason, the compensating measures relied on and the conditions that would trigger reconsideration.
Yearly review: Accepted risks are re-examined at least once a year, and changes in threats, vulnerabilities or business strategy trigger earlier review.
Ownership of outcomes: The entity answers to its supervisor for every accepted risk, whatever help it used to assess them.

Check that your board minutes name the tolerance level and that each accepted risk in your register has a named owner with authority, not just a team name.

What must exist before a supervisor or auditor reviews the risk assessment

A supervisor or auditor will not start by reading your risk scores. They will first check that the governing policy, the tolerance level, the method and the records behind them exist, are approved and are current. Each item below is something you can check yourself before an examination begins.

Approved ICT risk management policy

The policy is the document that gives the risk assessment its authority. Under Article 3 of Delegated Regulation (EU) 2024/1774, it must provide for the tolerance level, the assessment method, the treatment procedure and the monitoring of residual risk. Check that the policy names an approver, carries a version and date, and is the same document your staff actually follow rather than a summary written for the file.

Board-approved ICT risk tolerance level

Tolerance is the amount of ICT risk the entity accepts before it must act. Article 3 requires the tolerance level to be approved, which makes it a management body decision rather than an operational setting. Check the approval minutes, confirm the tolerance is expressed in terms that can be compared with assessed risk scores, and confirm it is referenced by the residual risk process.

Documented risk assessment methodology

The methodology explains how threats and vulnerabilities are linked to business functions and ICT assets, and how impact and likelihood are scored, whether quantitatively or qualitatively. An assessor will test whether two people applying it to the same asset reach comparable results. Check that scales are defined, criteria are written down, and every past assessment can be traced back to the version of the method used.

Current ICT asset inventory

A risk assessment is only as complete as the list of assets and business functions it covers. Check that the inventory records each system, its dependencies, its third-party providers and its owner, and that its last update date is recent. Gaps here usually show up when a supervisor picks one application and asks which risk scenarios apply to it.

Risk register with treatment status

The risk register lists each identified risk, its assessed level, the treatment chosen (mitigate, transfer, avoid or accept) and the current status of that treatment. Check that every entry above tolerance has an owner and a dated action, and that the treatment is verified as effective, which Article 3 requires you to monitor. A register without status fields cannot show whether risk is falling.

Accepted residual risk inventory

Residual risk is what remains after treatment. Article 3(d) requires an inventory of accepted residual risks, the named role that accepted each one above tolerance, and a written justification. Check that every acceptance has a justification a third party could follow, an expiry or review date, and an approver with the authority the policy assigns.

Dated review and change assessment records

Article 8 expects a yearly review of risk scenarios, a risk assessment on each major change to infrastructure or processes, and a yearly assessment of legacy systems. Check that each review has a date, a named reviewer, the scope covered and the outcome, and that change tickets link to the assessment that preceded them. Gaps between a major change and its assessment are a common finding.

Questions buyers ask about DORA risk assessment and residual risk

What does a DORA ICT risk assessment cost?

No fixed price applies, because the cost depends on the written scope. The main drivers are the number of business functions and ICT assets in scope, how complete the existing asset inventory and dependency maps are, the number of ICT third-party services involved, and whether legacy systems need separate assessment. Costs fall into two groups: internal staff time from risk, IT operations, business owners and the board, and any external help for methodology design, facilitation or evidence preparation. Much of the work is one-time (methodology, first full assessment, first residual risk register), while reviews, threat monitoring and the yearly reassessment of legacy systems recur. Ask any provider for a quote that lists deliverables, assumptions about the inventory, and which activities the internal team performs. DeployOpen does not publish a price list; a quote follows from the written scope.

How long does DORA risk assessment preparation take?

The duration is set by the written plan, not by a standard period, so ask for the timeline in the scope document. It depends on how mature the current inventory is, how many systems and suppliers must be assessed, how many risk owners must review results, and how quickly the management body can approve the tolerance level. Work usually runs in sequence: define the methodology and tolerance, build or confirm the asset and dependency base, run the assessment, agree treatment measures, and record accepted residual risks with named acceptors. Organizations with a current asset inventory typically move faster than those assembling one from scratch. Confirm dependencies on other workstreams, such as the asset inventory and the digital operational resilience strategy, when agreeing dates.

What does the internal team need to provide?

The internal team owns the risk decisions, so it must supply the people and information that make those decisions defensible. Expect to provide named business function owners who can describe impact, IT owners who can confirm asset configurations and vulnerabilities, a risk function that sets the methodology and scoring scales, and an approver for risk tolerance and each accepted residual risk. Access to change records, incident history, vulnerability scan results and supplier contracts is also needed. Under the RTS, the roles that accept residual risk above tolerance must be assigned and documented, so the team must decide who those people are before assessment closes. Ask the provider to list these inputs and time commitments in the written scope.

Can we run a DORA risk assessment in-house?

Yes, an entity can perform its own risk assessment, and DORA places responsibility on the financial entity's management body and ICT risk function, not on any outside firm. Many organizations keep ownership and accountability in-house while bringing in an implementation partner for specific work such as building the scoring method, assembling asset and dependency records, configuring tooling, or preparing evidence packs. Whether in-house work is practical depends on available risk skills, the number of systems, and the time available before supervisory review. Use an external party only to prepare materials and test methods; decisions and sign-off remain with the entity. DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own infrastructure and prepares evidence, but it does not approve risk acceptance or issue any attestation.

Does DORA have a certification for risk management?

No. DORA sets no certification scheme, so there is no DORA certificate for an ICT risk assessment. Competent authorities supervise compliance using their powers under Article 50 and review what the entity can show. The only attestation the Regulation provides for is confirmation that a threat-led penetration test met the requirements under Article 26(7). Be cautious with any vendor or consultant that offers a DORA certificate for risk assessment, because such a document would not come from a DORA authority. Any independent review of your framework is a voluntary assurance exercise, and its scope and report should be agreed with the reviewer in advance.

What will a supervisor ask for first on risk assessment?

A supervisor typically starts with the documents that show how the entity decides risk, then tests whether those decisions are applied. Expect requests for the ICT risk management policy with its approved risk tolerance level and assessment methodology, the documented risk treatment procedure, and the inventory of accepted residual risks with justifications and named acceptors. Supervisors will also ask for evidence of the yearly review of accepted residual risks, the yearly review of risk scenarios, risk assessments following major changes, and the yearly assessment of legacy ICT systems. Records of threat landscape monitoring and vulnerability tracking should show that the register changes over time. Confirm the exact requests with your competent authority, since supervisory practice and the review timing can vary.

How to choose a partner for DORA risk work

Choose a partner for DORA ICT risk work by checking three things before any money changes hands: whether they understand the financial-sector ICT risk methodology in Article 3 of Delegated Regulation (EU) 2024/1774 and the risk identification duties in Article 8 of DORA, whether they can work without being part of the function they are reviewing, and whether the scope is fixed in writing. Ask for named people with experience in banks, payment institutions or insurers, and ask how they would build the risk tolerance proposal, the risk treatment procedure and the residual risk inventory for your entity. A partner who talks only about tooling or generic frameworks has not answered the question.

Be clear about roles from the start. Your management body owns the risk tolerance level, the risk treatment decisions and the acceptance of residual risk above tolerance. The partner can draft the methodology, populate the threat and vulnerability analysis, prepare the residual risk register and set up the yearly review cycle. They should not sign off risk acceptances on your behalf. Where you need an independent view of the risk assessment, the reviewer should sit outside your own risk function, and that independence should be written into the engagement. Any assurance over the framework comes from your internal audit or an independent assessor, not from the implementation partner.

Before signing, ask for the deliverables list and read it against your own needs. It should name each document (the methodology, the tolerance proposal, the risk assessment for major changes and legacy systems, the residual risk inventory, the threat monitoring procedure and the review schedule), the format of each, who receives it and what acceptance looks like. Confirm the fixed scope, the assumptions about your asset inventory and the items you must provide. Ask how changes to scope are priced and approved, and what happens to the records after handover. Confirm the points to check with the partner and your own counsel, rather than assuming they are covered.

What usually delays DORA risk work or inflates its cost

Most DORA risk delays trace back to a few gaps: a risk assessment done once and filed, tolerance levels never approved at board level, and asset records too thin to score. Each card names one of these gaps and the step that prevents it, so the work stays a standing process rather than a recurring rescue.

Treating residual risk as a one-time sign-off

Teams often accept residual risks once during the initial assessment and never revisit them. Article 3 of Delegated Regulation (EU) 2024/1774 expects residual risks to be identified, accepted by a named role where they sit above tolerance, recorded with justifications, and reviewed at least once a year. Check that every accepted risk has an owner, an expiry or review date, and a written reason that still holds when the review comes around.

Missing board approval of tolerance

Risk assessment has no fixed meaning until the entity sets an ICT risk tolerance level and someone with authority approves it. Without that approval, staff cannot tell whether a finding is within appetite, and every acceptance decision becomes a judgment call. Confirm that the management body has formally approved the tolerance level, that it is written into the ICT risk management policy, and that the minutes show the decision.

Incomplete asset data feeding the methodology

A risk methodology scores threats against business functions and ICT assets, so missing or stale asset records produce scores that look precise but describe the wrong estate. Gaps often sit in dependencies on third-party services, self-hosted components and shadow tools that no one registered. Before scoring, reconcile the asset inventory with the business function map and the list of ICT services in use, and record which fields are still incomplete.

Legacy systems left out of yearly assessment

Legacy platforms are the systems most likely to carry unpatched vulnerabilities and unsupported dependencies, yet they are often excluded because they are assumed to be stable. Article 8(7) of DORA requires a specific ICT risk assessment of all legacy ICT systems at least yearly, for entities other than microenterprises. Build a legacy register with an owner for each system and schedule its assessment as a fixed line in the annual cycle, not an optional extra.

Threat monitoring not linked to the register

Threat intelligence and vulnerability feeds often sit in a security operations tool while the risk register is updated by hand, if at all. Article 3 of the RTS requires monitoring of changes in the threat landscape, vulnerabilities and the ICT risk profile, and a way to reflect those changes in the framework. Define a rule that each relevant threat or vulnerability creates or updates a register entry with a score, an owner and a treatment decision, and check that rule against a sample of recent alerts.

Major changes skipped in the assessment cycle

Risk assessments tend to follow the annual calendar, while infrastructure changes happen in sprints and migrations. Entities other than microenterprises must assess risk on each major change to network and information system infrastructure or processes under Article 8(3). Add a mandatory risk step to the change process, with a defined threshold for what counts as major, and keep the assessment record linked to the change ticket.

How DeployOpen prepares DORA risk assessment evidence

DeployOpen helps financial entities and their ICT providers prepare the systems, records and evidence behind DORA ICT risk assessment and residual risk acceptance. The organization owns its risk methodology, tolerance levels and acceptance decisions, while DeployOpen prepares the technical inputs and documentation those decisions rely on.

How we scope

Agreed in writing before work starts, with systems, business functions and ICT assets named explicitly
Defines which self-hosted open-source platforms fall inside the risk assessment and which stay with the client
Records who inside the organization approves tolerance levels and accepts residual risks above tolerance
Engagements are fixed-scope, so deliverables and timelines are confirmed before any risk work begins

How we build

Prepares threat and vulnerability inputs for each in-scope platform, drawn from the client's own environment
Maps identified risks to impact and likelihood indicators defined in the client's chosen methodology
Sets up records for risk treatment measures and monitoring of their effectiveness against tolerance
Configures logging and scanning outputs that feed the yearly review of threats and legacy system risks

How we hand over

Delivers a risk assessment register with methodology notes, scoring inputs and open treatment actions
Provides an inventory of accepted residual risks with draft justifications for management review
Documents the review cycle, triggers for reassessment after major changes and legacy system reviews
Hands over runbooks so the client's own teams can maintain the register after the engagement ends

How we support

Ongoing support and continuous testing are available as retainers for reassessments and yearly reviews
Supports the annual review of accepted residual risks with updated scans, configuration evidence and change records
Supports reassessment after major infrastructure changes, with the client confirming scope and approvals
Independent auditors or competent authorities assess the framework, and DeployOpen does not issue reports or attestations