When an attack comes, speed of response decides. How NIS2 and DORA change management accountability

For failing to implement security measures or to report cyber incidents, Czech companies face a fine of up to 250 million CZK or 2 % of turnover (whichever is higher). Responsibility for meeting these obligations lies directly with the company's management, which may face personal sanctions, including financial penalties and a ban on holding office.

DORA is even stricter. Banks, insurers and investment firms face fines of up to 2 % of global turnover (or fixed amounts of up to 10 million euros, for example) and personal sanctions for management of up to 1 million euros. It also comes down hard on the key IT suppliers of the financial sector, for whom it allows repeated fines of up to 1 % of average daily global turnover as well as administrative sanctions of up to 5 million euros.

Earlier regulation did effectively involve management, especially in decisions about risks, budgets and process design, but its impact was limited to personal data and it did not work with personal accountability to this extent. NIS2 and DORA now fundamentally change this practice and explicitly place responsibility for setting up, supervising and effectively running security measures directly on the organisation's leadership and its top management.

In practice this means above all:

⇢ measuring the organisation's ability to keep services available during an incident: how quickly it can detect an attack or a failure, escalate the situation, decide on an intervention, limit the impact and restore operations without a major interruption, and which steps depend on manual human intervention.

⇢ verifying whether the protection matches actual operations and preserves the integrity of services: an overview of whether the security perimeter covers the places where applications, services and APIs actually run today and from where users, partners and suppliers connect to them, not merely the historically defined boundaries of the infrastructure.

⇢ ensuring the ability to report to regulators in time, that is having unified data, clearly defined roles and responsibilities and pre-prepared procedures for reporting incidents that may threaten the availability or integrity of services within the statutory deadlines.

⇢ tightening third-party risk management with regard to service continuity, including contractual security requirements, audit rights, ongoing risk assessment, clearly defined termination conditions and realistic exit plans that do not endanger operations.

With NIS2 you must already be able to prove you know how to manage security

NIS2 fundamentally widens the range of organisations that must manage cybersecurity systematically and demonstrably. It no longer concerns only a narrow circle of critical infrastructure but as many as 6,000 companies across industries. From energy, transport and healthcare through logistics, manufacturing and retail to digital services and IT outsourcing. For many organisations it is the first regulation that explicitly tells them security is not optional and cannot be handled ad hoc.

The main change compared with the past is therefore not in individual technical measures but directly in the approach. NIS2 does not care which tool you use but whether you have management under control. You can no longer rely on having some security tools deployed if:

• you cannot manage risks systematically,
  
  
• you cannot evidence how your security measures are configured and maintained,
  
  
• you cannot detect and handle a security incident in time,
  
  
• or you are not clear about who is responsible for what.
  
  

Attention is also shifting to the supply chain. If your key business systems, applications or operations depend on third parties, your responsibility does not end with them; quite the opposite. NIS2 expects organisations to manage the risks that come "from outside" too, and to be prepared to bear the consequences of their failure.

From the management's point of view there is one more fundamental change: the regulation explicitly works with the role of management and its duty to approve the approach to risk management, oversee the functioning of the measures and ensure that the organisation can stand up both to an inspection and to a real incident. Otherwise it is already a management failure.

DORA: even if IT is outsourced, responsibility stays with the institution

DORA says clearly: if the technology fails, the financial institution fails too, regardless of how many reserves it has. The regulation therefore puts digital operational resilience on the same level as traditional risk management. For banks, insurers, investment companies, payment institutions and their technology partners this means it is no longer enough to "handle an incident". They must be able to prevent risks, detect them quickly, manage their impact, restore operations and document the whole process for the regulators.

In practice DORA forces organisations to put in order four areas that often used to exist separately or only on paper:

• ICT risk management as an ongoing process, not a one-off audit,
  
  
• reporting of major incidents according to clear criteria and in the prescribed structure,
  
  
• resilience testing that is meant to reveal real weaknesses, not just "tick a box",
  
  
• supplier risk management, including contracts, audits, an overview of dependencies and prepared scenarios for what to do when a supplier fails.

