Article 13 requires "the segregation and segmentation of ICT systems and networks" taking account of supported-function criticality or importance, Article 8(1) classification, and the ICT assets' overall risk profile.

Network architecture review

Article 13 requires reviews of network architecture and network-security design once a year, and periodically for microenterprises, to identify potential vulnerabilities.

Non-production data default

"non-production environments only store anonymised, pseudonymised, or randomised production data". Production data are permitted only under the Article 16(6) derogation and its conditions.

An ICT-related asset whose classification and overall risk profile are repeatedly relevant to how the Regulation's controls are designed and applied.

What is Static testing?

Testing performed by examining software or source code without executing the program; Article 16 requires source-code reviews covering static and dynamic testing.

What is Dynamic testing?

Testing performed while software is executed or exercised; Article 16 requires source-code reviews covering static and dynamic testing.

Regulation 2024/1774: Networks, Secure Development, Change, Identity, and Access — Commission Delegated Regulation (EU) 2024/1774 and Related DORA Secondary Legislation: An Advanced Deep Dive

1. Orientation: Boundary Security Is a System of Controls

A connected control chain

Articles 13-21 connect network protection, information in transit, secure projects and development, change governance, physical security, staff duties, identity management, and access control.

The operative pattern

The Regulation repeatedly requires financial entities to develop, document, and implement controls. A written policy alone is therefore not the complete requirement.

Risk-sensitive application

Several duties depend on ICT classification, overall risk profile, criticality, importance, and qualifiers such as where feasible and appropriate. Preserve those limits exactly.

2. Article 13: Designing and Operating Secure Networks

Segment according to risk

Article 13 requires "the segregation and segmentation of ICT systems and networks" using function criticality or importance, Article 8(1) classification, and the ICT assets' overall risk profile.

Know the connections

The Regulation requires "the documentation of all of the financial entity’s network connections and data flows", a dedicated administration network, and controls against unauthorised or non-compliant endpoints.

Protect and harden

Encryption applies across corporate, public, domestic, third-party, and wireless networks. Article 13 also requires secure external traffic, isolation where necessary, configuration baselines, and hardening.

3. Article 13 Reviews and Article 14 Information in Transit

Firewall review threshold

Firewall rules and connection filters require regular review based on classification and risk. For critical or important functions, adequacy verification is required at least every 6 months.

Architecture and sessions

Network architecture and security design are reviewed once a year, and periodically for microenterprises. Sessions must be limited, locked, and terminated after specified inactivity.

Information in transit

Article 14 requires protection of availability, authenticity, integrity, and confidentiality during transmission; data-leakage controls; secure external transfers; and reviewed confidentiality arrangements.

4. Quiz: Network Security Decisions

Choose the answer that most accurately reflects Articles 13 and 14 of the Regulation.

A financial entity operates an ICT system supporting a critical function. Which statement is required by Article 13?

It shall verify the adequacy of existing firewall rules and connection filters at least every 6 months.
It shall review firewall rules once a year, with no more frequent review needed.
It may review firewall rules only after an ICT-related incident.
It shall replace all firewall rules every 6 months.

Show Answer

Answer: A) It shall verify the adequacy of existing firewall rules and connection filters at least every 6 months.

Article 13 requires regular review based on classification and risk profile, and adds a specific minimum: for ICT systems supporting critical or important functions, adequacy of existing firewall rules and connection filters shall be verified at least every 6 months. The Article does not require wholesale replacement of rules.

5. Article 15: Governing ICT Projects Before Deployment

A policy for the project lifecycle

Article 15 requires an ICT project management policy for acquisition, maintenance, and, where applicable, development. It must enable "the effective management of the ICT projects" in that scope.

Minimum project contents

Required contents include objectives, governance, roles, plans, timeframes, risk assessment, milestones, change requirements, testing of all requirements including security, and production approval.

Management-body visibility

Projects affecting critical or important functions and associated risks are reported to the management body individually or in aggregation, periodically and, where necessary, event-driven.

6. Article 16: Secure Acquisition, Development, Testing, and Maintenance

Secure lifecycle policy

Article 16 requires security practices, specifications, approved requirements, and measures against unintentional alteration or intentional manipulation during development, maintenance, and deployment.

Testing is proportional, not optional

All ICT systems require testing and approval before use and after maintenance. "The level of testing shall be commensurate to the criticality of the business procedures and ICT assets concerned."

Code, packages, and environments

Procedures require "source code reviews covering both static and dynamic testing", package testing no later than integration, and protected non-production data and environments.

The narrow data derogation

Production data may be stored only for specific testing occasions, for limited periods, after relevant-function approval and reporting of those occasions to ICT risk management.

7. Quiz: Testing and Non-Production Data

Test your ability to distinguish the Article 16 default rule from its limited derogation.

Which arrangement matches Article 16(5) and Article 16(6)?

