Skip to content
Knowledge base Updated: February 5, 2026

KSC NIS2 or DORA? How does the financial sector need to reconcile the two regulations?

DORA is lex specialis for finance, but KSC/NIS2 still applies. How do you manage ICT risk, test resilience, and manage suppliers (TPPs) in accordance with both acts?

The financial sector is in a unique regulatory situation. While the economy as a whole prepares for the revolution associated with the amendment of the National Cyber Security System (NSC) Act, implementing the NIS2 Directive, financial institutions must simultaneously meet the requirements of another, much more stringent piece of legislation - the DORA (Digital Operational Resilience Act) Regulations. A key question arises: which of these regulations is more important, and does implementing one exempt us from the other?

The answer is not simple, but it is unambiguous: it is not a question of “either-or,” but “how to reconcile both.” KSC/NIS2 is a general, horizontal law on cyber security, while DORA is lex specialis - a specialized, vertical law, created precisely for the financial sector. This means that financial entities must implement the more specific requirements of DORA while not losing sight of the general KSC/NIS2 framework.

Shortcuts

What exactly is the DORA regulation and who does it apply to?

DORA, or the Financial Sector Operational Digital Resilience Regulation, is a European Union regulation that comes into force in January 2025. Its overarching goal is to standardize and strengthen the management of information and communication technology (ICT) risks across the EU financial sector.

Unlike the NIS2 Directive, which must be implemented into national law (like our KSC Act), DORA as a regulation operates directly in all member countries. It covers not only traditional entities such as banks, insurance companies or brokerage houses, but also (and this is a revolution) key third-party ICT service providers such as public cloud providers or specialized trading systems. As an integrator specializing in sector regulation, nFlo recognizes DORA as a key change agent for the entire industry.

📚 Read the complete guide: NIS2: Kompletny przewodnik po dyrektywie NIS2 - obowiązki, kary, terminy

The relationship is based on the classic principle of law: Lex specialis derogat legi generali (specific law overrules general law). KSC/NIS2 is a general (horizontal) law that establishes a baseline level of cyber security for many sectors of the economy. DORA is a specific (vertical) law that precisely regulates the financial sector.

In practice, this means that if DORA regulates an area (e.g., ICT vendor management or resilience testing) in greater detail than KSC/NIS2, the financial entity must apply the stringent requirements of DORA. In other areas that DORA does not cover in such detail, the financial entity is still subject to the general provisions of KSC/NIS2. Thus, neither regulation can be ignored.

Does the implementation of KSC/NIS2 requirements mean that we are DORA compliant?

Absolutely not. Such thinking is a trap that can be very costly. The implementation of KSC/NIS2 can be seen as a good foundation, but DORA puts much higher and more complex walls on top of it. Both regulations are based on the same risk management philosophy and both emphasize supply chain security, but the level of detail in DORA is incomparably higher.

For example, KSC/NIS2 requires “implementation of a risk analysis policy” and “appropriate measures.” DORA defines precisely what an ICT Risk Management System must include, what the classification of incidents should look like, and what specific resilience tests should be conducted. Treating compliance with KSC/NIS2 as an end goal will result in a financial organization failing to meet even half of the DORA requirements.

What are the key pillars of DORA that go beyond the KSC/NIS2 standard?

DORA is based on five key pillars, most of which are much more stringent than their counterparts in KSC/NIS2. These differences show why the financial sector needs to take a special approach.

  • ICT Risk Management: DORA requires the implementation of a comprehensive ICT risk management framework that is an integral part of the organization’s overall risk management. The level of detail in the policies, procedures and tools required is very high.

  • Incident Reporting: Like KSC/NIS2, DORA requires incident reporting. However, the classification system and reporting thresholds in DORA are unique to the financial sector and very precisely defined.

  • Digital Resilience Testing: This is one of the biggest differences. KSC/NIS2 speaks generally of “tests and audits.” DORA goes a step further, requiring key entities to conduct periodic, advanced Threat-Led Penetration Testing (TLPT).

  • Third Party Risk Management (TPPs): A revolution. KSC/NIS2 requires supply chain management. DORA introduces a full framework for managing risks associated with third-party ICT suppliers, including the requirement to have an exit strategy.

  • Information Sharing: DORA encourages the creation of mechanisms for sharing information about cyber threats in the sector.

What is the advanced resistance testing (TLPT) required by DORA?

This is not a standard penetration test that an organization mandates once a year to “tick off” compliance. TLPT is a much more advanced form of testing, also known as Red Teaming. It involves simulating a real, sophisticated attack (APT-type) targeting a company’s critical business functions.

TLPT tests must be conducted at least once every three years on key entities. They are carried out by third-party, certified testers (Red Team) who, based on analysis of real threats (Threat Intelligence), attempt to compromise the organization by testing its full resilience - technology, processes and people. This is much more than standard penetration testing of infrastructure or web applications.

How does DORA change the rules for supplier management (TPPs) compared to KSC/NIS2?

Supply chain management (SCRM) is important in KSC/NIS2. In DORA, it is absolutely critical and central. DORA talks not just about “suppliers,” but about “third-party providers of ICT services” (Third-Party Providers - TPPs).