Here too the fundamental shift compared with the past is above all in responsibility. Even if part of the infrastructure is outsourced or run in the cloud, full responsibility lies with the financial institution. An argument such as "it was the supplier's problem" will not relieve you of responsibility. If you lack overview, control and the ability to intervene in the event of a security incident, that is a regulatory problem.

Both NIS2 and DORA explicitly move responsibility for cybersecurity from the purely operational level to the level of organisational governance. That does not mean statutory bodies take over the technical tasks of IT teams, but that they are responsible for setting up, approving and overseeing the security risk management system as a whole.

In practice this means management is obliged above all to:

• approve the security strategy and the corresponding technical and organisational measures,
  
  
• ensure adequate resources for their implementation (people, money and processes),
  
  
• exercise ongoing oversight of their functioning and effectiveness,
  
  
• and be able to prove that the organisation acted in proportion to the nature of the risks, its size and the regulatory requirements.

The implementation of both frameworks is also reflected in data from the IAPP Privacy Governance Report 2024, according to which more than 80 % of professionals say they have been given additional tasks beyond their usual privacy agenda. The newer EU Digital Laws Report 2025 confirms the trend. Roughly 32 % to 40 % of respondents are now responsible for compliance with cybersecurity regulations (such as NIS2).

How to meet this responsibility in practice?

With the arrival of NIS2 and DORA, security architecture is no longer just a technical choice but a management risk. How your security is built directly determines how quickly your organisation can act during an incident, whether it responds automatically or only after a series of manual interventions, escalations and approvals. The assessment by regulators then depends on whether the incident is handled within minutes or only once it already affects operations, clients and regulatory obligations.

Speed of response is today a de facto regulatory parameter. Yet some traditional security models, especially those based on a manually managed, rigidly defined perimeter, hit their limits in this respect.

These approaches arose at a time when an organisation had a clearly bounded infrastructure. Today's hybrid environment with cloud, remote users and connected suppliers means that a significant share of risk arises outside that perimeter.

In a traditional, manually managed perimeter, the response to an incident typically consisted of several steps: the incident had to be assessed, context gathered, an intervention decided, a change approved, a rule deployed and the impact on operations verified. Each of these steps had a different owner, often a different team, and delays arose between the phases. Attacks, however, do not follow an organisation's internal processes. DDoS attacks today are not hour-long or day-long incidents; many of them last only tens of minutes. For protection to fulfil the purpose of the regulation and protect operations, mitigation must happen faster than the attack itself lasts. Protection that only starts after a round of escalations and approvals comes too late, even if it is technically configured correctly.

Add to that the physical limits of capacity: once the connection is saturated, the protection loses its effect. Distributed cloud models, by contrast, make it possible to react immediately and stop the attack before it threatens the availability of the service.

The authorities want proof; declarations are no longer enough

Neither NIS2 nor DORA is concerned only with whether the attack was stopped, but with whether the organisation can demonstrably document what happened, when it reacted, who made the decisions, which steps were taken and with what impact. If security is fragmented across several tools, teams and suppliers, the audit trail is hard to assemble and often only in hindsight. A unified, centrally managed approach, on the other hand, provides consistent data for internal evaluation and regulatory reporting, measurable response times, traceable decision-making and a single record of incidents.

NIS2 and DORA focus on the management of risks, incidents, business continuity and supplier relationships. Frameworks based on enforceable controls, audits and contractual responsibility therefore come to the fore. Cloudflare, for example, states that its approach to privacy is recognised in 39 jurisdictions.

The same logic applies to the supply chain. Organisations must be able to prove they have an overview of third-party risks and clearly defined procedures for escalation, decision-making and documentation. In such an environment a unified security platform is no longer a matter of comfort or IT efficiency but the way an organisation's leadership genuinely keeps its personal accountability, response speed, overview of risks and ability to defend everything before the regulator under control.