Recitals - Commission Delegated Regulation (EU) 2024/1774
The Commission Delegated Regulation (EU) 2024/1774 is not the main DORA (Digital Operational Resilience Act) document. Rather, it’s a supplementary regulatory text developed and adopted by the European Commission. Its primary purpose is to provide more detailed rules and guidelines on how to implement DORA effectively, particularly in the area of Information and Communication Technology (ICT) risk management. You can think of it as a blueprint for bringing DORA to life in the real world, specifying the technical standards and details needed for implementation.
The first part of the document are the Recitals. Recitals are not in themselves binding. They are, however, important in interpreting and understanding intentions of the act and give a good overview of what needs to be implemented. See below for a summary of each recital; this will give you a good start to understanding the standard. Each recital has a "more about" section if you would like to learn more.
Here is a very quick overview of each recital. It is recommended to not only skim through these, but also go through the recital summaries below.
TL;DR
Use a risk-based approach
If applicable, reuse existing policies and procedures
Implement clear roles and responsibilities to manage security
Use role segmentation
Basically same as 2.
When possible, use compliance standards (like ISO 27001) and industry best practices
Make sure to have asset management and capacity policies and procedures in place
Manage risks with legacy systems
Implement risk-based cryptographic policies and procedures
Separate test and production environments
Use a proactive approach to manage ICT vulnerabilities
Implement effective patch management
Secure procedures to timely communicate potential security threats
Only strong identification measures to manage user access rights should be used
Use robust ICT project management policies and procedures
Always evaluate and test ICT systems before putting into production
Put in place change management processes and procedures
Establish comprehensive ICT-related incident management policy and procedures
Adopt a broad approach for anomalous activities detection by collecting and analyzing information from various internal and external sources
Retain incident data and evidence for an appropriate period of time that is harmonized with relevant EU laws
Detection of incidents is hard and complex, therefore, keep an open mind regarding how incidents are classified and detected
ICT business continuity policy should at minimum include incident and change management, communication strategies and third-party provider risk
Develop and test scenarios for ICT disruptions
If applicable, establish processes and procedures for managing ICT projects operational risks, change management, and business continuity in relation to regulations (EU) No 648/2012, (EU) No 600/2014 and (EU) No 909/2014
Regularly review your ICT risk management framework and report findings
Companies that fall under the simplified ICT risk management framework should focus on essential security areas and are only obligated to develop an appropriate information security policy
The rationale behind consolidating both the standard and simplified ICT risk management frameworks into a single legislative act under Regulation (EU) 2022/2554. Not relevant for implementation purposes.
The origins and collaborative development of DORA. Not relevant for implementation purposes.
The process followed by the Joint Committee of the European Supervisory Authorities (ESAs) to develop the regulatory technical standards of DORA. Not relevant for implementation purposes.
Any processing of data as part of DORA compliance must fully comply with GDPR
DORA promotes a risk-based approach to ICT security. Basically, you should begin with identifying present and future risks for your company and ensure that they are effectively managed. This is very similar to how ISO 27001 is designed and meant to be implemented. If you have ISO 27001 implemented you already have a risk based approach and if not, DORA will give you a head start.
-
TL;DR
DORA promotes a risk-based approach to ICT security, ensuring that financial entities implement appropriate measures based on their specific risk profile and operational characteristics. Company/organizational factors that are relevant to take into account:
Size: Larger entities may require more robust and complex ICT security measures.
Structure and Internal Organization: More complex orgs may need more sophisticated ICT frameworks to manage risk effectively.
Nature and Complexity of Activities: Companies involved in high-risk activities may need stronger ICT protections than those with simpler operations.
Corresponding Risks: The regulation ensures that the ICT risk management framework reflects the actual risks the entity faces.
FULL VERSION
DORA aims to strengthen the digital resilience of financial entities within the European Union. The regulation acknowledges that financial entities vary greatly in terms of size, structure, internal organization, and the nature and complexity of their operations. These differences lead to varying levels of risk and complexity regarding their information and communication technology (ICT) environments.
To address these variations, the regulation mandates that ICT security requirements should be proportionate to the specific characteristics of each financial entity. This means that the rules around ICT security policies, procedures, protocols, and tools should be tailored to the entity's:
Size: Larger entities may require more robust and complex ICT security measures, while smaller entities may not need such extensive systems.
Structure and Internal Organization: Entities with more complex structures or internal arrangements may need more sophisticated ICT frameworks to manage their risks effectively.
Nature and Complexity of Activities: The type of services or operations a financial entity engages in can affect its risk profile. For example, entities involved in high-risk activities may need stronger ICT protections than those with simpler operations.
Corresponding Risks: The regulation ensures that the ICT risk management framework reflects the actual risks the entity faces. This allows for flexibility and avoids a one-size-fits-all approach, ensuring that smaller or less complex entities are not overburdened with unnecessary requirements.
In essence, the regulation promotes a risk-based approach to ICT security, ensuring that financial entities implement appropriate measures based on their specific risk profile and operational characteristics. This proportionality ensures that the regulation is both effective and practical across the diverse landscape of financial entities in the EU.
While DORA recognizes the need for making implementation as simple as possible by, for instance, reusing already existing documents and procedures, it does also mandate some specific policies and procedures. Furthermore, DORA encourages the use of leading industry practices, standards, and recognized best practices.
-
TL;DR
DORA promotes flexibility in adapting ICT security requirements to make implementation as simple as possible. This means that companies can choose to implement the necessary policies, procedures, protocols, and tools in a way that best suits their specific circumstances.
If applicable, existing documentation and procedures may be used to reduce administrative burden.
The regulation requires the development, documentation, and implementation of ICT security policies only for certain essential elements by following leading industry practices and standards, encouraging financial entities to align with recognized best practices.
The regulation does require that specific ICT security procedures are developed, documented, and implemented to address particular technical areas. These areas include:
Capacity and Performance Management: Ensuring that ICT systems can handle the required workloads and perform efficiently.
Vulnerability and Patch Management: Regularly identifying and addressing security vulnerabilities in software and systems.
Data and System Security: Protecting sensitive data and securing ICT systems against unauthorized access or breaches.
Logging: Keeping detailed records of ICT system activities to monitor and analyze security-related events.
FULL VERSION
This section of DORA emphasizes the importance of providing financial entities with flexibility in how they comply with ICT security requirements. Here are the key points:
Flexibility in Compliance: Recognizing the diversity among financial entities in terms of size, structure, and operations, the regulation allows them to have some flexibility in how they meet ICT security requirements. This means that entities can choose how to implement the necessary policies, procedures, protocols, and tools in a way that best suits their specific circumstances.
Use of Existing Documentation: To avoid redundancy and unnecessary burden, financial entities are permitted to use any existing documentation they already have to fulfill the documentation requirements imposed by the regulation. This provision acknowledges that many entities may already have relevant documents in place and should not be forced to create new ones if their existing materials are sufficient.
Essential Elements: The regulation requires the development, documentation, and implementation of ICT security policies only for certain essential elements. This approach focuses on critical areas of security, ensuring that entities prioritize key aspects of their ICT systems without being overwhelmed by extensive documentation requirements. In doing so, the regulation considers leading industry practices and standards, encouraging financial entities to align with recognized best practices.
Specific Technical Implementation Aspects: The regulation also requires that specific ICT security procedures be developed, documented, and implemented to address particular technical areas. These areas include:
Capacity and Performance Management: Ensuring that ICT systems can handle the required workloads and perform efficiently.
Vulnerability and Patch Management: Regularly identifying and addressing security vulnerabilities in software and systems.
Data and System Security: Protecting sensitive data and securing ICT systems against unauthorized access or breaches.
Logging: Keeping detailed records of ICT system activities to monitor and analyze security-related events.
In summary, the regulation provides financial entities with the flexibility to adapt ICT security requirements to their specific needs, allows for the use of existing documentation to reduce administrative burden, and focuses on essential and specific technical aspects of ICT security. This approach helps ensure that entities can effectively manage their ICT risks while being efficient and practical in their compliance efforts.
DORA stresses that financial entities must clearly define and assign roles and responsibilities for ICT security within the organization. This includes:
Clear assignment of key roles and responsibilities related to ICT security and for roles and responsibilities to be maintained over time.
Clear consequences for non-compliance must be outlined which could include disciplinary measures for employees.
-
TL;DR
DORA stresses that financial entities must clearly define and assign roles and responsibilities for ICT security within the organization. This includes:
Clear assignment of key roles and responsibilities related to ICT security and for roles and responsibilities to be maintained over time.
Clear consequences for non-compliance must be outlined which could include disciplinary measures for employees.
FULL VERSION
This section emphasizes the need for financial entities to establish clear roles, responsibilities, and accountability when it comes to ICT security. Here's a detailed explanation:
1. Correct Assignment of Roles and Responsibilities:
Importance of Clear Assignment: To ensure the effective and ongoing implementation of ICT security measures, financial entities must properly designate specific roles and responsibilities related to ICT security within their organization. This means identifying who is responsible for various aspects of ICT security, such as policy creation, implementation, monitoring, and response to incidents.
Ongoing Maintenance: These roles and responsibilities should not only be correctly assigned initially but also maintained over time. This includes updating roles as needed, particularly when there are changes in the organization, such as restructuring, personnel changes, or updates to ICT systems and security practices.
2. Laying Down Consequences for Non-Compliance:
Importance of Accountability: Financial entities must establish clear consequences for non-compliance with ICT security policies and procedures. This ensures that everyone within the organization understands the importance of adhering to these security measures and the potential repercussions of failing to do so.
Disciplinary Measures: Consequences could include disciplinary actions for employees or teams that fail to comply with ICT security requirements. This could range from warnings to more severe actions, depending on the severity of the non-compliance and its potential impact on the entity's operations and security.
3. Ensuring Correct Implementation Over Time:
Sustained Compliance: The goal is to ensure that ICT security measures are not just implemented correctly at one point in time but are consistently followed and updated as needed over the long term. This sustained compliance helps protect the financial entity from evolving cyber threats and ensures that the organization remains resilient in the face of ICT-related risks.
Continuous Improvement: By assigning clear responsibilities and enforcing accountability, financial entities can ensure that their ICT security practices evolve and improve over time, adapting to new challenges and maintaining high standards of protection.
Summary:
In summary, the regulation stresses that financial entities must clearly define and assign roles and responsibilities for ICT security. This ensures that the right people are accountable for implementing and maintaining security measures. Additionally, by establishing consequences for non-compliance, the regulation reinforces the importance of adhering to ICT security policies and procedures. These measures help ensure that ICT security is effectively managed and continuously upheld over time.
DORA requires companies to segregate ICT roles and responsibilities to prevent conflicts of interest, reduce risk, improve oversight, and enhance the overall effectiveness for security.
Key ICT roles and responsibilities should be divided among different people or departments. For example, the person who designs and implements security protocols should not be the same person who monitors or audits those protocols.
-
TL;DR
DORA requires companies to segregate ICT roles and responsibilities to prevent conflicts of interest, reduce risk, improve oversight, and enhance the overall effectiveness for security.
Key ICT roles and responsibilities should be divided among different people or departments. For example, the person who designs and implements security protocols should not be the same person who monitors or audits those protocols.
Example of Segregation:
ICT Security Implementation: One team/group/individual may be responsible for setting up and maintaining the organization's security systems, such as firewalls, encryption, and access controls.
ICT Security Monitoring and Auditing: A different team/group/individual should be responsible for monitoring the security systems to detect breaches or vulnerabilities and auditing the security processes to ensure compliance with policies and regulations.
Practical Implementation:
Organizational Structure: Financial entities should structure their ICT departments in a way that ensures clear separation of duties. This may involve creating independent teams for different aspects of ICT security, such as implementation, monitoring, and auditing or different individuals reporting to different managers.
Documentation: Roles and responsibilities should be documented clearly, ensuring that everyone in the organization understands their specific duties and the limits of their authority.
FULL VERSION
DORA emphasizes the importance of segregation of duties in managing ICT roles and responsibilities within financial entities. Here's a detailed explanation:
1. Purpose of Segregation of Duties:
Limiting Conflicts of Interest: The primary goal of segregating duties is to prevent conflicts of interest within an organization. A conflict of interest can arise when a single individual has multiple responsibilities that could compromise the integrity or security of ICT systems. For example, if someone is responsible for both implementing security controls and auditing those controls, there is a risk that they could overlook or cover up potential issues.
Enhancing Objectivity: By separating responsibilities, financial entities can ensure that different individuals or teams handle different aspects of ICT security. This promotes objectivity and reduces the likelihood of errors, fraud, or intentional misconduct.
2. How Segregation of Duties Works:
Division of Responsibilities: Key ICT roles and responsibilities should be divided among different people or departments. For example, the person who designs and implements security protocols should not be the same person who monitors or audits those protocols. This creates a system of checks and balances, where one person’s work is independently verified by another.
Example of Segregation:
ICT Security Implementation: One team or individual may be responsible for setting up and maintaining the organization's security systems, such as firewalls, encryption, and access controls.
ICT Security Monitoring and Auditing: A different team or individual should be responsible for monitoring the security systems to detect breaches or vulnerabilities and auditing the security processes to ensure compliance with policies and regulations.
3. Benefits of Segregation of Duties:
Risk Reduction: Segregation of duties reduces the risk of security breaches caused by internal threats, whether intentional (e.g., fraud or sabotage) or unintentional (e.g., errors or oversights).
Enhanced Governance: By clearly defining and separating roles, financial entities can improve governance over ICT security, ensuring that responsibilities are properly managed and no single individual has too much control over critical systems.
Compliance: Segregation of duties also helps financial entities comply with regulatory requirements, as many regulations, including DORA, mandate this practice to ensure a robust security framework.
4. Practical Implementation:
Organizational Structure: Financial entities should structure their ICT departments in a way that ensures clear separation of duties. This may involve creating independent teams for different aspects of ICT security, such as implementation, monitoring, and auditing.
Documentation: Roles and responsibilities should be documented clearly, ensuring that everyone in the organization understands their specific duties and the limits of their authority.
Summary:
In summary, the regulation requires financial entities to segregate ICT roles and responsibilities to prevent conflicts of interest. By ensuring that different individuals or teams handle different aspects of ICT security, financial entities can reduce risks, improve oversight, and enhance the overall effectiveness of their security measures. This approach helps safeguard the integrity of ICT systems and ensures compliance with regulatory standards.
Financial entities should not be required to develop specific documentation or remedies as specified by Title II, Chapter I of DORA, if already existing policies or procedures provide sufficient compliance.
-
The statement focuses on simplifying compliance by allowing flexibility in implementation of ICT security. Existing policies and procedures should be reviewed and evaluated whether they provide sufficient security and compliance as specified in DORA (specifically, in Title II, Chapter I).
Companies should develop their set of ICT security policies to as high a degree as possible based on industry best practices and existing standards.
-
TL;DR
Companies should develop their set of ICT security policies to as high a degree as possible based on industry best practices and existing standards. Best practices and standards could mean a wide range of standards including ISO 27001, GDPR, ISO 31000, etc.
Please remember recitals 1 & 2. Applicable best practices and standards can vary widely depending on the service, the nature/importance of the service and the complexity of the organization.
FULL VERSION
The statement emphasizes the importance of financial entities developing their ICT (Information and Communication Technology) security policies in a way that keeps pace with the evolving risks in a dynamic environment. Breakdown of the key points:
Dynamic Environment: ICT risks are constantly changing due to the rapid evolution of technology, cyber threats, and the overall digital landscape. Financial entities need to be proactive in addressing these changes to ensure their systems and data remain secure.
Leading Practices: Financial entities should base their ICT security policies on leading practices. These are the best and most effective methods that have been identified and recognized within the industry. By doing so, entities can adopt the most current and effective strategies for mitigating ICT risks.
Standards Reference (Article 2, Point (1), Regulation (EU) No 1025/2012): This regulation refers to the development and use of European standards. Standards are formalized guidelines and specifications that ensure quality, safety, and efficiency. In this context, financial entities are encouraged to incorporate relevant standards into their ICT security policies. Doing so provides a structured and recognized framework that can help ensure that their security measures are robust and effective.
Preparation and Awareness: By developing ICT security policies based on leading practices and applicable standards, financial entities can remain informed about the latest developments in ICT risk management. This prepares them to effectively handle new and emerging threats, ensuring their resilience in a changing environment.
Possible best practices and standards
Possible practices and standards that this article could be referring to include a wide range of guidelines, best practices, and technical specifications developed by recognized European or international standardization bodies. Below are some examples of possible standards and practices:
1. Information Security Management Standards (e.g., ISO/IEC 27001)
ISO/IEC 27001: An internationally recognized standard for information security management systems (ISMS). It provides a framework for establishing, implementing, maintaining, and continually improving information security within an organization.
ISO/IEC 27002: Provides best-practice recommendations on information security controls for use by those responsible for initiating, implementing, or maintaining ISMS.
2. Cybersecurity Standards
ISO/IEC 27032: Focuses on cybersecurity, offering guidelines for improving the state of cybersecurity and developing confidence in cyberspace.
NIST Cybersecurity Framework: Although developed by the U.S. National Institute of Standards and Technology, this framework is often used globally and provides a policy framework of computer security guidance for how private sector organizations can assess and improve their ability to prevent, detect, and respond to cyber attacks.
3. ICT Risk Management Standards
ISO 31000: Provides guidelines on risk management that can be applied to any organization regardless of its size, activity, or sector. It helps in managing risks associated with ICT.
ENISA Guidelines: The European Union Agency for Cybersecurity (ENISA) provides various guidelines and best practices related to ICT risk management, incident reporting, and resilience.
4. Data Protection and Privacy Standards
ISO/IEC 27701: A privacy extension to ISO/IEC 27001 that provides guidance for establishing, implementing, maintaining, and continually improving a privacy information management system (PIMS).
General Data Protection Regulation (GDPR): While not a standard, GDPR requires organizations to implement measures that align with best practices for data protection, which could involve the adoption of relevant standards like ISO/IEC 27701.
5. Interoperability Standards
ISO/IEC 20000: Focuses on IT service management and is aligned with ITIL (Information Technology Infrastructure Library). It ensures that IT services are delivered effectively and meet the needs of the business and its customers.
ETSI Standards: Developed by the European Telecommunications Standards Institute, these standards cover various aspects of ICT, including telecommunications, broadcasting, and electronic communications.
6. Cloud Security Standards
ISO/IEC 27017: Provides guidelines for information security controls applicable to the provision and use of cloud services.
ISO/IEC 27018: Focuses on protecting personal data in the cloud.
7. Operational Resilience Standards
ISO 22301: A standard for business continuity management, providing a framework for organizations to plan, establish, implement, operate, monitor, review, maintain, and continually improve a documented management system to protect against disruptive incidents.
Summary:
Financial entities must develop their ICT security policies by incorporating the latest leading practices and relevant standards to stay informed and prepared for evolving ICT risks. This approach ensures that they remain resilient and capable of responding to new challenges in a rapidly changing digital landscape.
Companies should develop and implement:
an ICT asset management policy, as defined in Section 3, Article 4 & 5
capacity and performance management procedures, and
policies and procedures for ICT operations.
-
TL;DR
To ensure their digital operational resilience, companies should, as part of their ICT security policies, procedures, protocols, and tools, develop and implement:
an ICT asset management policy, as defined in Section 3, Article 4 & 5
capacity and performance management procedures, and
policies and procedures for ICT operations.
The policies should ensure:
the monitoring of the status of ICT assets throughout their lifecycles
ensure the optimization of ICT systems operation and that the ICT systems’ and capacity’s performance meets the established business and information security objectives, and
ensure the effective and smooth day-to-day management and operation of ICT systems (ICT operations), thereby minimizing the risk of loss of confidentiality, integrity, and availability of data.
Basically, all ICT assets (hardware and software) should be accounted for and monitored for capacity in a way that is effective in day-to-day operations.
FULL VERSION
This section emphasizes the importance of comprehensive ICT asset management practices to ensure their digital operational resilience. Here's a breakdown of the key points:
1. Scope of ICT Management Requirements:
Financial entities must develop and implement a range of ICT management policies, procedures, and protocols as part of their overall ICT security strategy. These include:
ICT Asset Management Policy: Focuses on tracking and managing ICT assets throughout their lifecycle.
Capacity and Performance Management Procedures: Ensures that ICT systems operate efficiently, have desired capacity and meet business needs.
ICT Operations Policies and Procedures: Addresses the day-to-day management and operation of ICT systems to minimize risks.
2. ICT Asset Management:
Monitoring Throughout Lifecycles: The regulation requires financial entities to monitor ICT assets—such as hardware, software, and data—from acquisition to decommissioning. This ensures that assets are effectively utilized and maintained, reducing the likelihood of system failures, security breaches, or inefficiencies.
Effective Use and Maintenance: Proper asset management ensures that all ICT resources are used optimally and maintained to prevent degradation, vulnerabilities, or other risks that could compromise digital resilience.
3. Capacity and Performance Management:
Optimization of ICT Systems: Entities must ensure that their ICT systems are optimized to handle the necessary workloads and operate efficiently. This involves monitoring system performance and capacity, making adjustments as needed to prevent bottlenecks, slowdowns, or failures.
Meeting Business and Security Objectives: The performance of ICT systems should align with the entity's business goals and information security requirements, ensuring that systems can handle the demands placed on them without compromising security.
4. ICT Operations:
Smooth Day-to-Day Management: The regulation emphasizes the need for effective daily management of ICT systems to minimize operational risks. This includes routine tasks like system maintenance, updates, backups, and incident management.
Minimizing Risks: Proper management reduces the risks associated with the loss of confidentiality, integrity, and availability of data, which are critical for both operational resilience and regulatory compliance.
5. Overall Security Objectives:
Networks and Data Security: The policies and procedures outlined in the regulation are necessary to secure the network and protect against unauthorized access, intrusions, and data misuse.
Safeguarding Data: The ultimate goal of these measures is to preserve the availability, authenticity, integrity, and confidentiality of data. This ensures that data is accessible when needed, accurate and reliable, and protected from unauthorized modifications or breaches.
Summary:
In summary, the regulation mandates that financial entities implement comprehensive ICT management policies and procedures, covering asset management, capacity and performance management, and daily ICT operations. These measures are essential for ensuring the secure and efficient functioning of ICT systems, thereby minimizing risks and maintaining digital operational resilience. By optimizing ICT system performance and safeguarding data, financial entities can meet both business objectives and regulatory requirements, ensuring long-term stability and security.
Assets in ICT Context
Definition: In this context, "assets" refer to all the components and resources related to the ICT environment that are crucial for the functioning, security, and efficiency of the financial entity’s operations. These can include:
Hardware: Physical devices such as servers, computers, network devices, storage systems, and other equipment used in the ICT infrastructure.
Software: Applications, operating systems, databases, and other programs that run on the hardware and perform various functions critical to the entity’s operations.
Data: Information and data repositories that the entity manages, including customer data, financial records, transaction histories, and other sensitive information.
Network Infrastructure: Communication networks and connections, including routers, switches, firewalls, and communication lines that facilitate data transfer and connectivity.
Intellectual Property: Proprietary software, patents, trademarks, and other intellectual property related to the ICT environment.
Cloud Services and Virtual Assets: Cloud-based resources, virtual machines, and other virtualized components that the entity uses.
Asset Management in ICT Context
Definition: "Asset management" refers to the systematic process of managing, monitoring, and maintaining these ICT assets throughout their lifecycle. This involves several key activities:
Identification and Inventory: Keeping an accurate and up-to-date inventory of all ICT assets, including details about their location, configuration, and usage.
Procurement and Deployment: Ensuring that assets are procured and deployed according to the entity’s needs and standards. This includes selecting the right hardware and software, and properly configuring them for use.
Maintenance and Support: Regularly maintaining ICT assets to ensure they remain in good working condition. This could include software updates, hardware repairs, and performance monitoring.
Security and Compliance: Implementing security measures to protect ICT assets from threats, ensuring they comply with regulatory requirements, and monitoring them for vulnerabilities.
Lifecycle Management: Managing the entire lifecycle of ICT assets, from acquisition and deployment to eventual decommissioning and disposal. This ensures that assets are retired when they are no longer effective or secure.
Optimization: Ensuring that assets are used efficiently, avoiding over- or under-utilization, and optimizing their performance to meet business objectives.
Disposal and Decommissioning: Properly retiring and disposing of assets that are no longer needed, ensuring data is securely erased and hardware is recycled or disposed of in compliance with environmental regulations.
Importance in Financial Entities
For financial entities, effective asset management is crucial because these ICT assets are integral to their operations. Managing these assets properly ensures that they can support business activities reliably, securely, and efficiently. Poor asset management can lead to risks such as security vulnerabilities, operational inefficiencies, increased costs, and regulatory non-compliance.
In summary, assets in this context refer to the various components that make up the ICT infrastructure of a financial entity, while asset management is the process of overseeing these components throughout their lifecycle to ensure they are effectively used, maintained, and secured.
Risks associated with legacy ICT systems must be carefully monitored and managed. Any older technology, and especially if it’s not longer maintained by its vendor, should be carefully managed from a risk perspective and if possible, replaced.
-
TL;DR
Financial entities need to carefully manage the risks associated with legacy ICT systems by, for instance, record and monitor the end-dates of third-party support services. This practice is particularly important for critical systems that are essential to business operations. By focusing on these key assets, financial entities can prevent disruptions, security breaches, and data loss that may arise from using unsupported technology. Proper management of these risks ensures that legacy systems do not become a liability to the organization's overall digital resilience.
Basically, any technology that is old(er) and especially if it’s not longer maintained by its vendor, should be carefully managed from a risk perspective and if possible, replaced.
FULL VERSION
Legacy systems are older technology platforms that may still be in use but can pose security and operational risks. The regulation outlines specific measures to mitigate these risks. Here's a detailed explanation:
1. Legacy ICT Systems Risk:
Definition: Legacy ICT systems are outdated or older technology systems that continue to be used in an organization. These systems may no longer receive updates or support from vendors, making them vulnerable to security risks and operational failures.
Risk Management: Properly managing these systems is crucial because they can become weak points in the entity's overall ICT infrastructure, particularly if they are no longer supported by third-party vendors.
2. Recording and Monitoring End-Dates of Third-Party Support Services:
End-Dates of Support: Financial entities are required to keep track of the end-dates for third-party support services associated with their ICT systems. This means knowing when a vendor will stop providing updates, patches, and technical support for a system.
Monitoring: Regularly monitoring these end-dates ensures that financial entities are aware of when a system will become unsupported. This allows them to plan for necessary upgrades, replacements, or additional security measures before the support ends.
Importance of Timely Action: If an ICT system is no longer supported, it may become more vulnerable to security threats, such as cyberattacks, because it will no longer receive updates or patches. Monitoring end-dates allows financial entities to mitigate these risks by transitioning to newer systems or implementing compensatory controls.
3. Focus on Critical ICT Assets and Systems:
Critical Systems: The regulation emphasizes that financial entities should prioritize recording and monitoring end-dates for ICT assets or systems that are critical for business operations. These are systems that, if compromised, could severely impact the entity's ability to function, such as core banking systems, payment processing platforms, or data storage systems.
Potential Impact of Data Loss: Given the significant consequences of losing confidentiality, integrity, or availability of data, especially in critical systems, financial entities must focus their risk management efforts on ensuring these systems remain secure and operational.
Prioritization: By focusing on critical systems, financial entities can allocate their resources effectively to manage the most significant risks. This approach ensures that the systems most vital to business continuity are protected from the vulnerabilities that arise when support ends.
4. Mitigating Legacy System Risks:
Planning for Transition: Financial entities should plan for the transition away from legacy systems before the end of their support. This could involve upgrading to newer technologies, migrating to alternative systems, or implementing additional security measures.
Security Measures: Even while a legacy system is still in use, entities should ensure that appropriate security measures are in place, such as additional monitoring, access controls, and regular assessments, to mitigate the risks associated with outdated technology.
Summary:
In summary, the regulation requires financial entities to carefully manage the risks associated with legacy ICT systems by recording and monitoring the end-dates of third-party support services. This practice is particularly important for critical systems that are essential to business operations. By focusing on these key assets, financial entities can prevent disruptions, security breaches, and data loss that may arise from using unsupported technology. Proper management of these risks ensures that legacy systems do not become a liability to the organization's overall digital resilience.
Companies should follow a risk-based cryptographic approach that should closely monitor and follow industry advancement to deal with the dynamic landscape of cryptographic threats, including threats from quantum advancements.
-
TL;DR
Companies should follow a risk-based cryptographic approach that should closely monitor and follow industry advancement to deal with the dynamic landscape of cryptographic threats, including threats from quantum advancements.
More specifically, financial entities should encrypt the data concerned at rest, in transit or, where necessary, in use, on the basis of the results of a two-pronged process, namely data classification and a comprehensive ICT risk assessment. In use encryption is often not appropriate due to complexity and practical limitations, in that case data should be secured and protected through other ICT security measures.
In the vast majority of cases, cryptographic policies and procedures will already be covered by existing policies and procedures but you need to make sure that your policies, procedures, implementation and practices meet the necessary requirements.
FULL VERSION
This section of DORA emphasizes the importance of cryptographic controls for protecting data in financial entities. It provides guidance on how these entities should implement encryption and other cryptographic measures to ensure data security. Here's a detailed breakdown:
1. Purpose of Cryptographic Controls:
Protection of Data: Cryptographic controls are essential for ensuring the availability, authenticity, integrity, and confidentiality of data. These controls help protect sensitive information from unauthorized access, tampering, or loss, which is critical for financial entities handling large amounts of valuable data.
Types of Encryption:
Data at Rest: Encrypting data stored on devices or in databases.
Data in Transit: Encrypting data as it is transmitted across networks.
Data in Use: Encrypting data that is being actively processed or used by applications.
2. Risk-Based Approach:
Risk Assessment: Financial entities should implement cryptographic controls based on a thorough assessment of the risks associated with their data and ICT systems. This means identifying where encryption is most needed and which types of encryption should be used.
Data Classification: The first step in this process is data classification, which involves categorizing data based on its sensitivity and importance. This helps determine which data requires stronger cryptographic protection.
ICT Risk Assessment: The second step is a comprehensive ICT risk assessment. This involves evaluating potential threats and vulnerabilities in the entity's ICT environment to decide how and where encryption should be applied.
3. Encrypting Data in Use:
Complexity of Encryption: Encrypting data while it is in use (actively being processed) is more complex than encrypting data at rest or in transit. Because of this complexity, financial entities are advised to do so only when it is necessary and appropriate based on the results of their risk assessment.
Alternative Security Measures: If encrypting data in use is too difficult or impractical, financial entities should implement other ICT security measures to protect the data. These could include access controls, monitoring, or other security protocols that ensure the data remains secure during use.
4. Staying Abreast of Technological Developments:
Rapid Advancements in Cryptography: The field of cryptography is constantly evolving, with new techniques and potential vulnerabilities (e.g., quantum computing) emerging. Financial entities must stay informed about these developments to ensure their cryptographic controls remain effective.
Leading Practices and Standards: Entities should follow leading industry practices and standards to guide their use of cryptographic techniques. This ensures that they are using up-to-date and robust methods to protect their data.
5. Flexible, Risk-Based Approach:
Dynamic Threat Landscape: The regulation emphasizes the need for a flexible approach to dealing with cryptographic threats, acknowledging that the threat landscape is dynamic and continuously evolving. Financial entities should be prepared to adapt their cryptographic measures in response to new risks, such as those posed by advancements in quantum computing.
Continuous Monitoring and Mitigation: Ongoing risk mitigation and monitoring are essential. Financial entities should not only implement cryptographic controls but also continuously evaluate their effectiveness and adjust them as needed to address emerging threats.
Summary:
In summary, DORA requires financial entities to implement cryptographic controls to protect data based on a risk-based approach. This involves encrypting data at rest, in transit, and, where appropriate, in use. The regulation acknowledges the complexity of encrypting data in use and allows for alternative security measures when encryption is not feasible. Financial entities are also encouraged to stay informed about developments in cryptography, especially in light of emerging threats like quantum computing, and to remain flexible in their approach to addressing cryptographic risks.
In the vast majority of cases, strict separation of ICT production environments from environments where ICT systems are developed and tested or from other non-production environments is key to well functioning security and should be the default procedure.
-
TL;DR
In the vast majority of cases, strict separation of ICT production environments from environments where ICT systems are developed and tested or from other non-production environments is key to well functioning security and should be the default procedure. DORA does however recognize that in exceptional circumstances, financial entities should be allowed to test in production environments, provided that they justify such testing.
FULL VERSION
This passage discusses the importance of ICT (Information and Communication Technology) operations security and the role of operational policies, procedures, protocols, and tools in protecting the data handled by financial entities. Here’s a detailed explanation:
1. Separation of Environments:
Concept: One of the key security practices is the strict separation of different ICT environments, particularly:
Production Environment: The live environment where actual business operations occur, and real-time data is processed.
Development and Testing Environments: Where new ICT systems, updates, or features are developed and tested before they are deployed to the production environment.
Non-Production Environments: Any other environments used for purposes like training, simulation, or testing that are not part of live operations.
Purpose of Separation: The strict separation between these environments serves as a critical security measure to:
Prevent unintended or unauthorized access to the production environment, where live data is handled.
Avoid accidental modifications or deletions of data in the production environment, which could disrupt business operations.
Mitigate the risk of introducing errors or vulnerabilities from development and testing phases into live operations.
2. Exceptional Circumstances for Testing in Production:
Current Practices: In some modern ICT system development practices, it may be necessary to test systems directly in the production environment, especially when testing in a separate environment cannot fully replicate the production scenario.
Conditions for Testing in Production: The regulation allows for such testing in production environments under exceptional circumstances, provided that:
The financial entity can justify the need for testing in the production environment (e.g., no alternative environment can accurately simulate production conditions).
The entity obtains the required approval from relevant authorities or internal governance bodies before conducting the testing.
Approval and Justification: This ensures that testing in production is a well-considered decision with appropriate risk management measures in place to minimize potential negative impacts.
Summary
The passage highlights the importance of maintaining strict separation between ICT environments—particularly the production environment and development/testing environments—as a critical security measure for financial entities. This separation helps prevent unauthorized access, data modification, and disruptions in live operations. However, recognizing the realities of modern ICT practices, the regulation allows for testing in production environments under exceptional circumstances, provided that it is justified and approved to safeguard the integrity of business operations.
This section of DORA emphasizes the need for companies to take a proactive and comprehensive approach to managing ICT vulnerabilities.
-
TL;DR
This section of DORA emphasizes the need for companies to take a proactive and comprehensive approach to managing ICT vulnerabilities. Companies should identify and remedy vulnerabilities in their ICT environment, and both the financial entities and their ICT third-party service providers should use an effective vulnerability management framework. Financial entities should monitor ICT vulnerabilities using reliable resources and automated tools, verifying that ICT third-party service providers ensure prompt action on vulnerabilities in provided ICT services.
FULL VERSION
DORA highlights the importance of a proactive and structured approach to managing ICT vulnerabilities in financial entities. Given the dynamic nature of ICT landscapes and the increasing sophistication of cyber threats, the regulation outlines specific measures to help financial entities protect their digital operational resilience. Here's a detailed explanation:
1. The Need for Proactive and Comprehensive Vulnerability Management:
Dynamic ICT Landscape: The rapid evolution of technology and the increasing complexity of ICT systems create new vulnerabilities and cyber threats regularly. Financial entities must be prepared to identify and address these vulnerabilities proactively.
Risks of Inaction: Without a comprehensive approach to managing ICT vulnerabilities, financial entities, along with their customers, users, and counterparties, are at risk. These risks can impact the entity's digital operational resilience, which is its ability to withstand and recover from ICT disruptions, and can compromise the security, availability, authenticity, integrity, and confidentiality of data.
2. Requirements for Financial Entities:
Identifying and Remedying Vulnerabilities: Financial entities must actively identify vulnerabilities within their ICT environments and take steps to address them. This involves regularly assessing their systems for weaknesses and implementing fixes or patches to eliminate those vulnerabilities.
Adhering to a Vulnerability Management Framework: Both financial entities and their ICT third-party service providers must follow a consistent and responsible approach to vulnerability management. This framework should be transparent, ensuring that all parties involved understand their responsibilities and the processes in place to manage vulnerabilities effectively.
3. Role of ICT Third-Party Service Providers:
Collaboration and Accountability: ICT third-party service providers play a critical role in the security of financial entities' systems. The regulation requires these providers to adhere to the same standards of vulnerability management, ensuring that they address any weaknesses in the services they provide promptly.
Verification by Financial Entities: Financial entities must verify that their third-party providers are taking appropriate actions to manage vulnerabilities. This ensures that the entire ICT ecosystem, including outsourced services, remains secure.
4. Monitoring ICT Vulnerabilities:
Use of Reliable Resources and Automated Tools: Financial entities are encouraged to use reliable resources, such as industry databases and reports, to stay informed about new vulnerabilities. Automated tools can also help monitor systems continuously, enabling faster detection and response to vulnerabilities.
Continuous Monitoring: Given the fast-paced nature of cyber threats, continuous monitoring of vulnerabilities is essential. Financial entities should be vigilant in tracking potential weaknesses and ensuring that they are addressed as quickly as possible.
5. Importance of a Proactive Approach:
Preventive Measures: A proactive approach to vulnerability management is crucial in preventing cyberattacks and system failures before they occur. By identifying and addressing vulnerabilities early, financial entities can reduce the likelihood of security breaches and operational disruptions.
Maintaining Digital Resilience: Effective vulnerability management is key to maintaining the digital resilience of financial entities, ensuring that they can continue operating securely even in the face of evolving threats.
Summary:
In summary, this section of the regulation emphasizes the need for financial entities to take a proactive and comprehensive approach to managing ICT vulnerabilities. By identifying and addressing vulnerabilities in their systems, and by ensuring that their ICT third-party service providers do the same, financial entities can protect their digital operational resilience. Continuous monitoring using reliable resources and automated tools is essential for staying ahead of evolving cyber threats. This approach ensures the security, availability, authenticity, integrity, and confidentiality of the data that financial entities rely on for their operations.
Patch management is a critical aspect of managing ICT security policies and procedures. It involves regularly updating systems to fix vulnerabilities and improve security. DORA also stresses the importance of testing patches in a controlled environment before deploying them to live systems to prevent disruptions.
-
TL;DR
Patch management is a critical aspect of ICT security policies and procedures for financial entities. It involves regularly updating systems to fix vulnerabilities and improve security. DORA also stresses the importance of testing patches in a controlled environment before deploying them to live systems to prevent disruptions.
FULL VERSION
This part of DORA emphasizes the importance of patch management within ICT security policies and procedures. Patch management is a process that involves regularly updating software and systems to fix vulnerabilities and improve security. The regulation highlights specific practices to ensure patches are implemented effectively without causing disruptions. Here's a detailed explanation:
1. Importance of Patch Management:
Purpose: Patch management is crucial because it addresses vulnerabilities in software and systems. By applying patches, financial entities can fix security weaknesses that could be exploited by cyber threats, thereby protecting their ICT infrastructure.
Preventive Measure: Regular patching helps prevent disruptions caused by security breaches or system failures that could result from unpatched vulnerabilities.
2. Integration into ICT Security Policies and Procedures:
Comprehensive Approach: Patch management should be integrated into the broader ICT security framework of financial entities. It should not be a standalone process but part of a well-defined set of policies and procedures that guide how vulnerabilities are identified, assessed, and addressed.
Consistency: Including patch management in security policies ensures that all patches are applied consistently and in accordance with established security protocols, reducing the risk of errors or omissions.
3. Testing and Deployment in a Controlled Environment:
Controlled Environment: Before deploying patches to live systems (production environments), they should be tested in a controlled, non-production environment. This allows the entity to verify that the patch resolves the identified vulnerability without causing any unintended issues, such as software conflicts or performance problems.
Risk Mitigation: Testing patches in a controlled environment helps prevent disruptions to business operations that could occur if a patch is applied directly to a live system without proper validation. This step is crucial for maintaining the stability and security of ICT systems.
4. Resolving Identified Vulnerabilities:
Addressing Security Weaknesses: The primary goal of patch management is to resolve vulnerabilities that have been identified in the ICT systems. By applying patches promptly, financial entities can close security gaps and protect their systems from potential attacks.
Continuous Process: Vulnerabilities are continually discovered as new threats emerge, so patch management is an ongoing process that requires regular attention and action.
5. Preventing Disruptions from Patch Installation:
Minimizing Operational Impact: One of the challenges of patch management is ensuring that the installation of patches does not disrupt normal business operations. This is why testing in a controlled environment is so important—it allows financial entities to ensure that the patch will not cause any issues when deployed to live systems.
Planning and Timing: Patches should be deployed in a way that minimizes the impact on business operations, such as during scheduled maintenance windows. This careful planning helps avoid unexpected downtime or system interruptions.
Summary:
In summary, patch management is a critical aspect of ICT security policies and procedures for financial entities. It involves regularly updating systems to fix vulnerabilities and improve security. The regulation stresses the importance of testing patches in a controlled environment before deploying them to live systems to prevent disruptions. By integrating patch management into their security framework and ensuring that patches are applied consistently and effectively, financial entities can protect their ICT infrastructure from threats while maintaining operational stability.
Companies must ensure timely and transparent communication of potential security threats that could impact the company, its customers, counterparts, and the public. Factors like the severity of the vulnerability, the potential impact of the vulnerability on stakeholders, and the readiness of a fix or mitigation measures should be included in the communication.
-
TL;DR
Companies must ensure timely and transparent communication of potential security threats that could impact the company, its customers, counterparts, and the public. Factors like the severity of the vulnerability, the potential impact of the vulnerability on stakeholders, and the readiness of a fix or mitigation measures should be included in the communication.
FULL VERSION
DORA highlights the importance of timely and transparent communication regarding ICT vulnerabilities that could impact a financial entity and its stakeholders. It mandates financial entities to establish procedures for the responsible disclosure of vulnerabilities to relevant parties. Here’s a detailed explanation:
1. Purpose of Responsible Disclosure:
Timely Communication: The regulation stresses the need for financial entities to communicate potential security threats as soon as they are identified. This ensures that stakeholders, including clients and counterparts, are aware of risks that might affect them.
Transparency: Transparency in communicating vulnerabilities helps build trust with clients, partners, and the public. It ensures that all parties are informed and can take appropriate actions to protect themselves.
2. Establishing Disclosure Procedures:
Formal Procedures: Financial entities must create formal procedures for disclosing ICT vulnerabilities. These procedures should outline when and how vulnerabilities will be communicated to clients, counterparts, and the public.
Consistency: Having clear procedures ensures that disclosures are handled consistently, reducing the risk of misinformation or delayed communication.
3. Factors to Consider in Disclosure:
When establishing these procedures, financial entities should consider several key factors to ensure that disclosures are appropriate and effective:
Severity of the Vulnerability:
High-Severity Vulnerabilities: For vulnerabilities that pose a significant risk to the entity or its stakeholders, prompt and detailed disclosure is critical. This helps affected parties understand the seriousness of the threat.
Low-Severity Vulnerabilities: For less critical vulnerabilities, disclosures may be less urgent or detailed, depending on the potential impact.
Potential Impact on Stakeholders:
Client and Counterpart Exposure: The procedures should assess how the vulnerability might affect various stakeholders. For example, if a vulnerability could lead to data breaches or financial losses for clients, they need to be informed quickly.
Broader Public Impact: If a vulnerability has the potential to affect a large number of people or the financial system as a whole, public disclosure may be necessary to ensure widespread awareness and preparedness.
Readiness of a Fix or Mitigation Measures:
Available Solutions: The entity should consider whether a fix or mitigation measures are available before disclosing a vulnerability. If a solution is ready, the disclosure can include information on how stakeholders can protect themselves.
Guidance for Stakeholders: If a fix is not yet available, the entity should provide guidance on how stakeholders can mitigate the risk in the meantime.
4. Benefits of Responsible Disclosure:
Risk Mitigation: By informing stakeholders of vulnerabilities, financial entities help them take proactive steps to mitigate risks, reducing the potential impact of security threats.
Trust and Accountability: Transparent communication demonstrates accountability and helps maintain trust between the financial entity and its clients, partners, and the public.
Collaborative Security: Responsible disclosure can also encourage collaboration between the financial entity and its stakeholders in addressing and resolving vulnerabilities.
Summary:
In summary, the regulation requires financial entities to establish procedures for the
responsible disclosure
of ICT vulnerabilities to clients, counterparts, and the public. These procedures must consider the severity of the vulnerability, its potential impact on stakeholders, and whether a fix or mitigation measures are available. By ensuring timely and transparent communication, financial entities can help stakeholders manage risks effectively and maintain trust in the security of the financial system.
Only strong identification measures to manage user access rights should be used. Shared accounts might be used in exceptional cases but are discouraged in all other cases.
-
TL;DR
Only strong identification measures to manage user access rights should be used. Shared accounts might be used in exceptional cases but are discouraged in all other cases.
TL;DR
Only strong identification measures to manage user access rights should be used. Shared accounts might be used in exceptional cases but are discouraged in all other cases.
FULL VERSION
This section of DORA focuses on the importance of user access management in safeguarding sensitive financial data. It outlines the need for financial entities to implement strong measures for identifying individuals and systems that access their information and addresses the risks associated with unauthorized access and shared accounts. Here’s a detailed explanation:
1. User Access Rights and Unique Identification:
Assignment of User Access Rights: Financial entities need to control who can access their systems and data. This involves assigning access rights based on roles, responsibilities, and the principle of least privilege, meaning users should only have access to the data and systems necessary for their job.
Unique Identification: To manage access effectively, financial entities must ensure that every individual or system accessing their information is uniquely identified. This could involve using unique usernames, biometric data, or other identification methods to ensure that each action within the system can be traced back to a specific user or system.
2. Risks of Failing to Implement Strong Identification Measures:
Unauthorized Access: Without strong identification measures, financial entities are at risk of unauthorized users gaining access to sensitive information. This can lead to data breaches, where confidential financial data is exposed to unauthorized parties.
Data Breaches and Fraud: Poor access control can also result in fraudulent activities, where malicious actors manipulate financial data for personal gain, leading to significant financial and reputational damage.
Compromised Data Integrity and Availability: Unauthorized access can also compromise the integrity (accuracy and consistency) and availability (ensuring data is accessible when needed) of financial data, which are critical for the entity's operations and compliance with regulations.
3. Use of Generic or Shared Accounts:
Exceptional Circumstances: While the use of generic or shared accounts (e.g., accounts not tied to a specific individual) is generally discouraged due to the risks they pose, the regulation acknowledges that there may be exceptional circumstances where they are necessary. For example, during specific maintenance activities or in situations requiring collaborative work that makes individual accounts impractical.
Specified by Financial Entities: Financial entities must clearly define when and how shared accounts can be used. This includes establishing strict rules and conditions under which these accounts are permitted.
4. Maintaining Accountability:
Accountability for Actions: Even when shared accounts are used, financial entities must ensure that there is accountability for all actions taken through those accounts. This can be achieved by implementing measures such as logging, monitoring, and tracking activities to ensure that every action can be traced back to an individual or system.
Preventing Malicious Activities: Without accountability, malicious users could exploit shared accounts to perform unauthorized actions without being detected. This lack of traceability can hinder investigations and make it difficult to identify the source of a breach or fraudulent activity.
5. Impact of Inadequate Safeguards:
Hindering Investigations: If financial entities do not maintain accountability for actions taken through shared accounts, it can be challenging to investigate security incidents or data breaches. This can delay corrective measures and leave the entity vulnerable to ongoing threats.
Compliance Risks: Inadequate access controls and accountability can lead to non-compliance with regulatory requirements, resulting in penalties and damage to the entity's reputation.
Summary:
In summary, financial entities must establish strong identification measures to manage user access rights and protect sensitive financial data. Unique identification of individuals and systems is essential to prevent unauthorized access, data breaches, and fraud. While the use of shared accounts may be allowed in exceptional cases, financial entities must ensure that accountability is maintained to trace all actions and mitigate the risks of malicious activities. This approach is crucial for ensuring the confidentiality, integrity, and availability of financial data and for maintaining compliance with regulatory standards.
This section of DORA focuses on the importance of user access management in safeguarding sensitive financial data. It outlines the need for financial entities to implement strong measures for identifying individuals and systems that access their information and addresses the risks associated with unauthorized access and shared accounts. Here’s a detailed explanation:
1. User Access Rights and Unique Identification:
Assignment of User Access Rights: Financial entities need to control who can access their systems and data. This involves assigning access rights based on roles, responsibilities, and the principle of least privilege, meaning users should only have access to the data and systems necessary for their job.
Unique Identification: To manage access effectively, financial entities must ensure that every individual or system accessing their information is uniquely identified. This could involve using unique usernames, biometric data, or other identification methods to ensure that each action within the system can be traced back to a specific user or system.
2. Risks of Failing to Implement Strong Identification Measures:
Unauthorized Access: Without strong identification measures, financial entities are at risk of unauthorized users gaining access to sensitive information. This can lead to data breaches, where confidential financial data is exposed to unauthorized parties.
Data Breaches and Fraud: Poor access control can also result in fraudulent activities, where malicious actors manipulate financial data for personal gain, leading to significant financial and reputational damage.
Compromised Data Integrity and Availability: Unauthorized access can also compromise the integrity (accuracy and consistency) and availability (ensuring data is accessible when needed) of financial data, which are critical for the entity's operations and compliance with regulations.
3. Use of Generic or Shared Accounts:
Exceptional Circumstances: While the use of generic or shared accounts (e.g., accounts not tied to a specific individual) is generally discouraged due to the risks they pose, the regulation acknowledges that there may be exceptional circumstances where they are necessary. For example, during specific maintenance activities or in situations requiring collaborative work that makes individual accounts impractical.
Specified by Financial Entities: Financial entities must clearly define when and how shared accounts can be used. This includes establishing strict rules and conditions under which these accounts are permitted.
4. Maintaining Accountability:
Accountability for Actions: Even when shared accounts are used, financial entities must ensure that there is accountability for all actions taken through those accounts. This can be achieved by implementing measures such as logging, monitoring, and tracking activities to ensure that every action can be traced back to an individual or system.
Preventing Malicious Activities: Without accountability, malicious users could exploit shared accounts to perform unauthorized actions without being detected. This lack of traceability can hinder investigations and make it difficult to identify the source of a breach or fraudulent activity.
5. Impact of Inadequate Safeguards:
Hindering Investigations: If financial entities do not maintain accountability for actions taken through shared accounts, it can be challenging to investigate security incidents or data breaches. This can delay corrective measures and leave the entity vulnerable to ongoing threats.
Compliance Risks: Inadequate access controls and accountability can lead to non-compliance with regulatory requirements, resulting in penalties and damage to the entity's reputation.
Summary:
In summary, financial entities must establish strong identification measures to manage user access rights and protect sensitive financial data. Unique identification of individuals and systems is essential to prevent unauthorized access, data breaches, and fraud. While the use of shared accounts may be allowed in exceptional cases, financial entities must ensure that accountability is maintained to trace all actions and mitigate the risks of malicious activities. This approach is crucial for ensuring the confidentiality, integrity, and availability of financial data and for maintaining compliance with regulatory standards.
To manage the rapid advancement in ICT environments, companies should implement robust ICT project management policies and procedures to maintain data availability, authenticity, integrity, and confidentiality.
-
TL;DR
To manage the rapid advancement in ICT environments, companies should implement robust ICT project management policies and procedures to maintain data availability, authenticity, integrity, and confidentiality.
These policies and procedures should adopt testing practices and a risk-based approach. To guarantee the secure implementation of an ICT project, financial entities should ensure that staff from specific business sectors or roles influenced or impacted by that ICT project can provide the necessary information and expertise. To ensure effective oversight, reports on ICT projects, in particular about projects that affect critical or important functions and about their associated risks, should be submitted to the management body. Financial entities should tailor the frequency and details of the systematic and ongoing reviews and reports to the importance and the size of the ICT projects concerned.
FULL VERSION
This section of DORA emphasizes the importance of robust ICT project management within financial entities to ensure the security, reliability, and resilience of their ICT systems. Given the rapid advancements in technology, financial entities must adopt comprehensive policies and procedures to manage ICT projects effectively. Here’s a detailed explanation:
1. Importance of Robust ICT Project Management:
Purpose: Financial entities need to ensure that their ICT systems remain secure and reliable as they undergo changes, acquisitions, maintenance, or development. Robust ICT project management is essential to maintain the availability, authenticity, integrity, and confidentiality of data throughout these processes.
Adaptability: The regulation recognizes that ICT environments are rapidly advancing, so financial entities must have flexible and effective project management practices in place to keep pace with these changes.
2. Key Elements of ICT Project Management:
Identification of Necessary Elements: Financial entities should identify the essential components needed to manage ICT projects successfully. This includes recognizing the specific requirements for different types of ICT activities, such as system upgrades, acquisitions, or new developments.
Comprehensive Approach: Regardless of the project management methodology chosen (e.g., Agile, Waterfall, etc.), the regulation mandates that financial entities maintain a comprehensive approach that ensures all critical aspects of ICT systems are addressed.
3. Testing Practices and Risk-Based Approach:
Tailored Testing Practices: Financial entities are encouraged to adopt testing practices and methods that fit their unique needs. These practices should be designed to ensure that new systems, updates, or changes do not introduce vulnerabilities or disrupt operations.
Risk-Based Approach: The testing and management of ICT projects should be guided by a risk-based approach. This means that the level of testing, scrutiny, and resources allocated should correspond to the potential risks associated with the project. Higher-risk projects or changes should receive more thorough testing and evaluation.
4. Involvement of Relevant Staff:
Cross-Functional Collaboration: For a secure implementation of ICT projects, it is crucial that staff from relevant business sectors or roles that are influenced or impacted by the project are involved. These individuals can provide essential insights and expertise that ensure the project meets business needs while maintaining security.
Knowledge Sharing: Involving these staff members helps ensure that the project is aligned with the financial entity’s operational requirements and that any potential security or operational risks are addressed.
5. Oversight and Reporting:
Reporting to Management: Financial entities are required to submit reports on ICT projects to the management body, especially for projects that affect critical or important functions. These reports should highlight the associated risks and the progress of the project, ensuring that senior management is aware of and can oversee significant ICT initiatives.
Systematic Reviews and Reports: The regulation calls for ongoing and systematic reviews of ICT projects. The frequency and detail of these reviews should be tailored to the size and importance of the project. For example, larger projects with higher risks may require more frequent and detailed reviews, while smaller, less critical projects may need less oversight.
6. Maintaining a Secure ICT Environment:
Focus on Security and Resilience: Throughout the project management process, financial entities must ensure that their ICT environment remains secure, reliable, and resilient. This involves carefully managing risks, testing systems thoroughly, and ensuring that all changes are implemented securely.
Continuous Improvement: By systematically reviewing and reporting on ICT projects, financial entities can continuously improve their project management practices, ensuring that their ICT systems remain robust in the face of evolving threats and challenges.
Summary:
In summary, financial entities need to implement robust ICT project management policies and procedures to manage the rapid advancement in technology effectively. These policies should cover all aspects of ICT projects, from changes and acquisitions to maintenance and development. By adopting a risk-based approach, involving relevant staff, and ensuring systematic oversight and reporting, financial entities can maintain a secure, reliable, and resilient ICT environment. The regulation emphasizes the importance of adaptability, security, and thorough testing to safeguard the availability, authenticity, integrity, and confidentiality of financial data.
Financial entities are required to thoroughly evaluate and test software packages before integrating them into their ICT environments. This includes conducting ICT security testing to identify vulnerabilities, as well as reviewing the source code of both acquired and proprietary software where feasible.
-
TL;DR
Companies are required to thoroughly evaluate and test software packages before integrating them into their ICT environments. This includes conducting ICT security testing to identify vulnerabilities, as well as reviewing the source code of both acquired and proprietary software where feasible. The use of static and dynamic testing methods ensures that software integrity is maintained and that potential security risks are mitigated.
FULL VERSION
DORA highlights the importance of ensuring that software packages acquired or developed by financial entities are securely integrated into their existing ICT environments. It mandates thorough evaluation and testing of software to mitigate potential ICT security risks. Here’s a detailed explanation:
1. Secure Integration of Software:
Purpose: Financial entities need to ensure that any software they acquire or develop is effectively and securely integrated into their existing ICT infrastructure. This means that the software must align with the entity's business and information security objectives and not introduce new risks.
Alignment with Objectives: The software should support the financial entity’s operational goals while maintaining the confidentiality, integrity, and availability of data. This involves ensuring that the software does not conflict with or weaken existing security measures.
2. Thorough Evaluation of Software Packages:
Evaluation Process: Before integrating any software into their systems, financial entities must thoroughly evaluate it to identify any potential security vulnerabilities or compatibility issues with their existing ICT environment.
Assessment Criteria: The evaluation should consider various factors, including the software’s security features, its ability to meet business needs, and any potential impact on existing systems.
3. ICT Security Testing:
Purpose of Security Testing: To identify vulnerabilities and potential security gaps, financial entities are required to perform ICT security testing on the software packages they acquire or develop. This testing is crucial for ensuring that the software does not introduce new threats to the financial entity’s systems.
Broader ICT Systems: The testing should not only focus on the software itself but also consider how it interacts with the broader ICT environment. This helps in identifying any security gaps that could arise from integrating the software with existing systems.
4. Review of Source Code:
Source Code Review: To assess the integrity of the software and ensure it does not pose security risks, financial entities should review the source code of the software they acquire. This review helps in identifying any vulnerabilities or hidden threats within the code itself.
Proprietary Software: For proprietary software provided by third-party ICT service providers, financial entities should review the source code where feasible. While access to proprietary source code may be limited, the regulation emphasizes the importance of attempting to assess the security of such software as thoroughly as possible.
5. Static and Dynamic Testing Methods:
Static Testing: This involves analyzing the software's source code without executing it. Static testing helps identify vulnerabilities or coding errors that could be exploited by attackers before the software is run.
Dynamic Testing: Dynamic testing involves executing the software in a controlled environment to observe how it behaves in real-time. This helps in identifying runtime vulnerabilities, such as issues that only emerge when the software interacts with other systems or handles specific data inputs.
6. Mitigating ICT Security Risks:
Preventing Risks: By carrying out thorough evaluations, source code reviews, and ICT security testing, financial entities can mitigate the risk of introducing vulnerabilities through new software. This proactive approach ensures that any potential security issues are addressed before the software is integrated into the live environment.
Ongoing Vigilance: Even after software is integrated, ongoing monitoring and testing are necessary to ensure that it continues to meet security standards and does not introduce new risks over time.
Summary:
In summary, financial entities are required to thoroughly
evaluate and test software packages
before integrating them into their ICT environments. This includes conducting
ICT security testing
to identify vulnerabilities, as well as reviewing the
source code
of both acquired and proprietary software where feasible. The use of
static and dynamic testing methods
ensures that software integrity is maintained and that potential security risks are mitigated. These measures help financial entities maintain a secure ICT environment that supports their business and information security objectives, minimizing the risk of data breaches or other security incidents.
DORA stipulates that financial institutions should have sound ICT change management policies and procedures. Change management policies and procedures should separate the functions responsible for approving changes from the functions that request and implement those changes to prevent conflicts of interest, and to uphold the objectivity and effectiveness of the change management process.
-
TL;DR
DORA stipulates that financial institutions should have in place sound ICT change management policies and procedures. Change management policies and procedures should separate the functions responsible for approving changes from the functions that request and implement those changes to prevent conflicts of interest, and to uphold the objectivity and effectiveness of the change management process. It is also crucial to assign clear roles and responsibilities that ensure that ICT changes are planned, adequately tested, and that quality is ensured.
Financial entities should also develop and implement fall-back procedures. Financial entities should clearly identify those fall- back procedures and assign responsibilities to ensure a swift and effective response in the event of unsuccessful ICT changes.
Change management policies and procedures should:
separate the functions responsible for approving changes from the functions that request and implement those changes
assign clear roles and responsibilities that ensure that ICT changes are planned, adequately tested, and that quality is ensured
develop and implement fall-back procedures
FULL VERSION
DORA stresses the importance of having strong ICT (Information and Communication Technology) change management practices in financial entities to mitigate risks. Here’s a breakdown of the key points:
1. Inherent Risks of ICT Changes:
Impact of Changes: Any modification to ICT systems, regardless of its scale, carries risks. These changes could potentially lead to a loss of data confidentiality, integrity, and availability, which are critical aspects of information security.
Business Disruptions: If these risks materialize, they can result in severe disruptions to business operations, impacting the financial entity's ability to function smoothly.
2. Necessity for Rigorous Verification:
Verification Process: To prevent vulnerabilities and weaknesses that could expose financial entities to significant risks, a thorough verification process is essential. This process ensures that all changes comply with the necessary ICT security standards.
ICT Security Requirements: Verification is a critical step to ensure that changes do not compromise the security of the ICT systems, thereby protecting the entity from potential threats.
3. ICT Change Management Policies and Procedures:
Implementation: Financial entities are required to implement sound ICT change management policies and procedures as part of their broader ICT security framework.
Purpose: These policies serve to systematically manage changes in a way that mitigates risks, ensures compliance with security requirements, and prevents disruptions to ICT operations.
4. Separation of Duties:
Conflict of Interest Prevention: To maintain the objectivity of the change management process, the regulation emphasizes the need to separate the functions responsible for approving changes from those that request and implement them.
Objective Evaluation: This separation helps to ensure that changes are evaluated impartially, reducing the risk of conflicts of interest and ensuring that decisions are made based on security and operational effectiveness rather than on the interests of those implementing the changes.
5. Clear Roles and Responsibilities:
Assignment of Roles: It is important for financial entities to clearly define and assign roles and responsibilities within the change management process. This clarity helps ensure that every aspect of the process, from planning to testing and implementation, is handled by the appropriate personnel.
Controlled Implementation: Clear roles also facilitate controlled implementation of changes, ensuring that they are executed in a manner that minimizes risks and disruptions.
6. Testing and Quality Assurance:
Adequate Testing: Before rolling out changes, thorough testing is necessary to confirm that the changes will function as expected without causing issues. Testing also verifies that security standards are maintained.
Ensuring Quality: Quality assurance measures are in place to confirm that the changes meet all necessary requirements and do not introduce new vulnerabilities.
7. Fall-Back Procedures:
Developing Contingency Plans: Financial entities should establish fall-back procedures as a safety net in case changes fail or cause issues. These procedures allow the entity to revert to a previous state or take corrective actions quickly.
Swift Response: The regulation emphasizes the importance of clearly identifying fall-back procedures and assigning responsibilities, ensuring that if something goes wrong, the entity can respond effectively and minimize disruptions.
8. Minimizing Disruptions:
Smooth Transitions: By implementing well-planned and controlled change management processes, financial entities can ensure smooth transitions and minimize the risk of operational disruptions.
Maintaining System Functionality: These measures help maintain the integrity and availability of ICT systems, ensuring that the entity can continue to operate effectively even during periods of change.
Summary:
In summary, financial entities must implement robust ICT change management policies to address the inherent risks associated with changes to their systems. These policies should include rigorous verification processes, separation of duties to prevent conflicts of interest, clearly defined roles and responsibilities, thorough testing, and fall-back procedures. By doing so, financial entities can minimize disruptions, maintain system security, and ensure a swift response in case of issues, thereby safeguarding their operations and data integrity.
Companies must establish comprehensive ICT-related incident management policies and procedures that, at the minimum, include:
Key stakeholders and contacts inside the company
Key stakeholders and contact outside the company
Focuses on optimizing incident detection and response
Prepare policies, procedures and make sure that you have qualified resources available, internal or external, for detailed analysis of significant incidents.
-
TL;DR
Companies must establish a comprehensive ICT-related incident management policy and procedures that, at the minimum, includes:
Key stakeholders and contacts inside the company
Key stakeholders and contact outside the company
Focuses on optimizing incident detection and response
Prepare policies, procedures and make sure that you have qualified resources available, internal or external, for detailed analysis of significant incidents.
FULL VERSION
DORA states the importance of establishing a comprehensive ICT-related incident management policy for financial entities. The goal is to ensure that these entities can effectively detect, manage, and report ICT-related incidents. Here’s an explanation of the key components:
1. ICT-Related Incident Policy:
Purpose: Financial entities need to create a detailed ICT-related incident policy that outlines how they will handle ICT incidents. This policy should cover all aspects of the incident management process, from detection to resolution and reporting.
Incident Management Process: The policy should define the steps and procedures for managing ICT incidents, ensuring a systematic approach to handling such incidents when they occur.
2. Identification of Contacts:
Internal and External Contacts: Financial entities should identify all relevant contacts both inside and outside the organization who can assist in managing ICT incidents. These contacts are essential for coordinating responses and ensuring that the incident management process is executed effectively.
Coordination and Implementation: Having the right contacts in place ensures that all phases of the incident management process are properly coordinated and implemented, reducing the likelihood of delays or miscommunications during an incident.
3. Optimizing Incident Detection and Response:
Detection and Response: The policy should focus on optimizing the detection of ICT incidents and ensuring a swift and effective response. This includes having the right tools, processes, and personnel in place to quickly identify and address incidents.
Trend Analysis: By analyzing ICT-related incidents, financial entities can identify patterns and trends that might point to underlying issues. This analysis is crucial for improving the overall effectiveness of the incident management process.
4. Focus on Significant Incidents:
Analyzing Significant Incidents: Financial entities should pay special attention to incidents that are considered the most significant, especially those that occur frequently. These incidents often reveal deeper problems that need to be addressed to prevent future occurrences.
Root Cause Identification: Detailed analysis of significant incidents can help financial entities identify root causes, allowing them to implement solutions that address the underlying issues, rather than just treating the symptoms.
5. Continuous Improvement:
Learning from Incidents: The information gathered from analyzing ICT incidents provides valuable insights. Financial entities can use this information to continuously improve their incident management processes and enhance their overall ICT security posture.
Preventative Measures: By understanding the causes of frequent or severe incidents, financial entities can implement preventative measures, reducing the likelihood of similar incidents in the future.
Summary:
Financial entities must establish a comprehensive ICT-related incident management policy that includes the identification of key contacts, a focus on optimizing incident detection and response, and detailed analysis of significant incidents. By doing so, they can effectively manage and report ICT-related incidents, identify trends, and address root causes to prevent future issues. This approach not only helps in resolving incidents more efficiently but also strengthens the financial entity's overall digital resilience.
Companies must adopt a broad approach to detect anomalous activities by collecting and analyzing information from various sources. Policies and procedures should include:
Internal sources, like logs and reports from internal functions
External sources, such as data from ICT third-party providers
Assignment of clear roles and responsibilities within the entity to ensure that this process is handled effectively
In cases where personal data is involved, entities must comply with data protection laws, limiting the collection of such data to what is necessary for incident detection
-
TL;DR
Companies must adopt a broad approach to detect anomalous activities by collecting and analyzing information from various sources, both internal (like logs and reports from internal functions) and external (such as data from ICT third-party providers) and assigning clear roles and responsibilities within the entity to ensure that this process is handled effectively. Additionally, when personal data is involved, entities must comply with data protection laws, limiting the collection of such data to what is necessary for incident detection. This comprehensive approach enhances the financial entity's ability to detect and respond to potential security threats early on.
FULL VERSION
DORA emphasizes the importance of a comprehensive approach to detecting anomalous activities within financial institutions. The regulation outlines specific measures financial entities should take to ensure early and effective detection of potential threats. Here’s an explanation of the key points:
1. Early and Effective Detection:
Objective: The regulation aims to ensure that financial entities can detect unusual or suspicious activities at an early stage. Early detection is critical for preventing or mitigating potential security incidents.
Comprehensive Information Gathering: To achieve effective detection, financial entities need to gather and monitor information from multiple sources, both internal and external, rather than relying on a single data source.
2. Internal Information Sources:
Role of Logs: Logs, which record the activities and events within the entity's systems, are highlighted as an extremely relevant internal source of information. Logs can provide detailed insights into system behavior and help identify anomalies.
Beyond Logs: However, the regulation stresses that logs alone are not sufficient. Financial entities should also consider other internal sources of information, such as reports from various internal functions (e.g., security teams, risk management, or compliance departments). These functions may provide valuable information that logs might not capture.
3. External Information Sources:
Third-Party Providers: External information is equally important. Financial entities should monitor information from ICT third-party providers, especially regarding incidents that affect their systems and networks. This is crucial because issues with third-party providers can have a direct impact on the financial entity's operations.
Other External Sources: Besides third-party providers, financial entities should also consider other relevant external sources of information. This could include industry reports, threat intelligence feeds, or information shared within the financial sector about emerging threats.
4. Assigning Roles and Responsibilities:
Clear Responsibilities: The regulation emphasizes the importance of assigning specific roles and responsibilities within the financial entity for collecting, monitoring, and analyzing the gathered information. This ensures that the process is organized, efficient, and that nothing is overlooked.
5. Personal Data Considerations:
Data Protection Compliance: If the information gathered for incident detection includes personal data, the financial entities must comply with Union data protection laws (such as GDPR). This means that personal data should only be collected and processed to the extent necessary for detecting incidents, ensuring the protection of individual privacy.
Summary:
Financial entities must adopt a broad approach to detect anomalous activities by collecting and analyzing information from various sources, both internal (like logs and reports from internal functions) and external (such as data from ICT third-party providers). Assigning clear roles and responsibilities within the entity ensures that this process is handled effectively. Additionally, when personal data is involved, entities must comply with data protection laws, limiting the collection of such data to what is necessary for incident detection. This comprehensive approach enhances the financial entity's ability to detect and respond to potential security threats early on.
To enhance the detection and investigation of ICT-related incidents, financial companies should retain evidence of incidents for a period of time that balances usefulness and regulatory compliance. The retention period should be determined based on the criticality of the data involved and any applicable Union laws.
-
TL;DR
To enhance the detection and investigation of ICT-related incidents, financial companies should retain evidence of incidents for a period of time that balances usefulness and regulatory compliance. The retention period should be determined based on the criticality of the data involved and any applicable Union laws, ensuring that evidence is kept long enough to be effective without creating unnecessary regulatory burdens.
FULL VERSION
DORA states the importance of retaining evidence of ICT-related incidents within financial entities and provides guidance on how long this evidence should be kept. Here's an explanation of the key points:
1. Purpose of Retaining Evidence:
Facilitating Detection: Retaining evidence of ICT-related incidents is crucial for improving the detection and analysis of such incidents. By keeping records and data related to past incidents, financial entities can better understand patterns, identify root causes, and strengthen their defenses against future incidents.
Incident Investigation: This retained evidence also plays a critical role in investigating incidents, allowing entities to review what happened and how the incident was managed, which can inform future responses.
2. Determining the Retention Period:
Balancing Act: Financial entities must strike a balance between keeping evidence long enough to be useful and avoiding excessive storage or regulatory burdens. This means they should carefully consider how long they retain such evidence.
Factors to Consider:
Criticality of the Data: If the data involved in the incident is critical to the financial entity’s operations or to security, it may need to be retained for a longer period.
Union Law Requirements: Retention periods must also comply with relevant Union laws. For example, there might be specific regulations or legal requirements that dictate how long certain types of data must be kept, particularly in relation to data protection or financial regulations.
3. Avoiding Excessive Burden:
Efficiency: While retaining evidence is essential, financial entities should avoid retaining data longer than necessary. Doing so can create unnecessary storage costs, compliance challenges, and complexity in managing data.
Regulatory Compliance: The retention period should align with legal requirements without imposing undue burdens, ensuring that financial entities meet their obligations without being overwhelmed by excessive regulatory demands.
Summary:
To enhance the detection and investigation of ICT-related incidents, financial entities should retain evidence of these incidents for a period that balances usefulness and regulatory compliance. The retention period should be determined based on the criticality of the data involved and any applicable Union laws, ensuring that evidence is kept long enough to be effective without creating unnecessary regulatory burdens.
Union Laws
Please note that in this context, "Union laws" refer to the body of laws and regulations enacted by the European Union (EU) that apply to all member states. These laws cover a wide range of areas, including data protection, financial regulation, cybersecurity, and more. Specifically, within the framework of ICT security and incident management, the term "Union laws" likely points to several key legal instruments:
General Data Protection Regulation (GDPR): This is one of the most well-known EU laws that governs the handling and protection of personal data. When financial entities retain evidence of ICT-related incidents, they must ensure that any personal data included in that evidence is handled in compliance with GDPR, including limitations on data retention and requirements for data security.
Digital Operational Resilience Act (DORA): Regulation (EU) 2022/2554, which you referred to, is also known as DORA. It specifically addresses the digital operational resilience of financial entities, including requirements for ICT risk management, incident reporting, and data retention.
NIS2 Directive (Network and Information Security Directive): This directive strengthens cybersecurity requirements across the EU, including obligations for incident reporting, risk management, and cooperation between member states on cybersecurity matters. Financial entities may need to comply with retention and reporting obligations under this directive.
Sector-Specific Regulations: Various EU laws govern specific aspects of financial services, such as the Markets in Financial Instruments Directive (MiFID II), the Payment Services Directive (PSD2), and the Anti-Money Laundering Directive (AMLD). These laws may impose additional requirements on financial entities, including how they handle and retain data related to ICT incidents.
In summary, "Union laws" in this context refer to the various EU legal frameworks that govern data protection, financial regulation, cybersecurity, and other relevant areas that financial entities must comply with when managing ICT-related incidents.
Detection of ICT-related incidents is hard and complex, therefore companies should treat any set criteria for detecting and responding to ICT-related incidents as guidelines rather than strict rules. They should remain flexible and proactive, recognizing that not all criteria need to occur simultaneously for an incident to be taken seriously.
-
TL;DR
Detection of ICT-related incidents is hard and complex, therefore companies should treat any set criteria for detecting and responding to ICT-related incidents as guidelines rather than strict rules. They should remain flexible and proactive, recognizing that not all criteria need to occur simultaneously for an incident to be taken seriously. Additionally, the importance of the affected ICT services should be factored into the response, ensuring that more critical services receive the necessary attention when incidents occur. This approach helps financial entities maintain robust incident detection and response capabilities.
FULL VERSION
This passage explains the approach financial entities should take regarding the detection and response to ICT-related incidents, emphasizing flexibility and thoroughness. Here's a breakdown of the key points:
1. Criteria for Incident Detection and Response:
Non-Exhaustive Criteria: The regulation provides specific criteria that financial entities should use to detect and respond to ICT-related incidents. However, these criteria are not exhaustive—meaning they do not cover every possible scenario. Financial entities should remain open to identifying and responding to incidents that might fall outside these predefined criteria.
Adaptability: By treating the criteria as a starting point rather than a strict list, financial entities can be more adaptable and proactive in addressing unexpected or unique incidents that might otherwise go unnoticed.
2. Flexibility in Application:
Criteria Consideration: Financial entities should consider each criterion provided by the regulation, but the circumstances described in those criteria do not need to occur simultaneously. For example, if a criterion describes multiple conditions (e.g., system slowdowns and unusual access patterns), the entity should respond even if only one of those conditions is met, rather than waiting for all conditions to occur together.
Independent Triggers: This approach allows financial entities to detect incidents early, rather than delaying action until a full set of criteria is met. It helps in maintaining a higher level of vigilance.
3. Importance of Affected ICT Services:
Contextual Consideration: When triggering incident detection and response processes, financial entities should appropriately consider the importance of the ICT services affected. Not all ICT services are equally critical, so the response should be proportional to the significance of the affected systems or data.
Prioritization: If an incident affects a crucial ICT service (such as those related to payment systems or customer data), it should trigger a more urgent and robust response compared to an incident affecting a less critical system. This prioritization helps financial entities focus their resources and attention where they are needed most.
Summary:
Financial entities should treat the criteria for detecting and responding to ICT-related incidents as guidelines rather than strict rules. They should remain flexible and proactive, recognizing that not all criteria need to occur simultaneously for an incident to be taken seriously. Additionally, the importance of the affected ICT services should be factored into the response, ensuring that more critical services receive the necessary attention when incidents occur. This approach helps financial entities maintain robust incident detection and response capabilities.
When developing an ICT business continuity policy, financial entities should incorporate key aspects of ICT risk management, including:
incident management
communication strategies
change management, and
risks from third-party providers
-
TL;DR
When developing an ICT business continuity policy, financial entities should incorporate key aspects of ICT risk management, including:
incident management
communication strategies
change management, and
risks from third-party providers
This comprehensive approach ensures that the entity is well-prepared to handle disruptions and maintain business continuity.
FULL VERSION
Companies need to create a comprehensive ICT business continuity policy that integrates key aspects of ICT risk management. Here's a breakdown of the main points:
1. ICT Business Continuity Policy:
Purpose: This policy is designed to ensure that the financial entity can continue its critical operations in the event of disruptions or incidents involving its ICT systems. It's a crucial part of maintaining digital operational resilience.
2. Essential Components to Include:
ICT Risk Management: The policy should incorporate ICT risk management practices, which involve identifying, assessing, and mitigating risks related to ICT systems. This ensures that potential threats to business continuity are properly addressed.
ICT-Related Incident Management: The policy should include strategies for handling ICT-related incidents. This involves preparing for, detecting, responding to, and recovering from incidents that could disrupt business operations.
Communication Strategies: Clear communication plans should be established as part of the policy. This ensures that all relevant stakeholders, both internal and external, are informed and coordinated during an ICT-related incident.
ICT Change Management Process: The policy should account for changes to ICT systems, as changes can introduce new risks. Properly managing these changes helps prevent disruptions and maintains system stability.
Risks from ICT Third-Party Providers: The policy should address risks associated with external ICT service providers. Since these providers can impact the financial entity's operations, it's important to include measures for managing and mitigating risks that arise from these third-party relationships.
Summary:
When developing an ICT business continuity policy, financial entities should incorporate key aspects of ICT risk management, including incident management, communication strategies, change management, and risks from third-party providers. This comprehensive approach ensures that the entity is well-prepared to handle disruptions and maintain business continuity.
Companies should develop and test scenarios for ICT disruptions to ensure robust response and recovery plans. These scenarios help prioritize resilience measures and ensure backup systems can effectively maintain operations during disruptions, ultimately restoring primary systems within the required timeframe.
-
TL;DR
Companies should develop and test scenarios for ICT disruptions to ensure robust response and recovery plans. These scenarios help prioritize resilience measures and ensure backup systems can effectively maintain operations during disruptions, ultimately restoring primary systems within the required timeframe.
FULL VERSION
DORA emphasizes the importance of financial entities preparing for various potential scenarios that could disrupt their ICT systems, particularly those regulated under Title II of the regulation. Here's a breakdown:
1. Setting Out Scenarios:
Purpose: Financial entities should establish a range of scenarios that could affect their ICT systems. These scenarios are essential for both implementing ICT response and recovery plans and testing ICT business continuity plans.
Starting Point: The scenarios provided in the regulation should serve as a starting point. Financial entities should analyze these scenarios to determine their relevance and plausibility and decide if additional or alternative scenarios are necessary.
2. Focus on Efficient and Effective Resilience Measures:
Prioritization: Financial entities should prioritize scenarios where investing in resilience measures would be most beneficial. This means focusing on situations where the impact of disruptions is high and where effective measures can prevent or minimize damage.
Investment in Resilience: By identifying key scenarios, financial entities can allocate resources more efficiently to enhance their resilience against potential disruptions.
3. Testing Switchover and Redundancy:
Testing Critical Functions: Financial entities should regularly test their ability to switch from primary ICT systems to backup systems or redundant infrastructure. This testing ensures that in the event of a disruption, the backup systems can maintain operations effectively.
Duration and Effectiveness: Tests should verify that these backup systems and facilities can operate effectively for as long as needed, ensuring continuity until the primary ICT systems are restored.
Recovery Objectives: The goal is to ensure that the transition back to the primary systems happens smoothly and within the timeframes set by the financial entity's recovery objectives.
Summary:
Financial entities should develop and test scenarios for ICT disruptions to ensure robust response and recovery plans. These scenarios help prioritize resilience measures and ensure backup systems can effectively maintain operations during disruptions, ultimately restoring primary systems within the required timeframe.
DORA emphasizes the need to establish specific requirements for managing operational risks in relation to ICT project and change management, as well as ICT business continuity management. These requirements build on existing regulations, (EU) No 648/2012, (EU) No 600/2014 and (EU) No 909/2014 of the European Parliament and of the Council
-
TL;DR
DORA emphasizes the need to establish specific requirements for managing operational risks, particularly in relation to ICT project and change management, as well as ICT business continuity management. These requirements build on existing regulations that already apply to central counterparties, central securities depositories, and trading venues, specifically:
Regulations (EU) No 648/2012
(EU) No 600/2014, and
(EU) No 909/2014 of the European Parliament and of the Council.
FULL VERSION
DORA emphasizes the need to establish specific requirements for managing operational risks, particularly in relation to ICT project and change management, as well as ICT business continuity management. These requirements build on existing regulations that already apply to central counterparties, central securities depositories, and trading venues.
Breakdown:
Operational Risk Requirements:
Purpose: The regulation aims to set clear standards for managing operational risks, which are risks that arise from internal processes, systems, or external events. These risks can affect the smooth functioning of financial entities.
Focus Areas: The focus here is on two key areas:
ICT Project and Change Management: This involves managing the risks associated with implementing new ICT projects and making changes to existing ICT systems. Proper management ensures that changes don't introduce vulnerabilities or disruptions.
ICT Business Continuity Management: This involves ensuring that the financial entity can continue operating during and after disruptions to its ICT systems. Business continuity management plans help prepare for and respond to incidents that could threaten operations.
Building on Existing Regulations:
Existing Framework: The requirements being introduced are built upon existing regulations that already apply to specific financial market infrastructures, namely:
Regulation (EU) No 648/2012: also known as the European Market Infrastructure Regulation (EMIR), is a EU legislation that addresses over-the-counter (OTC) derivatives, central counterparties (CCPs), and trade repositories.
Regulation (EU) No 600/2014: also known as the Markets in Financial Instruments Regulation (MiFIR), aims to improve the transparency and regulation of financial markets.
Regulation (EU) No 909/2014: also known as the Central Securities Depositories Regulation (CSDR), aimes at improving securities settlement and regulating central securities depositories (CSDs) in the EU.
Harmonization: By building on these existing regulations, the new requirements aim to harmonize the approach to ICT risk management across different types of financial entities, ensuring consistency and robust protections throughout the financial system.
Summary:
The regulation introduces specific requirements for managing operational risks, particularly in ICT project and change management and ICT business continuity management. These new rules build on existing regulations that apply to central counterparties, central securities depositories, and trading venues, aiming to create a consistent and effective framework for managing ICT risks across the financial sector.
-
Regulation (EU) No 648/2012, also known as the European Market Infrastructure Regulation (EMIR), is a key piece of EU legislation that addresses over-the-counter (OTC) derivatives, central counterparties (CCPs), and trade repositories. Here are the main aspects of this regulation:
Scope and Objectives
The regulation aims to:
Increase transparency in the OTC derivatives market.
Reduce systemic risk in derivatives trading.
Establish uniform requirements for CCPs and trade repositories.
Key Components
Clearing Obligation
The regulation mandates that certain OTC derivative contracts must be cleared through CCPs. This applies to financial counterparties and some non-financial counterparties that exceed specified clearing thresholds.
Risk Mitigation
For OTC derivative contracts not cleared by a CCP, the regulation requires counterparties to implement risk mitigation techniques, including:
Timely confirmation of trades
Portfolio reconciliation
Dispute resolution procedures
Portfolio compression for large portfolios
Reporting Requirements
All derivative contracts (both OTC and exchange-traded) must be reported to registered trade repositories. This reporting obligation applies to both financial and non-financial counterparties.
CCP Requirements
The regulation establishes strict organizational, conduct of business, and prudential standards for CCPs. This includes:
Authorization and supervision procedures
Capital requirements
Governance standards
Risk management practices
Trade Repositories
EMIR introduces a new type of entity called trade repositories, which centrally collect and maintain records of derivative transactions. The regulation sets out:
Registration procedures
Operational standards
Data availability requirements
Enforcement and Penalties
Member states are required to establish rules on penalties for infringements of the regulation. These penalties must be effective, proportionate, and dissuasive.
International Coordination
The regulation includes provisions to avoid duplicative or conflicting rules with third countries. It allows for the recognition of third-country CCPs and trade repositories under certain conditions.
-
Regulation (EU) No 600/2014, also known as the Markets in Financial Instruments Regulation (MiFIR), is a key piece of European Union legislation that aims to improve the transparency and regulation of financial markets. Here are the main aspects of this regulation:
Scope and Objectives
MiFIR aims to:
Enhance transparency in financial markets
Strengthen investor protection
Improve the functioning of trading venues
Increase competition in the financial services sector
Key Components
Transparency Requirements
The regulation introduces pre-trade and post-trade transparency requirements for equity and non-equity instruments. This includes:
Publication of bid and offer prices
Disclosure of the volume and price of executed trades
Trading Obligation
MiFIR mandates that certain derivatives and shares must be traded on regulated platforms, including:
Regulated markets
Multilateral Trading Facilities (MTFs)
Organised Trading Facilities (OTFs)
Transaction Reporting
The regulation expands transaction reporting requirements to cover a wider range of financial instruments. Investment firms must report detailed information about their transactions to competent authorities.
Best Execution
MiFIR strengthens the best execution framework, requiring investment firms to take all sufficient steps to obtain the best possible result for their clients when executing orders.
Product Intervention
The regulation grants powers to national competent authorities and the European Securities and Markets Authority (ESMA) to temporarily prohibit or restrict the marketing, distribution, or sale of certain financial instruments or activities.
Third-Country Firms
MiFIR establishes a harmonized regime for granting access to EU markets for firms from third countries, based on an equivalence assessment of the third country's regulatory framework.
Implementation and Enforcement
MiFIR works in conjunction with the Markets in Financial Instruments Directive II (MiFID II) to create a comprehensive regulatory framework for financial markets in the EU. National competent authorities are responsible for enforcing the regulation, with ESMA playing a coordinating role.
-
Regulation (EU) No 909/2014, also known as the Central Securities Depositories Regulation (CSDR), is a key piece of European Union legislation aimed at improving securities settlement and regulating central securities depositories (CSDs) in the EU. Here are the main aspects of this regulation:
Objectives
The regulation aims to:
Enhance the safety and efficiency of securities settlement
Harmonize settlement periods across the EU
Establish a common regulatory framework for CSDs
Key Components
Settlement Discipline
The regulation introduces measures to improve settlement discipline, including:
Mandatory buy-in procedures for failed trades
Cash penalties for settlement fails
Monitoring and reporting of settlement fails
Settlement Periods
CSDR harmonizes the settlement cycle across the EU, mandating a T+2 settlement period for transferable securities traded on trading venues.
CSD Requirements
The regulation establishes a common set of requirements for CSDs, including:
Authorization and supervision procedures
Organizational and conduct rules
Prudential standards
Risk management practices
CSD Passporting
CSDR introduces a passporting regime, allowing authorized CSDs to provide services across the EU without requiring separate authorization in each member state.
Access Rights
The regulation ensures non-discriminatory access to CSD services for market participants, issuers, and other market infrastructures.
Internalised Settlement
CSDR requires investment firms to report internalized settlements (settlements that do not take place through a securities settlement system) to competent authorities.
Implementation and Enforcement
National competent authorities are responsible for enforcing the regulation, with the European Securities and Markets Authority (ESMA) playing a coordinating role. The regulation has been implemented in phases, with some provisions coming into force later than others.
Regulation (EU) No 909/2014 has significantly reshaped the European post-trade landscape, promoting greater harmonization, efficiency, and stability in securities settlement across the EU.
Financial entities must regularly review their ICT risk management framework and report the results to regulatory authorities.
Please note that national laws and technical details regarding, for instance reporting, is still a work in progress at this point in time (August 2024).
-
TL;DR
Please note that national laws and technical details regarding, for instance reporting, is still a work in progress at this point in time (August 2024).
Financial entities must regularly review their ICT risk management framework and report the results to regulatory authorities. To ensure efficient processing, these reports must be submitted in a searchable electronic format, allowing the authorities to easily access and analyze the information.
FULL VERSION
Businesses covered by DORA are required to review their ICT (Information and Communication Technology) risk management framework and report their findings to the relevant regulatory authority. Here's a detailed explanation:
Breakdown:
Article 6(5) of Regulation (EU) 2022/2554:
Review Requirement: Financial entities are obligated to regularly review their ICT risk management framework. This framework is a structured approach to identifying, assessing, managing, and mitigating risks associated with ICT systems.
Reporting to Authorities: After conducting this review, financial entities must report their findings to their competent authority (the regulatory body responsible for overseeing their activities).
Purpose of the Report:
Information Processing: The competent authorities need to process the information in these reports efficiently. This processing includes reviewing and assessing the ICT risk management practices of financial entities to ensure they comply with the regulation and effectively manage ICT risks.
Searchable Electronic Format:
Format Requirement: To facilitate easier processing and analysis of the information by the competent authorities, financial entities are required to submit their reports in a searchable electronic format.
Why This Matters: A searchable electronic format allows the competent authorities to quickly locate specific information, filter data, and compare reports across different entities. This improves efficiency and helps ensure that the information is transmitted clearly and accurately.
Summary:
Financial entities must regularly review their ICT risk management framework and report the results to regulatory authorities. To ensure efficient processing, these reports must be submitted in a searchable electronic format, allowing the authorities to easily access and analyze the information.
REGULATORY AUTHORITIES
In Sweden, the competent authority responsible for overseeing and regulating financial entities, including the implementation of DORA, is Finansinspektionen (FI), the Swedish Financial Supervisory Authority.
Key Responsibilities of Finansinspektionen (FI) in this Context:
Supervision: FI is responsible for supervising financial institutions, including banks, insurance companies, and other financial entities, to ensure they comply with regulations like Regulation (EU) 2022/2554.
ICT Risk Management: FI would oversee the implementation of ICT risk management frameworks by financial entities and ensure that they are adequately addressing risks related to ICT systems and cybersecurity.
Reporting: Financial entities in Sweden would be required to submit their reports on ICT risk management reviews to FI, in line with the requirements of Regulation (EU) 2022/2554.
For further details or specific guidelines, financial entities should directly consult with FI or refer to the information provided on their official website.
Companies that fall under the simplified ICT risk management framework must focus on essential security areas (confidentiality, integrity, availability, authenticity of data/services). They need a clear governance structure for effective risk management. To reduce the burden, they should develop and document only one policy, an information security policy.
-
TL;DR
Companies that fall under the simplified ICT risk management framework must focus on essential security areas (confidentiality, integrity, availability, authenticity of data/services). They need a clear governance structure for effective risk management. To reduce the burden, they should develop and document only one policy, that is an information security policy, that specifies the high-level principles and rules necessary to protect the confidentiality, integrity, availability, and authenticity of data and of the services of those financial entities.
FULL VERSION
This passage outlines the specific requirements for financial entities that fall under the simplified ICT (Information and Communication Technology) risk management framework as mentioned in Article 16 of Regulation (EU) 2022/2554.
Explanation:
Simplified ICT Risk Management Framework:
Focus on Essentials: The simplified framework is tailored for smaller or less complex financial entities. The requirements focus only on the most essential areas necessary to ensure data and service security.
Key Areas of Focus: Even within a simplified framework, the core areas that must be addressed are the confidentiality, integrity, availability, and authenticity of data and services. These four elements are crucial for safeguarding the financial entity’s operations and data from threats.
Internal Governance and Control Framework:
Clear Responsibilities: The financial entity must have a clear governance structure, with well-defined responsibilities. This ensures that those in charge can effectively manage ICT risks and respond to incidents when they arise.
Effective Risk Management: Even though the entity may operate under a simplified framework, the risk management practices must still be sound and capable of addressing the unique risks the entity faces.
Reduced Administrative Burden:
Single Policy Document: To minimize the complexity and administrative load, these financial entities are required to develop and document only one policy: an information security policy.
High-Level Principles: This policy should focus on the high-level principles and rules necessary to protect data and services. It simplifies the documentation process while still ensuring that key security measures are in place.
Summary:
Financial entities under the simplified ICT risk management framework must focus on essential security areas (confidentiality, integrity, availability, authenticity of data/services). They need a clear governance structure for effective risk management. To reduce the burden, they only need to document a single information security policy covering key security principles and rules.
-
According to Article 16 of the Digital Operational Resilience Act (DORA), the following financial entities fall under the simplified ICT risk management framework:
Small and non-interconnected investment firms that meet the conditions laid out in Article 12(1) of Regulation (EU) 2019/2033.
Payment institutions exempted pursuant to Directive (EU) 2015/2366.
Institutions exempted pursuant to Directive 2013/36/EU, specifically entities referred to in Article 2(5), points (4) to (23) of that Directive, in respect of which Member States have decided not to apply the option referred to in Article 2(4) of DORA.
Electronic money institutions exempted pursuant to Directive 2009/110/EC.
Small institutions for occupational retirement provision, defined as those operating pension schemes which together have less than 100 members in total.
These entities are not required to comply with Articles 5 to 15 of DORA, which outline more comprehensive ICT risk management requirements. Instead, they must implement a simplified ICT risk management framework that includes basic measures such as:
Implementing and maintaining an ICT risk management framework
Continuously monitoring and controlling the security and functioning of ICT systems
Minimizing ICT risk impact through appropriate strategies, policies, procedures, and tools
Establishing ICT business continuity plans and disaster recovery methods
Testing ICT business continuity plans and the effectiveness of implemented ICT risk control measures
Developing ICT security awareness programs and digital operational resilience training for staff and management
The specific elements of this simplified framework will be further detailed in regulatory technical standards developed by the European Supervisory Authorities (ESAs)
This recital explains the rationale behind consolidating both the standard and simplified ICT risk management frameworks into a single legislative act under Regulation (EU) 2022/2554. Not relevant for implementation purposes.
-
TL;DR
This recital explains the rationale behind consolidating both the standard and simplified ICT risk management frameworks into a single legislative act under Regulation (EU) 2022/2554. Not relevant for implementation purposes.
FULL VERSION
This statement explains the rationale behind consolidating both the standard and simplified ICT risk management frameworks into a single legislative act under Regulation (EU) 2022/2554. Here's a breakdown:
ICT Risk Management Framework: The regulation focuses on ICT (Information and Communication Technology) risk management for financial entities. This involves setting out specific rules and procedures to protect against ICT risks, such as cyberattacks, data breaches, and system failures.
Article 15 & Article 16:
Article 15 refers to the detailed requirements for the standard ICT risk management framework that applies to most financial entities.
Article 16(1) refers to the simplified ICT risk management framework, which is designed for smaller or less complex financial entities, offering them a more streamlined set of requirements.
Coherence Between Frameworks: The regulation seeks to ensure consistency between the standard and simplified frameworks. Even though the simplified framework is less complex, it must still align with the broader principles of the standard framework to ensure a unified approach across all financial entities.
Single Legislative Act: To ensure that both frameworks (standard and simplified) are implemented in a coherent and coordinated manner, they are included in the same legislative act. This ensures that both sets of provisions take effect simultaneously and maintain consistency across the financial sector.
In summary, this approach allows the regulation to cover all financial entities, whether large or small, within a single legislative framework, ensuring that both ordinary and simplified ICT risk management standards are aligned and applied consistently. Not relevant for implementation purposes.
This recital explains the origins and collaborative development of DORA, highlighting the involvement of several key regulatory and supervisory bodies in the European Union. Not relevant for implementation purposes.
-
TL;DR
This recital explains the origins and collaborative development of DORA, highlighting the involvement of several key regulatory and supervisory bodies in the European Union. Not relevant for implementation purposes.
FULL VERSION
This statement explains the origins and collaborative development DORA, highlighting the involvement of several key regulatory and supervisory bodies in the European Union. Here's a breakdown:
Regulation's Basis: The regulation is grounded in draft regulatory technical standards. These are detailed rules and guidelines that provide technical specifications to ensure consistent application of EU laws across the financial sector.
European Supervisory Authorities (ESAs):
European Banking Authority (EBA): Focuses on banking and financial institutions.
European Insurance and Occupational Pensions Authority (EIOPA): Deals with insurance and pension-related regulations.
European Securities and Markets Authority (ESMA): Supervises securities markets and investment activities.
These three bodies are collectively known as the European Supervisory Authorities (ESAs). They are responsible for drafting the technical standards that form the basis of the regulation.
Collaboration with ENISA:
The European Union Agency for Cybersecurity (ENISA) was consulted during the drafting process. ENISA provides expertise on cybersecurity, ensuring that the regulation adequately addresses ICT (Information and Communication Technology) risks and cyber threats.
Consultative Process: The draft technical standards submitted by the ESAs are not created in isolation. Instead, they are developed through a consultative process involving input from various stakeholders, including ENISA. This collaboration ensures that the standards are robust, comprehensive, and tailored to address the specific cybersecurity needs of the financial sector.
In summary, the regulation is built upon technical standards developed by key European regulatory bodies, with input from cybersecurity experts at ENISA. This collaborative approach ensures that the regulation effectively addresses ICT risks across the financial sector in the EU.
Not relevant for implementation purposes.
This recital outlines the thorough and inclusive process followed by the Joint Committee of the European Supervisory Authorities (ESAs) to develop the regulatory technical standards that form the basis of the Regulation. Not relevant for implementation purposes.
-
TL;DR
This recital outlines the thorough and inclusive process followed by the Joint Committee of the European Supervisory Authorities (ESAs) to develop the regulatory technical standards that form the basis of the Regulation. Not relevant for implementation purposes.
FULL VERSION
This recital outlines the thorough and inclusive process followed by the Joint Committee of the European Supervisory Authorities (ESAs) to develop the regulatory technical standards that form the basis of the Regulation. Here's an explanation:
Joint Committee of the European Supervisory Authorities: This committee is a collaborative body that brings together the three European Supervisory Authorities:
EBA (European Banking Authority): Oversees banking regulations.
EIOPA (European Insurance and Occupational Pensions Authority): Focuses on insurance and pension-related regulations.
ESMA (European Securities and Markets Authority): Regulates securities markets.
The Joint Committee coordinates efforts across these authorities to ensure consistency and coherence in financial regulation.
Legal Foundations: The references to Article 54 of different regulations indicate the legal basis for the Joint Committee's actions:
Regulation (EU) No 1093/2010 for EBA
Regulation (EU) No 1094/2010 for EIOPA
Regulation (EU) No 1095/2010 for ESMA
These articles establish the Joint Committee and outline its functions, including cooperation and consultation across the different sectors.
Open Public Consultations: The draft regulatory technical standards were subjected to open public consultations. This means that stakeholders, including industry participants, consumer groups, and the general public, were invited to provide feedback on the proposed standards. This step ensures transparency and allows for input from those who will be affected by the regulations.
Cost-Benefit Analysis: The Joint Committee also analyzed the potential costs and benefits of the proposed standards. This analysis helps to ensure that the regulations are both effective and economically viable, balancing the need for robust financial regulation with the potential impact on businesses and the economy.
Stakeholder Groups: The Joint Committee sought advice from several stakeholder groups that represent different sectors of the financial industry:
Banking Stakeholder Group: Provides input on banking-related regulations.
Insurance and Reinsurance Stakeholder Group and Occupational Pensions Stakeholder Group: Offer perspectives on insurance and pension matters.
Securities and Markets Stakeholder Group: Focuses on securities and investment issues.
These groups are established under the relevant articles of the regulations governing the ESAs and provide expert advice to ensure that the technical standards are well-informed and practical.
In summary, the regulation was developed through a collaborative process involving public consultations, cost-benefit analyses, and advice from specialized stakeholder groups, all coordinated by the Joint Committee of the European Supervisory Authorities. This approach ensures that the regulatory standards are comprehensive, balanced, and reflective of the needs of the financial industry. Not relevant for implementation purposes.
Any processing of personal data required by DORA must fully comply with GDPR and related regulations. DORA also highlights the importance of the data minimization principle in ensuring appropriate incident detection.
-
TL;DR
Any processing of personal data required by DORA must fully comply with GDPR and related regulations. DORA also highlights the importance of the data minimization principle in ensuring appropriate incident detection.
FULL VERSION
This statement explains the relationship between the processing of personal data under the Act and the existing data protection regulations within the European Union. Here's a breakdown of the key points:
Processing of Personal Data: When financial entities or other parties need to process personal data to comply with the obligations set out in this Act (likely related to ICT risk management and incident reporting), they must do so in accordance with existing EU data protection laws.
Applicable Regulations:
Regulation (EU) 2016/679 (GDPR): This is the General Data Protection Regulation, which governs the protection of personal data across the EU. It sets out principles for data processing, rights for data subjects, and obligations for data controllers and processors.
Regulation (EU) 2018/1725: This regulation applies specifically to EU institutions and bodies and aligns with the GDPR, ensuring that personal data handled by these institutions is protected similarly to data processed in the private sector.
Data Minimisation Principle: This principle, which is part of the GDPR, requires that only the minimum amount of personal data necessary for a specific purpose should be collected and processed. In the context of this Act, it means that when collecting personal data for purposes like incident detection, financial entities should only collect data that is essential for that purpose, avoiding unnecessary or excessive data collection.
Consultation with the European Data Protection Supervisor (EDPS): The EDPS is the EU’s independent data protection authority. The statement notes that the EDPS was consulted on the draft text of this Act, indicating that the potential impact on data protection was carefully considered during the drafting process. This consultation helps ensure that the Act aligns with data protection laws and respects individuals' privacy rights.
In summary, this statement emphasizes that any processing of personal data required by DORA must fully comply with the GDPR and related regulations. It also highlights the importance of the data minimization principle in ensuring appropriate incident detection and notes that the EDPS was involved in reviewing the Act to ensure it aligns with EU data protection standards.
Disclaimer
Please note that this text is provided as-is and should not be relied upon as an authoritative source. Please consult the Official Journal of the European Union for the official DORA documentation.
