DIGITAL OPERATIONAL RESILIENCE

What is DORA?
A financial sector
resilience framework.

The Digital Operational Resilience Act addresses ICT risk in the financial sector. It brings together requirements for covered financial entities across risk management, incident management and reporting, resilience testing, and ICT third-party risk.

External vulnerability reports can provide useful information about affected systems or services. A managed disclosure process helps that information reach the people responsible for assessment and action. The contribution needs to be defined within your entity’s wider DORA programme.

Framework overview: ESMA: Digital Operational Resilience Act.

APPLICABLE SINCE17 January 2025

Confirm your entity category, exclusions, proportionality, and applicable risk-management framework. The Article 10 mapping below concerns Title II of Delegated Regulation (EU) 2024/1774. Entities using the simplified framework under DORA Article 16 need to assess their corresponding requirements separately.

HACKRATE SERVICES

Turn external findings into
a managed disclosure process.

Build the route from first contact to internal ownership. Agree the service scope, communication coverage, and handoffs around the systems and teams involved.

RECEIVE

A clear disclosure channel

Give researchers and other external reporters a structured route for security findings. Capture the affected application or service, technical description, reproduction details, and supporting evidence without encouraging access to customer data.

Explore managed VDP
ASSESS

Human validation and context

Review relevance, duplicates, reproducibility, and demonstrated impact within the agreed service. Keep limitations and unanswered questions visible so your security team can combine technical evidence with service and business context.

See vulnerability triage
COORDINATE

Reporter and supplier handoffs

Keep clarification requests and reporter updates connected to the finding. Where a supplier is involved, route the relevant evidence to your designated vendor owner and agree how the parties exchange progress and technical questions.

Connect the responsible teams
FOLLOW THROUGH

Remediation records

Connect findings to engineering ownership, decisions, and remediation progress. Include agreed verification outcomes and disclosure coordination in the record so internal reviewers can understand the work and its limitations.

See the evidence to retain

CONNECT THE REQUIREMENT TO THE WORK

Where managed VDP
supports your DORA process.

Define the contribution alongside your existing procedures. The mapping explains how the service can support selected vulnerability management activities under the applicable technical rules.

ARTICLE 10(2)(a)

Vulnerability awareness

The technical rules address relevant and trustworthy information resources for maintaining vulnerability awareness.

Managed VDP contribution

External disclosures can add a source of technical information. Managed intake helps review and route that information alongside your other monitoring resources.

ARTICLE 10(2)(c)

Supplier vulnerability handling

The rules address how ICT providers handle vulnerabilities and report critical vulnerabilities and related information to the financial entity.

Managed VDP contribution

Retain the affected service and supplier context, and route relevant findings to your vendor owner. Your organisation manages the contractual obligations and supplier follow-through.

ARTICLE 10(2)(e)

Responsible disclosure

Procedures cover responsible disclosure of vulnerabilities to clients, counterparties, and the public.

Managed VDP contribution

A reviewed technical record and coordinated reporter communication can support your disclosure decisions. Your organisation owns the audience, content, timing, and delivery of those communications.

ARTICLE 10(2)(g) AND (h)

Remediation and resolution records

The rules address recording detected vulnerabilities, tracking resolution, and monitoring and verifying remediation.

Managed VDP contribution

Connect findings, evidence, owners, and progress in the agreed workflow. Include verification when contracted, while your team owns fixes and the completeness of its institutional records.

Legal reference: Delegated Regulation (EU) 2024/1774, Article 10. The service contributions above describe an agreed operating arrangement.

Receiving a report and disclosing to clients are separate activities.

Article 10(2)(e) concerns responsible disclosure to clients, counterparties, and the public. A managed reporting channel supplies evidence and coordination for that work. Your organisation still needs the process and authority to decide what to communicate, when, and through which channels.

FROM EXTERNAL REPORT TO INTERNAL ACTION

