Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.


Connecting your security stack & resolution processes seamlessly.


Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.


Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.


Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.


Download whitepapers & research on hot topics in the security field.

About us

Who we are, where we came from, and our Bright vision for the future.


Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
What Is Dora and Why Is It Critical

What Is Dora and Why Is It Critical

Edward Chopskie

The Digital Operational Resilience Act (DORA) is a new regulation that was adopted by the European Union (EU)  in December 2022. The act aims to improve the digital resilience of the financial sector by requiring financial institutions to implement robust measures to prevent, detect, and respond to ICT-related disruptions and threats. The core goal is to prevent and mitigate cyber threats.

ICT (Information and Communication Technology) risks refer to the potential threats and vulnerabilities that can impact the confidentiality, integrity, and availability of information and technology systems. Here are some common ICT risks:

  • Cybersecurity threats: These include malware, viruses, hacking, data breaches, phishing attacks, ransomware, and other malicious activities that can compromise sensitive information and disrupt systems.
  • Data breaches: Unauthorized access to sensitive data, either due to external attacks or internal breaches, can result in the loss, theft, or exposure of valuable information.
  • System downtime: Unplanned outages or system failures can disrupt business operations, leading to financial losses, reduced productivity, and customer dissatisfaction.
  • Software vulnerabilities: Weaknesses or flaws in software applications can be exploited by attackers to gain unauthorized access, manipulate data, or disrupt system functionality.
  • Human error: Mistakes made by employees, such as accidental data deletion, misconfiguration of systems, or falling for social engineering scams, can expose organizations to significant risks.
  • Insider threats: Employees or authorized individuals who misuse their access privileges to steal data, sabotage systems, or compromise security pose a risk to organizations.
  • Lack of IT governance: Inadequate policies, procedures, and controls related to ICT can result in non-compliance, weak security practices, and inefficient resource allocation.
  • Infrastructure failures: Failures in hardware components, network infrastructure, or power supply can disrupt ICT operations and cause data loss or downtime.
  • Third-party risks: Dependence on external vendors, cloud service providers, or partners introduces risks associated with their security practices, reliability, and compliance.
  • Regulatory and legal compliance: Failure to comply with industry regulations, data protection laws, or privacy requirements can result in legal repercussions, financial penalties, and reputational damage.

The primary purpose of DORA is to ensure the operational resilience of the EU financial sector. DORA complements existing laws such as the Network and Information Security Directive (NISD) and the General Data Protection Regulation (GDPR)

DORA applies to all financial institutions in the EU. That includes traditional financial entities such as banks, investment firms, and credit institutions, and non-traditional entities, like crypto-asset service providers and crowdfunding platforms. 

DORA also applies to some entities typically excluded from financial regulations. For example, third-party service providers that supply financial firms with ICT systems and services such as cloud service providers (CSPs) and data centers must follow DORA requirements. Lastly, DORA also covers firms that provide critical third-party information services such as credit rating services and data analytics providers. 

Organizations covered by Digital Operational Resilience Act need to implement risk management processes that help to identify potential vulnerabilities to credible cyber threats and put policies and security controls into place to protect against these risks. Organizations must test their ICT systems regularly to evaluate the strength of their protections and identify ‌vulnerabilities.

The key requirements of DORA include:

  • Risk management: Financial institutions must have a comprehensive risk management framework in place to identify, assess, and mitigate ICT risks.
  • Incident reporting: Financial institutions must report all significant ICT incidents to their national supervisory authorities.
  • Resilience testing: Financial institutions must regularly test their resilience to ICT disruptions.
  • Third-party oversight: Financial institutions must perform due diligence on critical third-party providers and monitor their performance on an ongoing basis.

Testing applications clearly falls into resilience testing. Software resilience testing is a method of software testing that focuses on ensuring that applications and APIs will perform well in real-life or chaotic conditions. In other words, it tests an application, or API’s resiliency, or ability to withstand stressful or challenging factors. 

Dynamic Application Security Testing (DAST) can be an excellent addition for resilience testing. (DAST) primarily focuses on identifying vulnerabilities and security flaws within applications in a compiled environment and during runtime. While its main purpose is not specifically related to resiliency testing, DAST can indirectly support aspects of resiliency testing through the identification and remediation of security weaknesses. Below are a few ways that DAST can contribute to resilience testing:

1. Identification of security weaknesses: DAST tools actively scan applications to identify security vulnerabilities such as SQL injection, cross-site scripting (XSS), and insecure configurations amongst many others. By addressing these vulnerabilities, organizations can improve the resilience of their applications against potential attacks that may impact availability or compromise data integrity. A developer-centric DAST should be part of the development lifecycle to identify and remediate vulnerabilities earlier in the SDLC well before production.  

2. Validation of error handling and exception management: Resilient applications should be capable of handling unexpected errors and exceptions gracefully. DAST can help identify areas within the application where error handling and exception management may be inadequate or inconsistent, allowing organizations to improve their resiliency by addressing these issues.

3. Integration with broader testing and monitoring processes: DAST can be integrated into a broader testing and monitoring framework. By incorporating DAST into an overall resiliency testing strategy, organizations can assess how security vulnerabilities may impact the resiliency of their applications. 

While DAST may not directly focus on all aspects of resiliency testing, its ability to identify and remediate security weaknesses can contribute to overall application resilience. And of course it is important to complement DAST with other testing techniques and methodologies that specifically target resiliency to ensure comprehensive testing coverage.

To summarize, by imposing these regulations, DORA aims to foster a more secure and resilient financial sector, where institutions are well-prepared to navigate operational risks, withstand cyber threats, and effectively respond to potential disruptions. Compliance with DORA is not only a legal requirement but also a means to instill trust and confidence among customers and stakeholders in the financial industry. And of course there are public reprimands and fines for non-compliance Institutions may face fines up to 10 million euros or 5% of their total annual turnover. Download how Bright helps organizations become DORA compliant here


DORA: Exploring The Path to Financial Institutions’ Resilience

DORA (Digital Operational Resilience Act) is the latest addition to the EU regulatory arsenal. A framework designed to bolster the cyber resilience of financial entities operating within the EU. But let’s face it: there’s no lack of regulations issued by the European Union legislature, and they’re not exactly known for keeping things light and easy.

IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

Get our newsletter