# What Is DORA? Digital Operational Resilience, Cyber Security and DORA Compliance Guide for Financial Entities **URL:** https://securesys.com.tr/en/learning/cyber-security-compliance-advisory/what-is-dora-compliance-and-digital-operational-resilience ![What Is DORA? Digital Operational Resilience, Cyber Security and DORA Compliance Guide for Financial Entities](/images/bilgi-merkezi/covers/cover-uyum-11.webp) ### What Is DORA? **DORA (Digital Operational Resilience Act) is a European Union regulation created to strengthen digital operational resilience in the EU financial sector and to govern how financial entities manage risks arising from information and communication technology (ICT).** The official name of DORA is **Regulation (EU) 2022/2554**, and the regulation has applied since 17 January 2025. DORA aims not only to protect financial entities against cyber attacks, but also to ensure that they can keep their critical services running during serious technology disruptions and security incidents, manage those incidents, and recover their operations securely. The regulation focuses on five core areas: - ICT risk management - Management, classification and reporting of ICT-related incidents - Digital operational resilience testing - ICT third-party risk management - Sharing of cyber threat information **Short answer:** DORA compliance means that a financial entity identifies its critical digital services, manages its ICT risks, develops its incident response and recovery capabilities, carries out appropriate resilience testing, and manages its technology suppliers in a controlled manner. ### \1. Why Was DORA Created? The financial sector is one of the sectors most dependent on information technology. Banking transactions, payment systems, digital customer services, investment platforms and insurance applications run largely on digital infrastructure. A serious outage in this infrastructure can affect not only the financial entity concerned, but also its customers, its business partners and other participants in the financial system. #### Main risks addressed by DORA - Ransomware attacks - Outages of critical applications - Failures originating from a cloud service provider - Identity and access management vulnerabilities - Supply chain attacks - Corruption of data integrity - Payment systems becoming unavailable - Insufficient disaster recovery capacity - Concentration risk in critical ICT services #### Example The transaction platform of a payment institution became unavailable because of a cyber attack. Even if the institution manages to stop the attack, if it cannot restart the payment service within an acceptable time, there may be a significant shortcoming in terms of operational resilience. DORA is concerned with **keeping the service running and recovering it** as much as with preventing the security incident. ### \2. When Did DORA Enter into Force? DORA was adopted in 2022 and entered into force on 17 January 2023. **The date of application is 17 January 2025.** DORA is an EU regulation. In this respect it differs from a directive such as NIS2. EU regulations apply directly in the Member States within the framework of their applicability conditions. However, the duties of competent authorities, supervisory processes and certain administrative matters are assessed together with the relevant national legislation. #### An important distinction Technical security measures alone are not enough for DORA to be implemented. The entity's legal scope, type of financial activity, regulatory authority and the relevant secondary legislation must be examined together. ### \3. Which Financial Entities Does DORA Cover? The scope of DORA is determined by the categories of financial entities defined in Article 2 of the regulation. #### Examples of entities in scope Banks and credit institutions. Payment institutions. Electronic money institutions. Investment firms. Crypto-asset service providers. Central counterparties. Central securities depositories. Trade repositories. Fund management companies. Insurance and reinsurance undertakings. Insurance and reinsurance intermediaries that meet the relevant scope conditions. Credit rating agencies. Crowdfunding service providers. Other relevant categories of financial entities. #### Critical point The fact that an organisation operates in the financial sector does not, on its own, mean that it falls within the scope of DORA. The entity definitions, exemptions and proportionality provisions in the regulation must be taken into account. ### \4. Does DORA Affect Financial Institutions in Türkiye? Türkiye is not a member of the European Union. For this reason, it cannot be said that DORA applies directly to all financial institutions in Türkiye. However, organisations in Türkiye may be affected by DORA in different ways. #### Scenario 1: A financial entity in the EU A Türkiye-based group may have a financial subsidiary in the EU that falls within the scope of DORA. In that case, the obligations of the EU entity concerned must be assessed. #### Scenario 2: Providing services to an EU financial entity A technology company in Türkiye may provide critical software or a managed ICT service to a bank in the EU. The bank may reflect the supplier risk management requirements under DORA in its contract. #### Scenario 3: Cloud and data centre services Technology suppliers that serve EU financial entities may encounter contractual security and resilience requirements. #### Scenario 4: International financial groups In multinational organisations, group security policies may be updated in line with DORA requirements. **Important:** Under DORA, the obligations of a financial entity are not the same as the contractual obligations of an ICT supplier or the obligations it has under the special oversight framework. ### \5. The Five Core Components of DORA | Component | Core objective | | --- | --- | | ICT Risk Management | Systematic management of digital infrastructure risks | | Incident Management and Reporting | Classification and reporting of serious incidents | | Operational Resilience Testing | Verification of security and recovery capabilities | | Third-Party Risk Management | Control of technology suppliers | | Information Sharing | Sharing of cyber threat information through appropriate mechanisms | These components should not be treated as independent workstreams. For example, a payment application identified as critical as a result of a risk analysis may influence the prioritisation of resilience testing and disaster recovery plans. ### \6. What Is DORA ICT Risk Management? ICT risk management enables an organisation to identify and assess the risks arising from its technology infrastructure and to manage them with appropriate controls. Chapter II of DORA focuses on this subject. #### Core activities Identification of critical business functions. ICT asset inventory. Assessment of system dependencies. Threat analysis. Vulnerability management. Access control. Incident detection. Response and recovery. Continuous improvement. #### Example A bank's mobile banking application may depend on the authentication infrastructure, the database and a third-party SMS service. Each of these dependencies must be included in the operational risk assessment. ### \7. Responsibility of the Management Body under DORA DORA links ultimate responsibility for ICT risk management to the management body of the financial entity. #### Topics management should consider The ICT risk management framework. The digital operational resilience strategy. Risk tolerance. Critical services. Business continuity. Supplier risks. Security investments. Audit findings. #### Example A financial entity's disaster recovery infrastructure does not meet the target recovery time for critical services. If an investment decision is needed to remove this risk, the matter must be considered at the appropriate management level. #### Critical point ICT security can be provided operationally by external parties. However, the regulatory responsibility of the financial entity cannot be eliminated simply by transferring it to the service provider. ### \8. Critical and Important Functions under DORA In DORA, identifying critical or important functions forms the basis of many risk management and supplier obligations. #### Assessment criteria The financial impact of a disruption to the function. Impact on customer services. Impact on regulatory obligations. Operational dependencies. Capacity to deliver the service through alternatives. #### Example functions Payment transactions. Customer account access. Processing of financial transactions. Critical risk management systems. Regulatory reporting. #### Important point Not all IT systems automatically have the same level of criticality. The identification of a critical or important function should be carried out in line with the relevant DORA provisions and the organisation's activities. ### \9. How Is a DORA ICT Asset Inventory Prepared? The starting point of effective risk management is knowing which systems and dependencies are in use. #### Inventory scope Physical servers. Virtual machines. Cloud services. Databases. Network devices. Security systems. Applications. API services. Third-party connections. Backup systems. #### Sample inventory | Asset | Business function | Criticality | Owner | | --- | --- | --- | --- | | Payment API | Payment transactions | Critical | Application team | | Authentication | Customer access | Critical | IAM team | | Reporting system | Management reports | Medium | IT operations | | Backup platform | Recovery | Critical | Infrastructure team | #### Critical point An asset inventory should not be merely a list of devices. The relationship of the assets to business functions must also be identified. ### \10. How Is a DORA Risk Analysis Carried Out? A risk analysis should assess the organisation's technology-driven threats and their impact on business processes. #### Step 1: Critical functions Which services are the priority? #### Step 2: Technology dependencies Which systems and providers are required? #### Step 3: Threats Ransomware. Service disruption. Unauthorised access. Corruption of data integrity. Supplier-originated incidents. #### Step 4: Impact Financial loss. Service disruption. Customer impact. Regulatory consequences. #### Step 5: Risk treatment Preventive controls. Detection controls. Response. Recovery. #### Example **Risk:** Compromise of an administrator account that has access to the payment system. **Potential impact:** Unauthorised transactions or service disruption. **Controls:** MFA, PAM, access monitoring, segregation of duties and an incident response plan. ### \11. What Is DORA Incident Management? DORA requires the establishment of processes for managing ICT-related incidents. #### Incident management lifecycle Preparation. Detection. Recording. Classification. Response. Communication. Recovery. Root cause analysis. #### Example Unexpected transaction errors are observed in a financial application. The initial investigation indicates that the problem may be related to malicious activity. The incident management team must carry out both a cyber security assessment and an operational impact assessment. #### Important point Not every technical error or security alert is a major ICT incident under DORA. Classification criteria must be applied separately. ### \12. How Is a Major ICT Incident Determined under DORA? Under DORA, ICT-related incidents are classified according to the criteria defined in the relevant technical standards. #### Areas assessed Affected customers. Number of transactions. Transaction value. Service disruption. Incident duration. Geographical spread. Data loss. Economic impact. Impact on critical services. #### Example A prolonged outage occurred in the transaction infrastructure of a payment institution. A large number of customers and a significant volume of transactions were affected. The institution must assess, according to the relevant classification criteria, whether the incident is a major ICT incident. ### \13. What Are the DORA Incident Reporting Deadlines? Under DORA, there is a staged reporting mechanism for major ICT incidents. According to the relevant technical standards that began to apply in 2025, the general reporting framework is as follows: | Report | General timing | | --- | --- | | Initial notification | As early as possible after classification as a major incident, and at the latest within 4 hours; in addition, it must not exceed 24 hours from the moment the entity became aware of the incident | | Intermediate report | At the latest 72 hours after the initial notification | | Final report | At the latest 1 month after the submission of the intermediate report | #### Important clarification For reporting timelines, becoming aware of the incident and classifying it as a major incident are different starting points. For weekends, public holidays and special arrangements for certain entities, the relevant technical rules and the rules of the competent authority must be taken into account. **DORA reporting deadlines should not be confused with the general 24–72 hour reporting mechanism of NIS2.** ### \14. Incident Reporting Procedure for DORA Organisations should establish a clear procedure for identifying and reporting major ICT incidents. #### Contents of the procedure Definition of an incident. Classification criteria. Responsible teams. Competent authority. Reporting channel. Timing. Internal escalation. Customer communication. Evidence management. #### Sample responsibility matrix | Task | Example owner | | --- | --- | | Incident detection | SOC | | Technical analysis | Incident response team | | Business impact assessment | Business unit | | Regulatory classification | Risk and compliance | | Approval of the notification | Authorised management | | Technical recovery | IT operations | #### Critical point Defining responsibilities in advance can reduce decision delays during a critical incident. ### \15. DORA and SOC Services A SOC supports financial entities in detecting security incidents and carrying out response processes. #### SOC capabilities 24/7 security monitoring. SIEM correlation. EDR/XDR alerts. Threat intelligence. Incident prioritisation. Response coordination. Security reporting. #### Example An unusual data transfer was detected in a bank's critical application. The SOC team verifies the incident. Coordination is established with the relevant technical teams. The necessary information is passed on to the risk and compliance teams. #### Important point DORA is not a general provision that obliges every financial entity to purchase a particular commercial SOC service. The necessary security capabilities should be established within the framework of the organisation's risks and the obligations that apply to it. ### \16. DORA and the Use of SIEM A SIEM enables security events from different systems to be collected and correlated. #### Sample log sources in financial entities Payment applications. Authentication systems. Firewall. VPN. Databases. API gateway. Cloud platforms. EDR. PAM. #### Sample use case scenario A privileged user accessed the critical payment system at unusual hours. Subsequently, a privilege change and a high-volume data transfer took place. If appropriate rules have been defined, the SIEM can correlate these activities. #### Critical point Log collection, monitoring and incident response processes should be considered together. ### \17. DORA Digital Operational Resilience Testing Chapter IV of DORA focuses on digital operational resilience testing. The aim is to verify the resilience of the organisation's ICT systems and controls. #### Examples of test types Vulnerability assessments. Network security assessments. Security vulnerability scans. Source code reviews. Scenario-based tests. Compatibility tests. Performance tests. End-to-end tests. Penetration tests. #### Important point The testing programme should be planned according to the organisation's risks, size and activities. It should not be assumed that all organisations must perform the same tests with the same frequency. ### \18. Penetration Testing under DORA Penetration tests enable the security vulnerabilities in a financial entity's systems to be assessed in a controlled manner. #### Test areas Web applications. Mobile banking. API. Internal network. External network. Active Directory. Cloud systems. Wireless networks. #### Example An API authorisation vulnerability was identified in a payment application. The finding is recorded. A risk assessment is carried out. The remediation is applied. A retest is performed. #### Critical point A penetration test alone does not mean that the entire DORA resilience testing programme has been satisfied. ### \19. What Is DORA TLPT? **TLPT (Threat-Led Penetration Testing) is an advanced testing approach that aims to assess, on the basis of realistic threat intelligence, the resilience of live production systems that support critical or important functions.** Unlike classic penetration tests, TLPT is carried out with scenarios that take into account the tactics and operational objectives of specific threat actors. #### TLPT components Threat intelligence. Identification of critical functions. Test scope. Realistic attack scenarios. Red Team activities. Blue Team detection and response. Evaluation of test results. Remediation plan. #### Critical point Under DORA, the TLPT obligation does not automatically apply to all financial entities. It applies to the entities designated by the relevant competent authority. ### \20. The Difference Between DORA TLPT and a Classic Penetration Test | Criterion | Classic Penetration Test | TLPT | | --- | --- | --- | | Focus | Identification of security vulnerabilities | Resilience against realistic attacks | | Approach | Technical test scenarios | Scenarios driven by threat intelligence | | Scope | Defined systems | Systems supporting critical or important functions | | Test environment | Authorised test environments | Live production systems under controlled conditions | | Blue Team | May not always be a central element | Detection and response capability is important | | Outcome | Vulnerability report | Operational resilience and remediation outputs | #### Important point Not every Red Team exercise automatically satisfies DORA TLPT requirements. TLPT must be carried out in accordance with the relevant regulatory and methodological requirements. ### \21. The Relationship Between DORA TLPT and TIBER-EU TIBER-EU is a threat intelligence-based ethical Red Team testing framework developed by the European Central Bank. There is a strong methodological relationship between the TLPT requirements under DORA and the TIBER-EU approach. #### Common elements Threat intelligence. Realistic attack scenarios. Critical functions. Controlled test execution. Red Team and Blue Team assessment. Remediation plan. #### Critical point Using the TIBER-EU approach does not mean that the relevant DORA TLPT obligations are automatically fulfilled. The requirements of the competent authority and the relevant technical standards must be taken into account. ### \22. How Is a DORA TLPT Process Planned? #### Phase 1: Scoping Critical or important functions are identified. Supporting systems are assessed. Test boundaries are defined. #### Phase 2: Threat Intelligence Realistic threat actors are examined. Attack scenarios are developed. Objectives are set. #### Phase 3: Red Team Testing Authorised attack scenarios are executed. Security controls are assessed. Operational risks are managed. #### Phase 4: Blue Team Assessment Detection capabilities are examined. Alerting processes are assessed. Response capability is analysed. #### Phase 5: Results and Remediation Findings are validated. Root causes are evaluated. Corrective actions are planned. #### Important point Because TLPT exercises can create operational risk on live systems, they must be carried out with dedicated governance, authorisation and risk control mechanisms. ### \23. Qualities Sought in DORA TLPT Test Providers The competence of TLPT service providers is important. #### Assessment topics Red Team experience. Threat intelligence competence. Financial sector experience. Technical expertise. Independence. Confidentiality. Test safety. Reporting quality. #### Important point DORA and the relevant technical standards contain specific conditions for test providers. The selection of a service provider should be made taking these conditions into account. ### \24. DORA and Third-Party ICT Risk Management Financial entities may obtain many critical services from external sources. #### Sample providers Cloud providers. Data centres. Software vendors. Managed service providers. SOC/MDR providers. Network service providers. Payment infrastructure suppliers. #### Core risks Service disruption. Data security. Unauthorised access. Supplier dependency. Subcontractor risks. Difficulties in terminating the service. #### Critical point DORA does not limit third-party ICT risk management to preparing a supplier contract. The supplier must be assessed throughout the service lifecycle. ### \25. What Should DORA ICT Service Contracts Contain? Article 30 of DORA sets out certain elements that must be included in contracts for ICT services. #### Topics to be assessed Service description. Service levels. Data processing and storage locations. Security requirements. Incident support. Business continuity. Service termination. Return of data. Audit rights. Subcontractors. #### Example A bank outsources the cloud infrastructure of its critical payment application. The contract must explicitly address service continuity, data security, audit rights and the exit strategy. #### Critical point There are additional contractual requirements for ICT services that support critical or important functions. ### \26. What Is the DORA Register of Information? Under DORA, financial entities are required to track their contractual arrangements with ICT third-party service providers in a specific information register. This register is generally referred to as the **Register of Information**. #### Information the register may contain Service provider. Type of service. Contract details. Supported business functions. Criticality. Subcontractor relationships. Relevant locations. #### Example | Provider | Service | Function | Criticality | | --- | --- | --- | --- | | Cloud provider | Application hosting | Payment system | Critical | | SOC provider | Security monitoring | Incident detection | High | | Software supplier | Application support | Customer portal | High | #### Important point For the Register of Information, the data structure and reporting requirements defined in the relevant technical standards must be taken into account. ### \27. Critical ICT Third-Party Providers under DORA DORA contains provisions for designating certain ICT third-party service providers as critical and subjecting them to a special oversight mechanism. #### Assessment areas Importance of the service to the financial sector. Systemic impact. Provider concentration. Availability of alternative providers. Critical function dependencies. #### Critical point A financial entity defining a supplier as critical in its own internal assessment and DORA designating it as a critical ICT third-party provider within the European oversight framework are different concepts. ### \28. DORA and Cloud Services Cloud infrastructure provides significant operational benefits for financial entities. However, the use of cloud can create new dependencies. #### Assessment areas Data security. Identity management. Logging. Backup. Service continuity. Supplier concentration. Exit strategy. #### Example A financial entity's critical applications run in a single cloud region. How the service would be maintained in the event of a regional outage must be assessed. #### Important point Using the cloud does not remove the organisation's own risk management and operational resilience responsibilities. ### \29. DORA and Business Continuity DORA requires financial entities to establish ICT business continuity and recovery processes. #### Core components Business impact analysis. Identification of critical functions. ICT continuity policies. Disaster recovery plans. Backup. Crisis management. Exercises. #### RTO and RPO **RTO:** The target time for the service to be restored. **RPO:** The target for acceptable data loss. #### Example The database that carries out a bank's customer transactions became unavailable. The recovery plan must support the secure restoration of the service within the target time. ### \30. DORA and Disaster Recovery Testing It is not enough for disaster recovery plans merely to be prepared. Their feasibility must be tested. #### Sample tests Restoring from backup. Failover to an alternative data centre. Critical application recovery. Network connectivity recovery. Authentication service recovery. #### Test results Actual recovery time achieved. Data integrity. Failed steps. Improvement needs. #### Critical point Tests should assess not only whether technical systems come back up, but also the availability of critical business functions. ### \31. The Relationship Between DORA and ISO/IEC 27001 ISO/IEC 27001 focuses on the information security management system. DORA, on the other hand, introduces regulatory obligations for digital operational resilience in the financial sector. | Topic | ISO 27001 | DORA | | --- | --- | --- | | Core objective | Information security management | Digital operational resilience | | Risk management | ISMS (Information Security Management System) risks | ICT risks and financial operations | | Incident management | Information security incidents | ICT incidents and regulatory reporting | | Testing | Risk-based verification | Resilience testing programme and TLPT for certain entities | | Supplier security | Supplier controls | Detailed ICT third-party requirements | | Certification | Certification is possible | There is no general DORA certificate requirement | #### Critical point An ISO 27001 certificate is not automatic proof of DORA compliance. DORA-specific obligations must be assessed separately. ### \32. The Difference Between DORA and NIS2 DORA and NIS2 focus on different regulatory areas. #### DORA Digital operational resilience of financial entities. #### NIS2 Cyber security resilience of organisations in certain critical and important sectors. #### Common areas Risk management. Incident management. Business continuity. Supplier security. Management responsibility. #### Important point For financial entities, the relationship between DORA and NIS2 as a matter of specific regulation should be assessed within the framework of the relevant EU legislation and national implementation. It should not be assumed that all obligations of both regulations will automatically apply together. ### \33. The Difference Between DORA and PCI DSS PCI DSS is a standard for the security of payment card data. DORA, on the other hand, focuses on the digital operational resilience of financial entities. #### PCI DSS Protection of card data. Access control. Secure network. Security testing. #### DORA ICT risk management. Incident reporting. Operational resilience testing. Supplier risk management. #### Critical point PCI DSS compliance does not satisfy all the requirements of DORA. ### \34. DORA and Source Code Security Security vulnerabilities in the critical software of financial entities can create operational risk. #### Assessment methods SAST. DAST. SCA. Manual code review. API security testing. #### Example The authorisation check in a payment application may have been implemented incorrectly. Source code review and application security testing help to identify such risks. #### Important point Source code analysis is one component of a broader ICT risk management and secure development programme. ### \35. DORA and Red Team Services Red Team exercises aim to assess an organisation's defensive capabilities against realistic attack scenarios. #### Assessment areas Initial access. Identity security. Network segmentation. Privileged access. Security monitoring. Incident response. #### Example In an authorised Red Team exercise, a controlled attack scenario aimed at gaining access to a critical system is carried out. The defence team's detection and response performance is assessed. #### Critical point General Red Team experience alone may not be sufficient for DORA TLPT exercises. The relevant regulatory requirements must be met separately. ### \36. How Is a DORA Gap Analysis Carried Out? A gap analysis compares an organisation's current ICT risk management and resilience practices with DORA requirements. #### Step 1: Scope Type of entity. Competent authority. Applicable provisions. #### Step 2: Current state Risk management. Incident management. Business continuity. Testing. Supplier security. #### Step 3: Gap analysis Missing processes. Insufficient controls. Evidence gaps. #### Step 4: Action plan Owners. Priorities. Target dates. Verification methods. ### \37. Documents That Can Be Prepared for DORA Compliance #### Management ICT risk management policy. Digital operational resilience strategy. Management decision records. #### Risk management Critical function inventory. ICT asset inventory. Risk assessment reports. Risk treatment plan. #### Incident management Incident response procedure. Incident classification matrix. Reporting procedure. Incident records. #### Business continuity Business impact analysis. ICT business continuity plan. Disaster recovery plan. Test reports. #### Third-party management Supplier inventory. Register of Information. Contract assessments. Supplier risk reports. #### Testing Resilience testing plan. Penetration test reports. TLPT documents (if applicable). Corrective action records. ### \38. A Sample 120-Day Compliance Roadmap for DORA #### Days 1–20: Scope and Gap Analysis The organisation's regulatory scope is determined. Existing processes are assessed. Critical functions are defined. A gap report is prepared. #### Days 21–45: Risk Management The ICT asset inventory is updated. A risk assessment is carried out. Priority controls are identified. #### Days 46–70: Incident and Business Continuity An incident classification procedure is prepared. A reporting workflow is established. Business continuity plans are assessed. #### Days 71–95: Testing and Supplier Management Security tests are carried out. Critical suppliers are assessed. The Register of Information is prepared or updated. #### Days 96–120: Validation An internal assessment is carried out. Corrective actions are planned. A management report is prepared. #### Important clarification The 120-day plan is a sample implementation approach. It is not a guarantee that the organisation will complete all its DORA obligations within this period. Special exercises such as TLPT must be planned separately. ### \39. DORA Compliance Checklist #### Scope - Has the organisation's DORA scope been assessed? - Has the competent authority been identified? - Has the applicable secondary legislation been reviewed? #### Governance - Has an ICT risk management framework been established? - Have management responsibilities been defined? - Has the digital operational resilience strategy been assessed? #### Risk management - Have critical or important functions been identified? - Has the ICT asset inventory been prepared? - Have technology dependencies been assessed? - Have risk treatment plans been created? #### Incident management - Have incident classification criteria been defined? - Has a major incident reporting procedure been prepared? - Have SOC and response processes been assessed? #### Testing - Has a resilience testing programme been established? - Have security tests been planned? - Has the applicability of TLPT been assessed? - Are test findings being tracked? #### Business continuity - Is there an ICT business continuity plan? - Are disaster recovery tests being carried out? - Is the restoration of critical services being verified? #### Third-party management - Have ICT suppliers been identified? - Have contracts been assessed? - Has the Register of Information been prepared? - Have exit strategies been established? ### \40. SECURESYS DORA Consulting and Technical Security Services SECURESYS provides technical consulting and assessment services that help financial entities improve their digital operational resilience and cyber security processes. #### DORA Technical Gap Analysis Existing ICT risk management and security controls are assessed. #### ICT Risk Management Critical systems, technology dependencies and cyber security risks are analysed. #### SOC and SIEM Services Security event monitoring, detection and response processes can be supported. #### Penetration Tests Security assessments of web, mobile, API, network and other relevant systems can be carried out. #### Red Team and TLPT Preparation Threat intelligence-driven test scenarios and defence assessments can be planned. Where a regulatory TLPT service under DORA is involved, the conditions that apply to the relevant test provider must be verified separately. #### Source Code Security Secure development processes for critical financial applications can be supported. #### Supplier Security The technical security risks of ICT service providers can be assessed. #### Business Continuity and Recovery The recovery capabilities and resilience testing of critical systems can be supported. #### Mapping ISO 27001 to DORA Existing information security management system controls can be mapped to DORA's technical requirements. **In the SECURESYS approach, the aim of DORA consulting is not merely to prepare documentation; it is to build a tested and sustainable operational resilience structure that protects the critical digital services of financial entities.** Legal scope and regulatory interpretations should be assessed together with experts competent in the legislation of the country concerned. #### Frequently Asked Questions (FAQ) #### \1. What is DORA? DORA is the European Union regulation governing digital operational resilience in the EU financial sector. #### \2. When did DORA start to apply? It started to apply on 17 January 2025. #### \3. Which entities does DORA cover? It covers banks, payment institutions, certain insurance and investment firms, and the other financial entities defined in the regulation. #### \4. Is DORA mandatory for companies in Türkiye? It is not a general direct obligation for all companies in Türkiye. EU activities and supplier relationships must be assessed separately. #### \5. What is DORA consulting? It is consulting activity aimed at helping financial entities improve their ICT risk management, incident management, testing and supplier security processes. #### \6. Is ISO 27001 mandatory for DORA? DORA does not set an ISO 27001 certificate as a general requirement for all organisations. #### \7. Is a SOC mandatory for DORA? Purchasing a particular commercial SOC service is not a general requirement. Appropriate security monitoring and response capabilities are needed. #### \8. What is DORA TLPT? It is an advanced testing approach that assesses operational resilience through threat intelligence-based, realistic attack scenarios. #### \9. Is TLPT mandatory for all financial entities? No. It applies to the entities designated by the relevant competent authority. #### \10. Should penetration testing be carried out under DORA? Risk-based security tests should be planned as part of the resilience testing programme. The types of tests are determined according to the organisation's obligations. #### \11. What is the DORA incident reporting deadline in hours? For major ICT incidents, there are specific rules for the initial notification, such as a limit of 4 hours from classification and 24 hours from becoming aware of the incident. #### \12. Are DORA and NIS2 the same? No. DORA focuses on the digital operational resilience of the financial sector, while NIS2 focuses on the cyber security of certain critical and important sectors. #### \13. Are DORA and ISO 27001 the same? No. ISO 27001 is a management system standard, whereas DORA is a regulatory EU regulation. #### \14. Does DORA cover supplier security? Yes. ICT third-party risk management is one of the core components of DORA. #### \15. What is the Register of Information? It is the information register in which contractual arrangements with ICT third-party service providers are tracked in a specific structure. #### \16. Does DORA require Red Team testing? There is a TLPT obligation for certain entities. General testing requirements are assessed according to the organisation's scope. #### \17. Is disaster recovery testing required for DORA? DORA contains requirements for the appropriate testing of ICT business continuity and recovery capabilities. #### \18. How long does DORA compliance take? It varies according to the organisation's size, activities, current maturity and applicable obligations. #### \19. Is there a DORA certificate? DORA does not create a single general certificate requirement for all financial entities. #### \20. What should be considered when choosing a DORA consulting firm? Financial sector experience, knowledge of ICT risk management, cyber security testing competence, operational resilience experience and the capacity to understand regulatory requirements should be assessed. ### Conclusion: Why Is DORA Important for Financial Entities? DORA is an important regulation that addresses cyber security and operational resilience in the financial sector in an integrated way. Organisations should first determine the obligations that apply to them. They should define their critical or important functions. They should assess their ICT assets and dependencies. They should establish a risk management framework. They should improve their security incident detection and response processes. They should set up a reporting mechanism for major ICT incidents. They should establish a resilience testing programme. Where applicable, they should meet TLPT requirements. They should manage third-party ICT service providers. They should validate their business continuity and disaster recovery capabilities. **The core value of DORA compliance is not merely preventing cyber attacks; it is enabling financial entities to keep their critical services running in the face of serious technology incidents and to recover securely.** ### Official Sources and References **DORA – Regulation (EU) 2022/2554:** https://eur-lex.europa.eu/eli/reg/2022/2554/oj **European Banking Authority (EBA):** https://www.eba.europa.eu **European Securities and Markets Authority (ESMA):** https://www.esma.europa.eu **European Insurance and Occupational Pensions Authority (EIOPA):** https://www.eiopa.europa.eu **European Central Bank – TIBER-EU:** https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html **European Commission – Digital Operational Resilience:** https://finance.ec.europa.eu/digital-finance/digital-operational-resilience-act-dora_en