The entry into force of DORA and NIS2 (Decree-Law no. 125/2025) has placed cybersecurity at the centre of strategic decision-making within organisations. Gradually, it ceases to be viewed as an exclusively technical issue and assumes a structural dimension within operational resilience.

However, in many cases, compliance with DORA and NIS2 continues to be addressed in the same manner as previous regulatory requirements: with a predominant focus on policies, processes and documentation. As a result, the real risk is relegated to the background, the risk that today materialises in software, secure development and the applications that support the business.

Complying with DORA and NIS2 does not merely mean demonstrating compliance. It means ensuring business continuity, preventive identification of threats, structured reactive incident response, preparedness for crisis scenarios, resilience and tested and effective recovery.

This begins in the code.

DORA and NIS2: operational resilience requires application security

The DORA Regulation and the NIS2 Directive require an integrated approach to digital risk management. In the current context, such resilience depends directly on the applications that support critical processes.

Applications:

  • process sensitive data,
  • connect value chains,
  • integrate third parties,
  • support essential operations.

Ignoring application security in DORA and NIS2 compliance creates a structural weakness between what the regulations require and what is effectively protected.

Regulatory compliance without application security is fragile resilience

Organisations must continue to invest in governance, risk management, monitoring and perimeter controls. These elements are indispensable.

However, none of these pillars is sufficient if the software supporting critical processes is not treated as a central component of the security strategy. Software is not static. It evolves continuously, undergoes numerous changes, integrates new dependencies and exposes new attack surfaces.

Occasional penetration tests or sporadic audits are not sufficient because application risk is real and continuous:

  • code vulnerabilities,
  • insecure dependencies,
  • design flaws,
  • configuration errors.

These are currently some of the main entry points for serious incidents. Building compliance with DORA or NIS2 without regularly assessing the application portfolio is, in practice, building resilience on an unstable foundation.

Recurring assessments and continuous application security

Both DORA and NIS2 reinforce the need for recurring assessments, continuous detection and response capability, and sustained improvement of the security posture.

This principle conflicts with reactive approaches to application security centred on isolated interventions or corrective actions only after incidents.

Regulatory maturity requires continuity and integration between:

  • threat modelling,
  • static or interactive code analysis,
  • vulnerability management,
  • dynamic testing and recurring technical assessments.

Without such continuity, compliance with DORA and NIS2 tends to remain formal rather than substantive.

Application security and organisational culture under NIS2

NIS2 goes beyond the technical dimension. It reinforces organisational accountability and requires profound cultural changes.

Software security cannot remain confined to technical teams. It must involve those who develop, those who operate, those who manage risk and those who make strategic decisions. Without such transversal integration, application security becomes an isolated technical exercise, disconnected from strategy and incapable of genuinely influencing the organisation’s maturity level.

From requirement to practice: aligning application security with DORA and NIS2 objectives

The challenge does not lie in adding another layer of compliance, but in aligning application security with the true objectives of the regulations: reducing operational risk, protecting critical digital assets, ensuring business continuity and strengthening digital resilience.

This requires viewing software as a living asset, subject to constant change, external dependencies and continuous exposure to new threats.

DORA and NIS2 have raised the level of regulatory demand and, in doing so, exposed a recurring weakness: the difficulty in translating legal requirements into effective digital risk control.

As long as application security is treated as a technical detail, this gap will persist. Strengthening resilience begins where risk is most critical today: in the code.