SkarpChapter 5 of 11
Regulation 2024/1774: Simplified ICT Framework and Final Provisions
Proportionality does not mean the absence of disciplined control. This chapter traces the simplified framework from governance and risk assessment through technical safeguards, continuity planning, review reporting, and the Regulation’s binding entry into force.
Orientation: What the Simplified Framework Requires
A simplified framework is still a framework
Title III applies to the financial entities referred to in Article 16(1) of Regulation (EU) 2022/2554. Simplification does not remove duties to govern, document, protect, test, recover, and report.
Read qualifications carefully
The Regulation often calibrates requirements using phrases such as commensurate, where applicable, and as needed. These qualifiers limit how a duty applies; they must not be erased.
The architecture of this lesson
Chapter I covers governance and risk foundations. Chapter II covers safeguards. Chapter III covers continuity. Chapter IV covers review reporting. Title IV supplies the final legal provisions.
Article 28: Governance, Responsibility, and Audit
The Article 28 objective
Article 28(1) requires "an internal governance and control framework that ensures an effective and prudent management of ICT risk to achieve a high level of digital operational resilience."
What the management body owns
It bears overall responsibility, sets roles, objectives, and ICT requirements, and approves, oversees, and periodically reviews classifications, risks, impact analysis, policies, continuity plans, and response and recovery measures.
Budget, skills, and reporting
It "allocates and reviews at least once a year the budget necessary to fulfil the financial entity’s digital operational resilience needs" and establishes reporting arrangements for information security and resilience.
Outsourcing does not transfer responsibility
Verification tasks may be outsourced where Union and national sectoral law allow it. Nevertheless, "financial entities shall remain fully responsible for the verification of compliance with the ICT risk management requirements."
Independent assurance
Control and internal-audit functions must be appropriately segregated and independent. Audits must fit the audit plan, use independent ICT-risk-competent auditors, and lead to timely remediation of critical findings.
Articles 29-32: Policy, Assets, Risk, and Physical Security
Policy as the starting point
Article 29 requires a developed, documented, and implemented information-security policy. It must state high-level principles and rules protecting confidentiality, integrity, availability, and authenticity.
An inventory of dependencies
Article 30 requires entities to "identify, classify, and document all critical or important functions, the information assets and ICT assets supporting them and their interdependencies."
Risk management is a cycle
Article 31 combines tolerance levels, risk assessment, mitigation, monitoring, reassessment after specified triggers, continuous threat monitoring, and regular scenario review.
Incident triggers must be defined
Entities shall "set out alert thresholds and criteria to trigger and initiate ICT-related incident response processes." The Article requires thresholds and criteria, not simply an informal escalation practice.
Physical security follows risk and classification
Article 32 protects premises and, where applicable, data centres from access, attacks, accidents, and environmental hazards. Protection from environmental hazards must be commensurate with importance and criticality.
Quiz 1: Governance and Risk Foundations
Choose the most accurate answer
A financial entity hires an ICT third-party service provider to verify compliance with ICT-risk-management requirements. Under Article 28(3), which statement is correct?
What is the effect of outsourcing verification tasks under Article 28(3)?
- The financial entity may outsource the task where permitted, but remains fully responsible for verification of compliance.
- The service provider becomes solely responsible for compliance once the verification task is outsourced.
- Outsourcing is prohibited for all verification tasks under the simplified framework.
- The management body no longer needs to receive information-security reporting.
Show Answer
Answer: A) The financial entity may outsource the task where permitted, but remains fully responsible for verification of compliance.
Article 28(3) allows outsourcing in accordance with Union and national sectoral law, but states that "financial entities shall remain fully responsible for the verification of compliance with the ICT risk management requirements."
Article 33: Access Control as a Disciplined Process
Procedures must be active, not merely written
Article 33 requires access-control procedures to be developed, documented, and implemented. They must also be enforced, monitored, and periodically reviewed.
The access principle
"access rights to information assets, ICT assets, and their supported functions, and to critical locations of operation of the financial entity, are managed on a need-to-know, need-to-use and least privileges basis"
Traceable identities and account changes
Users must be identifiable for their actions. Procedures must grant, change, and revoke rights for user and generic accounts, including generic administrator accounts.
Higher-risk access receives stronger treatment
Privileged, emergency, and administrator access is need-to-use or ad-hoc and logged. Strong authentication is required for remote access, privileged access, and specified publicly available critical-function assets.
Articles 34-35: Operating a Secure ICT Environment
All assets are in scope
Article 34 applies to all ICT assets. A practical estate may include cloud services, laptops, network equipment, applications, and public-facing systems, not just the most visible platform.
Vulnerability management is proportionate
Entities shall "perform automated vulnerability scanning and assessments of ICT assets commensurate to their classification" and risk profile, and deploy patches to address identified vulnerabilities.
Logging creates operational evidence
Entities shall "log events related to logical and physical access control, ICT operations, including system and network traffic activities, and ICT change management." Log detail must fit purpose and asset usage.
Data has three protection states
Article 35 requires "the identification and implementation of measures to protect data in use, in transit, and at rest" alongside network, deletion, disposal, teleworking, and private-device safeguards.
Articles 36-38: Testing, Secure Delivery, and Controlled Change
Testing must connect to risk intelligence
The Article 36 testing plan validates specified security measures and must consider threats and vulnerabilities identified through the Article 31 simplified ICT-risk-management framework.
Critical-function systems require prompt adjustment
Entities shall monitor and evaluate results and "update their security measures accordingly without undue delay in the case of ICT systems supporting critical or important functions."
Secure systems begin before first use
Article 37 requires, where appropriate, a risk-based acquisition, development, and maintenance procedure with specified and approved requirements, testing, and approval before first use and production changes.
A controlled change is a chain of actions
Article 38 requires that "all changes to ICT systems are recorded, tested, assessed, approved, implemented, and verified in a controlled manner" with resilience safeguards.
Thought Exercise: Assess a High-Risk Change
Scenario: Moving a critical customer-service application
A financial entity plans to move a customer-service application supporting a critical function to a new hosting environment. The move changes network routes, administrator accounts, backup arrangements, and the external provider supporting the system.
Write a short checklist using only the Articles already studied.
- Under Article 31(1)(e), identify why the entity must assess ICT and information-security risks before and after this major ICT-system or ICT-service change.
- Under Article 33, identify what must happen to privileged and emergency access during the migration.
- Under Article 34, identify the operational controls relevant to vulnerabilities, logging, capacity, anomalous activity, and threat monitoring.
- Under Article 36, explain how the entity should use testing results and when the requirement to update security measures "without undue delay" applies.
- Under Article 37, identify the approvals and testing needed before introducing the change to production.
- Under Article 38, list the exact chain of controls required for the change.
Self-check: Do not write that Article 38 merely requires approval. Its required chain is broader: recorded, tested, assessed, approved, implemented, and verified, in a controlled manner and with adequate safeguards.
Article 39: The ICT Business Continuity Plan
Continuity planning starts with disruption scenarios
Article 39 requires analysis of severe-disruption exposure and impact for ICT assets supporting critical or important functions, expressly "including a cyber-attack scenario."
A usable plan has governance and resources
The plan must be management-body approved, documented, readily accessible in an emergency or crisis, and supported by sufficient execution resources.
Recovery includes dependencies
Plans must "establish planned recovery levels and timeframes for the recovery and resumption of functions and key internal and external dependencies, including ICT third-party service providers."
Backup planning has specified content
Plans must "identify backup procedures and measures that specify the scope of the data that are subject to the backup, and the minimum frequency of the backup" based on function criticality.
Continuity plans evolve
The plan must cover activation, restoration, third-party-provider failure mitigation, alternatives to short-term recovery, communications, escalation, and updates based on lessons, risks, threats, objectives, and major changes.
Articles 40-41: Prove Recovery and Report the Review
The annual testing minimum
Article 40 requires continuity-plan testing "at least once every year for the back-up and restore procedures, or upon every major change of the business continuity plan."
Testing is about business viability
Testing must demonstrate the entity can sustain the viability of its business until critical operations are re-established, and it must identify plan deficiencies.
Deficiencies must reach the management body
Results must be documented. Identified deficiencies shall be analysed, addressed, and reported to the management body.
The report has a required format
Article 41 requires the review report in a searchable electronic format. Its required content includes context, ICT-risk and threat summaries, changes, review reasons, findings, remediation, and conclusions.
Remediation must be forward-looking
The report must include "remedying measures identified to address weaknesses, deficiencies, and gaps in the simplified ICT risk management framework, and the expected date for implementing those measures".
Flashcards: Exact Phrases to Recall
Flip each card and explain the practical consequence in one sentence.
- Article 28 governance objective
- "an internal governance and control framework that ensures an effective and prudent management of ICT risk to achieve a high level of digital operational resilience."
- Annual budget obligation
- "allocates and reviews at least once a year the budget necessary to fulfil the financial entity’s digital operational resilience needs"
- Access-control basis
- "access rights to information assets, ICT assets, and their supported functions, and to critical locations of operation of the financial entity, are managed on a need-to-know, need-to-use and least privileges basis"
- Operational vulnerability control
- "perform automated vulnerability scanning and assessments of ICT assets commensurate to their classification"
- Data-protection states
- "the identification and implementation of measures to protect data in use, in transit, and at rest"
- Controlled change requirement
- "all changes to ICT systems are recorded, tested, assessed, approved, implemented, and verified in a controlled manner"
- Continuity scenario expressly named
- "including a cyber-attack scenario."
- Report remediation content
- "remedying measures identified to address weaknesses, deficiencies, and gaps in the simplified ICT risk management framework, and the expected date for implementing those measures"
Quiz 2: Continuity and Review Reporting
Choose the answer that preserves Article 40 and Article 41 exactly.
A firm changed its business continuity plan substantially six months after its last backup-and-restore test. It is preparing its simplified-framework review report.
Which action best matches the Regulation?
- It must test only when the next annual date arrives, and may submit a scanned image report.
- It shall test upon every major change of the business continuity plan, and the report shall be submitted in a searchable electronic format.
- It may skip testing if it has cloud backups, provided the management body approves the report.
- It needs only to list current ICT risks; remedial measures and expected implementation dates are optional.
Show Answer
Answer: B) It shall test upon every major change of the business continuity plan, and the report shall be submitted in a searchable electronic format.
Article 40(1) requires testing at least annually for backup and restore procedures, or upon every major change of the business continuity plan. Article 41(1) requires the report in a searchable electronic format. Article 41(2)(g) also requires remedial measures and expected implementation dates.
Article 42: Final Provisions and Legal Effect
The operative entry-into-force wording
"This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union." Published June 25, 2024, it entered into force July 15, 2024.
Its legal effect
"This Regulation shall be binding in its entirety and directly applicable in all Member States." Article 42 states a binding Regulation, not a non-binding recommendation.
Execution and identifiers
"Done at Brussels, 13 March 2024." The signature is "Ursula VON DER LEYEN". ELI: http://data.europa.eu/eli/reg_del/2024/1774/oj. ISSN 1977-0677 (electronic edition).
Key Terms
- ICT risk
- Risk associated with the use of ICT systems, services, assets, processes, and related security conditions, as addressed through the simplified framework in Title III.
- ICT asset
- An ICT-related asset subject to classification, risk management, operational security, testing, and other controls under Title III.
- risk appetite
- The financial entity's risk orientation, used in Article 28 when aligning the framework with business strategy and in Article 31 when determining ICT-risk tolerance levels.
- management body
- The body that Article 28 assigns overall responsibility for the simplified ICT risk management framework and its alignment with business strategy and risk appetite.
- least privileges
- The Article 33 access principle under which access is restricted to no more privilege than is necessary.
- information asset
- An information-related asset that must be identified, classified, and documented where it supports critical or important functions.
- privileged access
- Elevated access that Article 33 requires to be assigned on a need-to-use or ad-hoc basis and logged.
- remedying measures
- Measures identified in the Article 41 report to address weaknesses, deficiencies, and gaps, together with expected implementation dates.
- risk tolerance level
- The level of ICT risk determined under Article 31 in accordance with the financial entity's risk appetite.
- business continuity plan
- The Article 39 plan addressing severe disruptions, recovery, dependencies, backups, communications, alternatives, and updates.
- searchable electronic format
- The mandatory format in which Article 41(1) requires submission of the review report.
- critical or important functions
- Functions that Article 30 requires entities to identify, classify, and document together with supporting information assets, ICT assets, and interdependencies.