SkarpChapter 2 of 11
Regulation 2024/1774: ICT Risk Governance, Assets, Cryptography, and Operations Security
The Regulation now moves from regulatory rationale to the machinery of day-to-day ICT control. This chapter examines how governance, risk treatment, asset records, cryptographic safeguards, vulnerability management, secure operations, and logging fit into a reviewable control system.
Article 1: A Risk-Based Starting Point
The governing principle
Article 1 requires proportional design. The financial entity must take account of its size, overall ICT risk profile, and the nature, scale, and complexity of its services, activities, and operations.
Exact mandatory wording
"the size and the overall risk profile of the financial entity, and the nature, scale and elements of increased or reduced complexity of its services, activities and operations shall be taken into account"
What Article 1 expressly includes
The analysis includes encryption and cryptography, ICT operations security, network security, ICT project and change management, and impacts on data and business continuity.
Article 2: Making Security Policies Governable
Embedded, not isolated
Article 2(1) requires ICT security policies, information security, and related procedures, protocols, and tools to be embedded in the ICT risk management framework.
Four required security outcomes
The Chapter I controls shall secure networks, safeguard against intrusion and misuse, preserve availability, authenticity, integrity, and confidentiality, and support accurate, prompt transmission.
Evidence of governance
Policies shall show management-body approval, monitoring indicators, recorded exceptions, staff responsibilities, documentation, segregation of duties, assigned roles, review, and consideration of material change.
Knowledge Check: Article 2 Governance
Choose the statement that most accurately reflects Article 2(2).
Which item does Article 2(2) expressly require an ICT security policy to indicate?
- The date of the formal approval of the ICT security policies by the management body
- The name of every employee who may access production systems
- A fixed annual budget for all security controls
- The identity of every ICT third-party service provider
Show Answer
Answer: A) The date of the formal approval of the ICT security policies by the management body
Article 2(2)(b) requires policies to "indicate the date of the formal approval of the ICT security policies by the management body." The other items are not stated as this Article 2(2) requirement.
Article 3: From Risk Assessment to Residual-Risk Accountability
Risk tolerance and assessment
Article 3 requires policies and procedures to show approval of ICT risk tolerance and to assess vulnerabilities, threats, their effects on supported functions, and impact and likelihood indicators.
Treat, then account for what remains
Risk treatment measures shall be identified, implemented, and documented. Residual risks still present afterward must be identified, assigned to responsible roles, and handled through an acceptance process.
Annual residual-risk review
Accepted residual ICT risks require an inventory with justification and review at least once a year, including changed risk, available mitigations, and whether acceptance reasons remain valid.
Articles 4 and 5: Know the Assets You Depend On
Asset lifecycle policy
Article 4 requires an ICT asset-management policy. It shall prescribe monitoring and management of the lifecycle of ICT assets identified and classified under Article 8(1) of Regulation (EU) 2022/2554.
What the records shall contain
Records shall include identifiers, location, classification, owner, supported functions, continuity requirements, network exposure, dependencies, and, where applicable, provider-support end dates.
Criticality is impact-based
Article 5 requires criteria for criticality assessment. The assessment considers ICT risk, dependencies, and the consequences of losing confidentiality, integrity, or availability.
Worked Example: An Asset Record and Criticality Assessment
Build a usable asset record
For a payment database, record the identifier, logical location, classification, owner, supported service, continuity objectives, exposure, dependencies, and applicable supplier-support end dates.
Map dependencies
The database may depend on identity services, application servers, network gateways, backups, and an ICT third-party service provider. Article 4 requires records of these links and interdependencies.
Assess three kinds of loss
Article 5 asks how loss of confidentiality, integrity, and availability would affect the entity's processes and activities. A criticality assessment must connect technical failure to business impact.
Articles 6 and 7: Encryption and the Key Lifecycle
Classification and assessment drive the policy
Article 6 requires an encryption and cryptographic-controls policy designed from approved data classification and ICT risk assessment results. The policy covers data, connections, traffic, and key management.
Data in use has a conditional rule
Encryption of data in use applies where necessary. Where it is not possible, the entity shall use a separated and protected environment or equivalent measures ensuring the stated security outcomes.
Keys and certificates
Article 7 requires lifecycle key management, lifecycle protection controls, replacement methods, an up-to-date certificate register for at least critical or important assets, and renewal before expiration.
Flashcards: Governance, Assets, and Cryptography
Flip each card and explain the requirement in your own words. Focus on the conditions and qualifiers, not only the headline term.
- Article 1 proportionality principle
- When developing and implementing the stated controls, the entity's size, overall risk profile, and the nature, scale, and increased or reduced complexity of its services, activities, and operations shall be taken into account.
- Accepted residual-risk inventory
- Article 3 requires the development of an inventory of accepted residual ICT risks, including a justification for their acceptance.
- Residual-risk review frequency
- Accepted residual ICT risks shall be reviewed at least once a year, including changed risks, available mitigations, and whether acceptance reasons remain valid and applicable.
- Asset lifecycle
- The asset-management policy shall prescribe monitoring and management of the lifecycle of ICT assets identified and classified in accordance with Article 8(1) of Regulation (EU) 2022/2554.
- Encryption fallback for data in use
- Where encryption of data in use is not possible, data shall be processed in a separated and protected environment, or equivalent measures shall be taken.
- Cryptographic key lifecycle
- It includes generating, renewing, storing, backing up, archiving, retrieving, transmitting, retiring, revoking, and destroying cryptographic keys.
Article 8: Secure ICT Operations and Production Discipline
Operations are a control system
Article 8 requires documented ICT-operations policies and procedures. They shall specify how assets are operated, monitored, controlled, and restored, including documentation of ICT operations.
Production separation
Policies shall require separation between production and development, testing, and other non-production environments. The separation considers all components, including accounts, data, and connections.
A narrow production-testing exception
Production testing is permitted only where instances are clearly identified, reasoned, limited in time, and approved by the relevant function. Production systems and data must retain the stated security properties.
Articles 9 and 10: Capacity, Vulnerabilities, and Patches
Capacity is a resilience issue
Article 9 requires procedures for capacity requirements, resource optimisation, and monitoring availability and efficiency. They must include the prevention of ICT capacity shortages.
Weekly is the minimum for specified assets
Automated vulnerability scanning and assessments for ICT assets supporting critical or important functions shall occur on at least a weekly basis.
Patches need deadlines and escalation
Patch procedures shall, to the extent possible, evaluate updates with automated tools, define emergency procedures, test and deploy updates, and set installation deadlines plus escalation if deadlines cannot be met.
Articles 11 and 12: Data, Systems, and Logging Evidence
Article 11: Secure configurations and endpoints
The data and system-security procedure shall include classification-based access restrictions, secure configuration baselines, authorised software controls, anti-malware measures, and endpoint and storage safeguards.
Article 12: What must be logged
Logging covers access and identity management, capacity management, change management, ICT operations and system activities, plus network traffic activities and network performance.
Logs must remain trustworthy
Logging systems and log information require protection against tampering, deletion, and unauthorised access at rest, in transit, and, where relevant, in use. Failures must also be detectable.
Final Knowledge Check: Operations and Vulnerabilities
Test whether you can distinguish an unconditional obligation from a qualified or conditional one.
Which statement is correct under Articles 8 to 10?
- Testing in production is prohibited in every circumstance.
- All ICT assets must undergo automated vulnerability scanning exactly once every week.
- Testing in production may occur only under stated conditions, while assets supporting critical or important functions must be scanned and assessed at least weekly.
- Patch-management procedures need deadlines only for emergency patches.
Show Answer
Answer: C) Testing in production may occur only under stated conditions, while assets supporting critical or important functions must be scanned and assessed at least weekly.
Article 8 permits production testing where instances are clearly identified, reasoned, limited in time, and approved by the relevant function. Article 10 sets an at-least-weekly minimum for assets supporting critical or important functions. It does not say all assets must be scanned exactly once weekly. Article 10 also requires patch deadlines and escalation procedures generally.
Key Terms
- logging
- The Article 12 safeguards involving recorded events, retention, security, failure detection, and reliable time synchronisation.
- ICT asset
- An ICT asset identified and classified for the purposes referred to in Articles 4 and 5.
- data in use
- Data being processed; Article 6 requires encryption where necessary and specifies an alternative where encryption is not possible.
- data at rest
- Data in stored form, addressed by the encryption rule in Article 6(2)(a).
- data in transit
- Data being transmitted, addressed by the encryption rule in Article 6(2)(a).
- legacy ICT system
- A legacy system for which, for financial entities other than microenterprises, Article 4 requires records necessary to perform a specific ICT risk assessment.
- residual ICT risk
- ICT risk that remains after implementation of ICT risk treatment measures.
- criticality assessment
- The Article 5 assessment of information assets and ICT assets supporting business functions, considering ICT risk, dependencies, and loss of confidentiality, integrity, and availability.
- production environment
- The live ICT environment separated from development, testing, and other non-production environments under Article 8.
- ICT risk tolerance level
- The level of ICT risk whose approval must be indicated in the ICT risk management policies and procedures under Article 3.
- vulnerability management
- The Article 10 process for awareness, scanning, provider oversight, dependency tracking, disclosure, prioritisation, remediation monitoring, and recording.
- accepted residual ICT risk
- A residual ICT risk that has been accepted under the roles, responsibilities, inventory, justification, and review provisions required by Article 3.
- cryptographic key lifecycle
- The full sequence of generating, renewing, storing, backing up, archiving, retrieving, transmitting, retiring, revoking, and destroying cryptographic keys.
- secure configuration baseline
- A configuration baseline identified under Article 11 that minimises ICT-asset exposure to cyber threats and is regularly verified as effectively deployed.