KSC/NIS2 requires a company to audit its suppliers and include security clauses in contracts. DORA goes much further. It requires financial entities to have a full TPPs risk management strategy, which must include, among other things:

  • A very rigorous risk assessment before signing a contract.

  • Precise contractual clauses (much broader than in KSC/NIS2).

  • Full right to audit the supplier.

  • Exit strategy (exit strategy): The company must have a documented plan for how to end its relationship with a key supplier (e.g., a cloud provider) and move services elsewhere without disrupting operational continuity.

Most importantly, DORA introduces direct oversight by regulators (the so-called Supervisory Forum) of ICT providers deemed “critical” to the financial sector. This means that the regulator can control not only the bank, but also its cloud provider.

Is a 24/7 SOC monitoring system needed for DORA compliance?

Yes, and even more so than with KSC/NIS2. The ability to quickly detect and report incidents is the foundation of DORA. The regulation requires the implementation of very detailed mechanisms for detecting anomalies and incidents and classifying them immediately.

The requirement for 24-hour reporting with KSC/NIS2 is already a huge operational challenge. DORA adds a complex event classification matrix. In practice, the only way to meet these requirements is to have a mature Security Operations Center (SOC) that monitors the infrastructure 24/7.

However, such a SOC must be configured for DORA - its systems (SIEM/SOAR) and analysts must be trained to classify incidents not only according to general rules, but according to the precise taxonomy required by financial supervision (e.g., the FSA).

Can KSC/NIS2 and DORA be implemented in one project?

This is not only possible, but actually recommended and most cost-effective. Trying to run two separate compliance projects will lead to chaos, duplication of work and gigantic costs. Both regulations, despite their differences in detail, are based on the same foundation: risk management.

The START - CORE - RESILIENCE implementation model that nFlo uses for KSC/NIS2 can be perfectly replicated for DORA.

  • START PHASE: It starts the same way - with an audit and risk analysis, but immediately conducted in terms of both regulations.

  • CORE Phase: Building a CMS is the foundation. Instead of creating an SCRM policy (for KSC/NIS2), a more elaborate “TPPs Risk Management Strategy” (for DORA) is created right away.

  • RESILIENCE PHASE: Instead of an “ordinary” SOC, an SOC tailored to DORA reporting requirements is implemented right away. Instead of standard pentesting, advanced TLPT testing is planned.

The integrated approach makes it possible to build a single, consistent safety management system that meets the requirements of both pieces of legislation.

Why do you need a financially literate partner to implement DORA?

A KSC/NIS2 implementation requires a partner that combines GRC expertise and technology. DORA implementation requires the same, but at a much higher level of specialization. Knowledge of general ISO standards is not enough here. You need a partner who understands the specifics of the financial sector, the FSC and EBA guidelines, and the DORA logic itself.

The market is divided between GRC companies (“paper” consulting) and IT integrators (“box” implementations). The financial sector needs an end-to-end partner that can seamlessly bridge these worlds.

A partner such as nFlo, with a portfolio that includes both GRC services (consulting on sector regulations such as DORA or FSC guidelines ) and advanced cybersecurity services (penetration testing, SIEM/SOC implementations ), is able to guide a financial institution through the entire, complex process. Such a partner can both audit the GRC under DORA, and technically implement the requirement for advanced TLPT testing or implement an SOC capable of reporting in accordance with FSA requirements.

Comparison of Requirements: KSC/NIS2 vs. DORA

The table below shows the key differences in the approach of the two regulations. For the financial sector, DORA is always an overriding requirement.

Requirements AreaKSC Law (implementing NIS2) - Lex GeneralisDORA Regulation - Lex Specialis (Financial Sector)
BasisA risk-based approach.ICT risk management framework approach (much more detailed).
TestingRequire “regular testing and auditing” of security features.Require advanced resilience testing, including mandatory TLPT (Red Teaming) testing for key players.
Supply ChainSupply chain risk management (SCRM). Requirement to have policies, audits, contractual clauses.Third-party risk management (TPPs). Full management strategy, including the requirement for an exit strategy and direct regulator oversight of critical TPPs.
Incident ReportingStrict requirement (up to 24 hours) to report serious incidents to CSIRT.A very detailed system for classifying and reporting ICT incidents to the relevant supervisory authority (e.g., the FSA).
Implementation PartnerEnd-to-end integrator required (GRC + Technology).Required end-to-end integrator with expertise in DORA and FSC guidelines.

Learn key terms related to this article in our cybersecurity glossary:


Learn More

Explore related articles in our knowledge base:


Explore Our Services

Need cybersecurity support? Check out:


Cybersecurity for Your Industry

Learn more about cybersecurity in your industry:


See also:

Share:

Talk to an expert

Have questions about this topic? Get in touch with our specialist.

Sales Representative
Grzegorz Gnych

Grzegorz Gnych

Sales Representative

Response within 24 hours
Free consultation
Individual approach

Providing your phone number will speed up contact.

Want to Reduce IT Risk and Costs?

Book a free consultation - we respond within 24h

Response in 24h Free quote No obligations

Or download free guide:

Download NIS2 Checklist