Receive. Assess.
Route. Follow through.

Keep report handling connected to service context, engineering, and incident owners. Urgent evidence moves to the responsible team while validation and clarification continue.

01

Define and receive

Agree the reporting policy, channel, relevant services, handling of sensitive evidence, and communication coverage. Name the internal security owner and the route for urgent information before launch.

02

Review and clarify

Hackrate reviews the submission and requests useful missing details. Any reproduction work follows the agreed authorisation, environment, and access. Separate observed impact from claims that require further investigation.

03

Route and decide

Your organisation identifies the affected service, criticality, supplier dependencies, and engineering owner. Incident and risk teams assess urgent evidence while routine validation continues.

04

Remediate and coordinate

Your engineers or responsible supplier implement the fix or mitigation. Keep progress and reporter communication connected, record verification where agreed, and coordinate external disclosure with your authorised owners.

KEEP THE RESPONSE REVIEWABLE

A finding needs
service context.

Agree which records your security, engineering, risk, and review teams need. A technical report becomes more useful when it is connected to the affected service and the decisions that follow.

Set access, evidence handling, reporting format, retention needs, and any included retesting during scoping. Your organisation determines how the resulting records fit its formal documentation.

01 / AFFECTED SERVICE

Assets and dependencies

Identify the relevant application, service, version, and supplier context. Your team adds the business function, criticality, and operational dependencies.

02 / TECHNICAL FINDING

Evidence and limitations

Keep reproduction information, supporting evidence, demonstrated impact, and unanswered questions together. Avoid collecting unnecessary customer or transaction data.

03 / RESPONSE

Owners and progress

Connect the engineering or supplier owner, chosen action, internal decisions, and progress. Keep the reporter conversation linked to the same finding.

04 / FOLLOW-THROUGH

Verification and communication

Where included, record the verification result and remaining limitations. Your owners decide client advisories, public disclosure, and any authority notifications.

GIVE IMPORTANT DECISIONS AN OWNER

Three handoffs
to define before launch.

Clarify how external evidence reaches the teams with the authority to act. Agree backup contacts and escalation routes as part of the operating arrangement.

SECURITY AND ENGINEERING

Risk and remediation

Your teams assess service impact, prioritise the response, and implement fixes or mitigations. Hackrate contributes reviewed technical information and agreed coordination.

ICT SUPPLIER OWNER

Third-party follow-through

Your vendor owner coordinates the provider’s investigation and contractual obligations. Agree how evidence, affected services, progress, and resolution information are exchanged.

INCIDENT AND COMMUNICATION OWNERS

Classification and disclosure

Your organisation assesses major incident reporting and external communication. Incoming reports are not automatically major ICT-related incidents; relevant evidence needs prompt review.

Incident framework: DORA, Articles 17 to 20. Agree the current classification, notification procedure, and applicable technical standards with your responsible team.

A SERVICE WITH A DEFINED CONTRIBUTION

Managed disclosure.
Your resilience programme.

Scope the service around your actual reporting needs and internal capacity. Keep the wider DORA workstreams connected to their responsible owners.

Hackrate’s agreed role

  • Receive disclosures through the agreed channel.
  • Review technical claims, request evidence, and coordinate reporter communication.
  • Provide a finding and handoff with assessment limits and open questions.
  • Support agreed verification, status records, and disclosure coordination.

Your organisation’s ownership

  • Determine applicability, governance, and the requirements of your framework.
  • Own risk decisions, remediation, supplier obligations, and client communication.
  • Classify incidents and submit any required authority notifications.
  • Maintain wider ICT controls, monitoring, testing, continuity, and formal records.

Managed VDP supports part of vulnerability handling. Required scanning and resilience testing, including TLPT where applicable, need their own arrangements. A disclosure engagement does not provide complete DORA compliance or an automatic authority reporting integration.

YOUR QUESTIONS, ANSWERED

DORA & managed
VDP FAQs.