A test environment normally stores anonymised, pseudonymised, or randomised production data; actual production data may be stored only for specific testing occasions, limited periods, relevant-function approval, and reporting to ICT risk management.
A test environment may permanently store production data whenever developers need realistic records.
Only anonymised data may ever be used in testing, without exception.
Production data may be used freely in non-production if access is restricted to developers.

Show Answer

Answer: A) A test environment normally stores anonymised, pseudonymised, or randomised production data; actual production data may be stored only for specific testing occasions, limited periods, relevant-function approval, and reporting to ICT risk management.

Article 16(5) establishes the default that non-production environments only store anonymised, pseudonymised, or randomised production data. Article 16(6) creates a conditional derogation for actual production data: specific testing occasions, limited periods, relevant-function approval, and reporting to the ICT risk management function.

8. Articles 17 to 19: Change Control, Physical Security, and Staff Duties

Change governance

Article 17 applies to all listed software, hardware, firmware, system, and security-parameter changes. It requires security verification, independent approval functions, controlled testing, quality assurance, and fall-back arrangements.

Emergency is not exempt

Emergency changes need adequate safeguards and must be documented, re-evaluated, assessed, and approved after implementation, including workarounds and patches.

Physical and environmental protection

Article 18 requires measures against attacks, accidents, and environmental threats or hazards, proportionate to the importance of locations and the criticality of operations or systems there.

Personnel as a control layer

Article 19 requires assigned security responsibilities, staff awareness and adherence to ICT-security policies, awareness of anomalous-behaviour reporting channels, and return of assets at employment termination.

9. Articles 20 and 21: Identity, Least Privilege, and Access Reviews

One person, traceable access

Article 20 requires unique identification and authentication. Subject to Article 21(c), each relevant staff member must have a unique identity corresponding to a unique user account.

Identity lifecycle

Creation, change, review, update, temporary deactivation, and termination must be managed. Identity-assignment records remain after reorganisations or contractual endings, subject to applicable retention law.

Least privilege and review cadence

Access follows need-to-know, need-to-use, and least privilege. Rights are updated as necessary, at least annually generally, and at least every 6 months for critical or important-function systems.

Strong and physical access controls

Strong authentication is required for remote, privileged, critical-or-important-function, and publicly accessible ICT-asset access. Physical access must be authorised, logged, monitored, and promptly revoked when unnecessary.

10. Flashcards: Recall the Exact Regulatory Anchors

Flip each card and explain the rule aloud. Focus on the trigger, frequency, and qualifier rather than only the headline term.

Network segmentation: Article 13 requires "the segregation and segmentation of ICT systems and networks" taking account of supported-function criticality or importance, Article 8(1) classification, and the ICT assets' overall risk profile.
Firewall review for critical systems: For ICT systems supporting critical or important functions, adequacy of existing firewall rules and connection filters shall be verified at least every 6 months.
Network architecture review: Article 13 requires reviews of network architecture and network-security design once a year, and periodically for microenterprises, to identify potential vulnerabilities.
Testing proportionality: "The level of testing shall be commensurate to the criticality of the business procedures and ICT assets concerned."
Non-production data default: "non-production environments only store anonymised, pseudonymised, or randomised production data". Production data are permitted only under the Article 16(6) derogation and its conditions.
Change-function independence: Article 17 requires mechanisms ensuring independence between functions approving changes and functions requesting and implementing them.
Unique identity: Subject to Article 21(c), each relevant staff member must receive a unique identity corresponding to a unique user account.
Strong authentication trigger: Strong authentication methods are required for remote network access, privileged access, access to ICT assets supporting critical or important functions, and publicly accessible ICT assets.

Key Terms

ICT asset: An ICT-related asset whose classification and overall risk profile are repeatedly relevant to how the Regulation's controls are designed and applied.
Static testing: Testing performed by examining software or source code without executing the program; Article 16 requires source-code reviews covering static and dynamic testing.
Dynamic testing: Testing performed while software is executed or exercised; Article 16 requires source-code reviews covering static and dynamic testing.
Least privilege: The principle that access rights are assigned only to the minimum extent needed, alongside need-to-know and need-to-use principles.
Emergency change: A change managed through procedures, protocols, and tools that provide adequate safeguards and that is documented, re-evaluated, assessed, and approved after implementation.
Privileged access: Elevated access, such as administrator access, which Article 21 requires to be assigned on a need-to-use or ad-hoc basis and protected by strong authentication.
Network segmentation: Separation of ICT systems and networks based on the supported function's criticality or importance, Article 8(1) classification, and the overall risk profile of ICT assets.
Information in transit: Information while it is being transmitted over networks; Article 14 requires protection of its availability, authenticity, integrity, and confidentiality.
Non-production environment: An environment other than production. Under Article 16, it only stores anonymised, pseudonymised, or randomised production data, subject to the limited Article 16(6) derogation.
Critical or important function: A function whose supporting ICT systems trigger specific heightened requirements in this module, including firewall-rule verification and access-right review at least every 6 months.