Understand the service contribution, financial sector context, and decisions that remain with your organisation.

Discuss your requirements
How does managed VDP support DORA compliance work?

Hackrate managed VDP can support external vulnerability intake, human validation, reporter communication, and a documented handoff to your security team. The resulting technical record can feed your vulnerability management and disclosure processes. Define the service contribution within your applicable DORA framework, with your organisation retaining risk, remediation, regulatory reporting, and compliance decisions.

Which organisations should assess DORA applicability?

DORA applies to covered financial entities, with categories, exclusions, and proportionality rules defined in the regulation. Banks, payment institutions, investment firms, and insurers are examples of the sectors addressed. ICT suppliers also need to understand relevant customer contracts and any obligations that apply to their own role. Supplying a financial entity does not automatically make a provider subject to every financial-entity requirement.

Does DORA require us to buy a public VDP or bug bounty programme?

The technical rules address vulnerability management and responsible disclosure. A managed VDP is a service that can support part of that operating process. It should not be described as a universal requirement to purchase a public intake or bounty programme. Any invitation to actively test systems, researcher access, or reward commitment needs separate terms and authorisation.

Does accepting external reports satisfy responsible disclosure to clients?

Receiving a report and communicating vulnerability information to clients, counterparties, or the public are different activities. Article 10(2)(e) of Delegated Regulation (EU) 2024/1774 addresses the latter. Managed intake can provide useful evidence and coordination, but your organisation still needs procedures and owners for deciding and delivering appropriate external disclosure.

Is every vulnerability report a major ICT-related incident?

No. Your designated incident team must assess the facts against the applicable DORA classification and reporting requirements. A vulnerability report can contain information requiring urgent assessment, but an intake status or severity label does not determine the statutory outcome. Escalate relevant evidence promptly and keep the authority reporting process connected to the responsible internal team.

Can managed VDP replace DORA security testing or TLPT?

Managed disclosure receives and handles reports through an agreed channel. Your wider DORA programme must separately address the testing, scanning, and other requirements applicable to your organisation. A VDP is not a substitute for required automated assessments or threat-led penetration testing. Scope any active security testing as a separate engagement.

What records can our team retain from the process?

Agree the report format, access, retention needs, and included activities. Useful records can cover affected assets, technical evidence, validation limits, reporter discussion, ownership, decisions, remediation progress, and verification where included. Your organisation determines how those records fit its formal documentation and supervisory requirements.

Does managed VDP provide complete DORA compliance?

The service supports a defined part of vulnerability handling. DORA also covers wider ICT risk management, incident management and reporting, resilience testing, and third-party risk. Your organisation remains responsible for those workstreams and the requirements of its applicable framework. The service does not constitute a DORA certification or a complete operational resilience assessment.

Should a financial entity follow both NIS2 and DORA reporting rules for the same obligation?

DORA is the sector-specific EU legal act for relevant financial entities under NIS2 Article 4. Its corresponding requirements take precedence in the areas addressed by that relationship. Determine your entity’s applicable framework and authority process before using either set of requirements. Other group entities or suppliers may require a separate assessment.

OFFICIAL REFERENCES

Read the source.
Define your scope.

Reviewed 25 October 2026

Use current official texts and supervisory guidance for your applicability and legal assessment. Define the managed VDP contribution separately within your operating process.

CONNECT DISCLOSURE TO DAILY OPERATIONS

Give every report
a route to action.

Bring your services, existing reporting channels, and decision owners. Build a managed disclosure process that supports your financial organisation’s vulnerability management work.

Plan Your DORA Disclosure
Hackrate

Our platform helps companies to identify software vulnerabilities in a cost-efficient way. It provides a secure and centralized view of ethical hacking projects for your company.

US Patent Applied for HackGATE #63/645,845

Hackrate Status

Hackrate Ethical Hacking Platform |
2026 ©

CVE Program Numbering Authority