Corporate Cybersecurity Legal Obligations in Türkiye and the EU: 2026 Compliance Guide

Legal position last verified: 26 August 2026.

Corporate cybersecurity legal obligations in Türkiye arise principally from Law No 7545 on Cybersecurity, Law No 6698 on the Protection of Personal Data (“KVKK”), the Turkish Commercial Code and sector-specific rules. In the European Union, the applicable framework may include the NIS2 Directive, the General Data Protection Regulation (“GDPR”), the Digital Operational Resilience Act (“DORA”) for financial entities and the Cyber Resilience Act (“CRA”) for products with digital elements. The exact obligations depend on the company’s sector, size, countries of operation, data and products or services.¹

The first hour of a ransomware incident may look like an operational matter for the security team. Within the same day, however, the event can engage personal data breach notification, continuity of critical services, customer contracts, supplier escalation, cyber insurance, management oversight and several regulatory reporting channels. Corporate cybersecurity law is therefore not captured by the statement, “A breach must be reported within 72 hours.”

For accuracy, this study uses “Europe” principally to mean EU law and, where relevant, the EEA framework. The United Kingdom, Switzerland and other European jurisdictions require separate national analysis. NIS2 is also a directive: exact registration duties, competent authorities, sanctions and management liability must be checked in the implementing law of the relevant Member State.

The company-level conclusion: Legal cyber readiness is not a notification drafted after the attack. Before an incident, the organisation needs an applicability matrix, critical-asset map, decision authority, supplier obligations, evidence-preservation process and a mechanism for running several reporting clocks without confusing them.

Corporate legal overview

1. The first legal error: assuming one cybersecurity law applies to every company

An organisation’s cyber obligations are built in four layers:

1. General cyber layer: Law No 7545 in Türkiye; NIS2 national implementation in the EU, depending on sector and size.
2. Personal data layer: the KVKK in Türkiye; the GDPR where its territorial scope is engaged.
3. Sector layer: financial services, payments, electronic communications, energy, health, transport, digital infrastructure and other regulated critical services.
4. Product and contract layer: the CRA for products with digital elements placed on the EU market, together with customer contracts, cloud terms, financing documents and insurance policies.

One event may fall within several layers. An attack affecting the cloud provider of a payment institution may constitute:

• a cyber incident under Law No 7545;
• a KVKK or GDPR personal data breach if customer data is affected;
• a DORA ICT-related incident for an EU financial entity;
• a NIS2 significant incident for an entity or service within national scope; and
• an Article 14 CRA event for the product manufacturer if an actively exploited vulnerability is involved.

The thresholds, addressees, content requirements and trigger times are not identical.

Corporate legal applicability card

Maintain one page for each legal entity showing:

• business activity and revenue model;
• countries in which services are provided;
• headcount, turnover and balance-sheet information;
• critical services and maximum tolerable outage;
• personal data categories and controller/processor roles;
• potential NIS2 Annex I or Annex II sector;
• DORA financial-entity status;
• products with digital elements placed on the EU market and operator role;
• registration and competent authority by country;
• notification channels and local contact people;
• contractual customer-notice periods;
• insurer and law-enforcement conditions.

2. Türkiye’s Law No 7545: what the broad framework means in practice

Law No 7545 entered into force upon publication in the Official Gazette on 19 March 2025. Its scope covers public bodies, professional organisations and natural or legal persons that are present, active or provide services in cyberspace.¹² Turkish scholarship describes the statute as the first overarching law to move the country’s previously dispersed cybersecurity architecture into a central institutional framework.¹³

A broad scope does not mean that every detailed technical obligation applies identically to every company. The Cybersecurity Presidency may classify persons and entities within the Act and create provisions applying only to defined groups or activities. Critical-infrastructure status, sector rules and secondary measures are therefore decisive.

2.1 Core duties of companies

Article 7 identifies duties for persons and entities within the Act that use information systems to provide services, collect or process data or perform similar activities. They include:¹⁴

• providing, as a priority and on time, data, information, documents, hardware, software and other assistance requested by the Presidency within its duties;
• implementing cybersecurity measures required by applicable law;
• notifying the Presidency without delay of vulnerabilities or cyber incidents detected in the field in which services are provided;
• complying with the Presidency’s policies, strategies, action plans and other regulatory measures;
• where applicable, following authorised procurement rules for cybersecurity products and services used by public bodies and critical infrastructures; and
• obtaining the required approval before commencing activity where the business is subject to cybersecurity certification, authorisation or licensing.

“Without delay” is not a fixed number of hours. A company should not wait for the technical investigation to be complete. It needs a process capable of sending an initial notification based on available information and updating it as facts develop, while checking the current secondary rules and official reporting channel.

2.2 Audit readiness is part of incident readiness

The Presidency may inspect acts and operations within the scope of the law, directly, on site or through authorised auditors. Inspectors may examine electronic data, documents, infrastructure, devices, software and hardware; take copies or samples; and request written or oral explanations. An inspected company must keep the relevant systems open and operational for examination and provide the necessary infrastructure within the stated period.¹⁵

This requires three forms of advance preparation:

1. Regulatory interface: who represents legal, information security and management during an inspection;
2. Evidence and secrecy management: where records are kept, how integrity is shown, and how personal data and trade secrets are identified;
3. Request log: who approved each disclosure, what copy was supplied and how chain of custody was maintained.

A company should not rely on an explanation that logs were lost before lawyers arrived or that its supplier cannot export the evidence. Logging and supplier cooperation have to be solved contractually and technically before an incident.

2.3 The 2026 amendments and transitional position

Law No 7590, published in Official Gazette No 33326 on 31 July 2026, introduced transitional rules for functions transferred to the Cybersecurity Presidency. Until the Presidency issues new secondary instruments, existing rules continue to apply and defined references to the former authorities are treated as references to the Presidency or its President.¹⁶

The amendment also inserted Article 7(1)(a) into the administrative-fine linkage in Article 16(10) of Law No 7545. Failure to supply requested data, information, documents, hardware, software or other assistance on time is therefore included in the corresponding administrative-sanction framework.¹⁷

The practical result is that primary legislation alone is not a complete operational baseline. Companies need a live register covering continuing pre-existing rules, the institutional transfer, the Presidency’s current legislation page, sector supervisors and new secondary measures.

2.4 Sanctions should be explained accurately

The original nominal statutory ranges include:

• TRY 1 million–10 million for breach of Article 7(1)(a), (b) or (c), following the 2026 amendment;
• TRY 10 million–100 million for breach of Article 18 duties concerning defined exports and corporate transactions; and
• for breach of the Article 8(4) audit duties by a commercial company, not less than TRY 100,000 and up to 5 per cent of gross sales shown in audited annual financial statements.

The law also contains criminal provisions for, among other matters, obstructing access to requested data or systems and operating without required approval or authorisation.¹⁸

These figures should not be presented as an automatic fine for every incident. The conduct, addressee, fault, concurrence, current revaluation, audit status and law applicable at the enforcement date require case-specific analysis. The occurrence of an attack does not by itself establish criminal liability of a director or senior manager.

3. The KVKK: when a cyber event becomes a personal data breach

Article 12 of the KVKK requires the controller to take appropriate technical and organisational measures to prevent unlawful processing and access and to safeguard personal data. The controller must carry out or commission the necessary internal audits. Engaging a processor does not remove the controller’s duties; the controller and processor are jointly responsible for the required security measures within the processing relationship.¹⁹

3.1 Not every cyber event is a personal data breach

An attack may stop production but leave the confidentiality, integrity and availability of personal data unaffected. Conversely, unauthorised viewing of customer accounts may be a personal data breach even if the service never went offline.

The first assessment should separate:

• confidentiality: unauthorised access or disclosure;
• integrity: alteration, deletion or loss of reliability;
• availability: loss of access to personal data for a legally meaningful period.

These categories are useful for technical classification, but they do not replace the notification threshold in Article 12(5) of the KVKK. Under that provision, the core test is whether personal data has been unlawfully obtained by others. The GDPR uses a broader personal data breach definition that also covers loss of confidentiality, integrity or availability. Availability loss alone therefore does not automatically trigger a KVKK notification without a separate assessment of the facts.

3.2 Notification to the Turkish Personal Data Protection Board and affected data subjects

Under Turkish Personal Data Protection Board Decision No 2019/10, “as soon as possible” means without delay and no later than 72 hours after the controller becomes aware of the breach. Affected data subjects should be informed within the shortest reasonable period after they are identified, directly where contact details are available and by an appropriate method, such as a website notice, where they are not.²⁰

The 72-hour period is not time granted to complete forensic work. The organisation should:

1. record the awareness time;
2. make an initial notification with the information available;
3. explain information that is not yet available; and
4. provide updates as the investigation develops.

The Board’s published decision summaries show that delayed technical root-cause identification does not automatically justify late notification and that insufficient logging or monitoring can be assessed separately as a failure of security measures.²¹

4. Legal responsibilities of the board and senior management

Law No 7545 does not create automatic personal liability for a director or senior manager every time a cyber incident occurs. Article 369 of the Turkish Commercial Code nevertheless requires directors and persons entrusted with management to act with the care of a prudent manager and protect the company’s interests in good faith. Article 553 regulates liability where founders, directors, managers or liquidators culpably breach duties arising from law or the articles of association.²²

In a cyber case, the factual questions are likely to include:

• did management understand the critical services, systems and data?
• were resources assigned to critical vulnerabilities that had been escalated?
• were the CISO, legal, internal audit and business-continuity roles defined?
• were supplier dependencies and single points of failure assessed?
• were backups and incident plans actually tested?
• did the board receive regular, intelligible and decision-useful reporting?
• were notification and public-communication decisions recorded during the incident?

Recent research argues that boards should move beyond operational metrics such as phishing results or patch counts and govern critical assets, risk appetite, resource allocation, crisis choices and stakeholder communication.²³ Field research also finds that well-intentioned but non-expert directors can perform oversight that is legitimate in form yet largely symbolic in substance.²⁴

Matters for annual board approval

• critical services and maximum tolerable downtime;
• cyber risk appetite and unacceptable scenarios;
• the reporting line of the CISO or security leader;
• cybersecurity budget and remediation of material weaknesses;
• cloud and supplier concentration risk;
• crisis committee and emergency decision rights;
• principles on ransom, law enforcement, insurance and external statements;
• ownership of regulatory reporting;
• tabletop exercises and independent testing;
• conversion of lessons learned into tracked management actions.

5. NIS2: scope, management accountability and minimum measures

NIS2 seeks a high common level of cybersecurity across 18 critical and important sectors. It generally covers medium-sized and larger entities in Annex I and Annex II sectors, while DNS services, top-level-domain registries, trust services and several other categories can be covered irrespective of size or by specific national designation.²⁵

Principal Annex I areas include energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, managed ICT and managed security services, public administration and space. Annex II includes postal and courier services, waste management, chemicals, food, specified manufacturing, online marketplaces, search engines, social networking platforms and research.

5.1 Why NIS2 scope is answered country by country

NIS2 is a directive rather than a regulation. A company must determine under the relevant Member State law:

• essential or important entity status;
• registration or self-identification requirements;
• competent authority and CSIRT;
• national reporting form;
• enforcement and maximum sanctions;
• management liability and any temporary prohibition measures;
• special national thresholds or designation decisions.

A German energy subsidiary and a French online marketplace should not be copied into the same generic NIS2 row without reviewing each national implementation.

5.2 Management-body duties

Article 20 requires management bodies to approve the Article 21 cybersecurity risk-management measures and oversee their implementation. Members must receive training; Member States are also to encourage regular training for employees. The form of management liability is determined through national implementation.²⁶

The board is not expected to select firewall rules. It should approve and monitor:

• visibility of material risks;
• the appropriate and proportionate control level;
• resources and competence;
• supply-chain dependencies;
• reporting and escalation;
• evidence that controls are effective.

5.3 The minimum NIS2 control domains

Article 21 requires appropriate and proportionate technical, operational and organisational measures based on an all-hazards approach. The minimum domains are:²⁷

1. risk analysis and information-system security policies;
2. incident handling;
3. business continuity, including backup, disaster recovery and crisis management;
4. supply-chain security, including relationships with direct suppliers and service providers;
5. secure acquisition, development and maintenance, including vulnerability handling and disclosure;
6. policies and procedures assessing the effectiveness of risk-management measures;
7. cyber hygiene and cybersecurity training;
8. policies and procedures on cryptography and, where appropriate, encryption;
9. human-resources security, access control and asset management;
10. where appropriate, multi-factor or continuous authentication and secure communications.

Implementing Regulation (EU) 2024/2690 sets more detailed technical and methodological requirements and significance criteria for defined digital service providers, including cloud, data-centre, CDN, managed-service and managed-security-service providers.²⁸

5.4 The NIS2 reporting sequence

An incident may be “significant” where it has caused or is capable of causing severe operational disruption or financial loss to the entity, or considerable material or non-material damage to other persons. From awareness, the entity submits:²⁹

• within 24 hours: an early warning;
• within 72 hours: an incident notification and initial assessment;
• when requested: an intermediate report;
• within one month after the incident notification: a detailed final report.

Where the incident is continuing, a progress report is followed by the final report after handling is completed. Recipients of the service may also need to be informed where they are likely to be adversely affected.

The 24-hour message is not a final forensic report. The organisation needs to provide an initial view of identity, contact point, suspected malicious cause and cross-border implications while the investigation continues.

5.5 The sanctions framework

For essential entities, NIS2 requires national law to provide an administrative-fine maximum of at least EUR 10 million or 2 per cent of worldwide annual turnover, whichever is higher. For important entities, the corresponding floor for the maximum is at least EUR 7 million or 1.4 per cent, whichever is higher.³⁰

These are not automatic, uniform EU fines. The directive sets a minimum level for the maximum available under Member State law. The actual sanction depends on national implementation, the infringement, fault, cooperation and other statutory factors.

6. GDPR: separate the personal data breach from the NIS2 incident

GDPR Article 32 describes risk-appropriate security including pseudonymisation and encryption; continuing confidentiality, integrity, availability and resilience; timely restoration; and regular testing and evaluation of measures.³¹

Under Article 33, a controller notifies a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in risk to people’s rights and freedoms. A processor notifies the controller without undue delay. Where high risk is likely, affected data subjects are informed without undue delay under Article 34.³²

One event may require both NIS2 and GDPR notifications

A ransomware incident at a hospital may be:

• a NIS2 significant incident because clinical services are severely disrupted; and
• a GDPR personal data breach because the confidentiality or availability of patient records is affected.

A NIS2 report does not automatically satisfy the GDPR. The authority, content, risk threshold and form differ. The same central incident file should generate separate legal tests and reporting decisions.

7. Financial services: DORA is a separate operational-resilience regime

DORA has applied since 17 January 2025 to defined EU financial entities, including credit institutions, payment institutions, electronic-money institutions, investment firms, insurers and other listed actors. It covers ICT risk management, incident reporting, digital operational-resilience testing and ICT third-party risk.³³

Article 5 places responsibility on the management body to define, approve, oversee and remain accountable for the ICT risk-management framework. Outsourcing cloud or another ICT service does not transfer the financial entity’s responsibility.

DORA time limits for a major ICT-related incident

Under Delegated Regulation (EU) 2025/301, a financial entity submits:³⁴

• an initial notification as early as possible, within four hours after classifying the incident as major and no later than 24 hours after becoming aware of the incident;
• an intermediate report no later than 72 hours after the initial notification;
• a final report no later than one month after the intermediate or latest updated intermediate report.

These deadlines do not apply to every minor system fault; they apply after the incident meets the DORA criteria for a major ICT-related incident.

Under the sector-specific-act principle, equivalent DORA provisions can displace corresponding NIS2 risk-management and reporting rules for financial entities. Other group companies, technology providers or legal entities outside DORA may still require separate NIS2 analysis.

8. Digital-product manufacturers: prepare for the CRA reporting date

The CRA creates horizontal cybersecurity requirements for hardware and software products with digital elements placed on the EU market. Most provisions apply from 11 December 2027; Chapter IV has applied since 11 June 2026, while manufacturer reporting under Article 14 starts on 11 September 2026.³⁵

As at 26 August 2026, that reporting date is still in the future. Turkish manufacturers placing products on the EU market should not wait: Article 14 will also apply to products within scope that were placed on the market before the general 2027 application date.

Article 14 reporting clocks

For an actively exploited vulnerability, the manufacturer submits:

• an early warning within 24 hours after awareness;
• a vulnerability notification within 72 hours;
• a final report no later than 14 days after a corrective or mitigating measure becomes available.

For a severe incident affecting product security, the manufacturer submits:

• an early warning within 24 hours;
• an incident notification within 72 hours;
• a final report within one month after the incident notification.

Notifications are made through the single reporting platform to the coordinating CSIRT and ENISA.³⁶

The CRA is not merely an incident-notification law. It brings secure design, secure defaults, known exploitable vulnerabilities, security updates, support periods, technical documentation, conformity and supply-chain processes into the product lifecycle. Scholarship characterises its approach as horizontal, risk-based and rooted in product safety.³⁷

9. Reporting clock matrix: there is no single 72-hour rule

Operational rule: Security operations, legal and executive management should share one incident chronology while recording the legal trigger for each regime separately. Technical detection, controller awareness and DORA major classification are not necessarily the same moment.

10. Minimum cybersecurity provisions for supplier and cloud contracts

A statement that the supplier will maintain “industry-standard security” is rarely sufficient. The security schedule should address at least:

Academic analysis of NIS2 supply-chain security finds that the directive broadly aligns with recognised risk-management practice but does not fully solve the practical complexity of IoT and multi-tier supply chains.³⁸ The customer must therefore examine components and sub-suppliers, not simply the direct vendor’s certificate.

11. The first 24 hours: one legal and technical workflow

First 60 minutes

1. open the crisis team and a single incident identifier;
2. appoint the incident, legal, technical and communications leads;
3. contain safely without wiping evidence through impulsive resets;
4. record detection, awareness, classification and decision times separately;
5. invoke the relevant supplier incident clause;
6. move communications to authorised channels and stop unauthorised public statements.

First four hours

• identify critical-service, country, customer and data impact;
• separate unauthorised access, exfiltration, alteration and availability loss;
• if DORA may apply, assess major-incident classification;
• check insurer notification and any approval condition for forensic providers;
• establish jurisdiction-appropriate legal confidentiality and privilege strategy;
• brief the board in terms of business impact rather than raw technical data.

First 24 hours

• complete the Law No 7545, KVKK, NIS2, GDPR, DORA, CRA, sector and contract matrix;
• make required early warnings;
• determine whether customers or affected data subjects need immediate risk-reduction instructions;
• record law-enforcement and regulatory-cooperation decisions;
• if ransom is demanded, assess sanctions, insurance, continuity, legality and governance together;
• preserve evidence, logs and decision chronology;
• assign owners for 72-hour reports.

12. A 30–60–90-day corporate cybersecurity compliance plan

Days 1–30: scope and critical assets

• build a Türkiye–EU legal applicability matrix for each group company;
• identify critical processes, data, systems and suppliers;
• place all Law No 7545/KVKK/NIS2/GDPR/DORA/CRA clocks in one controlled table;
• include cybersecurity oversight in the board or committee mandate;
• approve the crisis team, authority matrix and 24-hour contact list;
• take formal decisions on material vulnerabilities and end-of-life systems.

Deliverable: scope register, critical-asset map, reporting-clock matrix and governance map.

Days 31–60: controls and contracts

• review supplier contracts for notice, logs, sub-suppliers, audit and exit;
• verify MFA, privileged access, patching, backups, EDR/SIEM and segmentation controls;
• write a classification guide separating service outage from personal data breach;
• establish specialised DORA or CRA procedures where relevant;
• document evidence retention and chain of custody;
• train executives and incident roles through practical scenarios.

Deliverable: contract remediation list, control evidence and notification templates.

Days 61–90: exercise and governance evidence

• run a realistic ransomware or supplier-breach tabletop exercise;
• simulate a NIS2/CRA 24-hour warning and DORA four-hour classification path;
• test the KVKK/GDPR affected-person decision;
• perform an independent backup restoration;
• report metrics and accepted residual risks to the board;
• assign owners and closure dates to every exercise finding.

Deliverable: exercise report, evidence pack, board decision and one-year remediation roadmap.

13. Ten metrics for the board

1. percentage of critical services with a current risk assessment;
2. percentage of critical assets mapped to a business and data owner;
3. average remediation time for internet-facing critical vulnerabilities;
4. percentage of privileged accounts under MFA and periodic review;
5. restoration-test success rate and measured recovery times;
6. percentage of critical supplier contracts containing hour-based notice and audit rights;
7. average time to determine whether an event is legally reportable;
8. time taken in the latest exercise to reach executive decisions, first notice and customer communication;
9. accepted material residual risks with a named owner and expiry date;
10. percentage of incident and exercise actions closed on time.

The dashboard should not consist solely of volume metrics such as blocked attacks. The board needs visibility into business criticality, decision quality, remediation velocity and supplier dependency.

14. Three practical scenarios

Scenario A — Customer data exfiltration at a Turkish e-commerce business

The company assesses its “without delay” cyber incident and vulnerability duties under Law No 7545. Because confidentiality of personal data is affected, the KVKK breach process opens; awareness time is recorded and the Board notification is prepared without treating 72 hours as a waiting period. Payment providers, cloud suppliers, insurers and contract customers are checked separately.

Scenario B — Ransomware at the German manufacturing subsidiary of a Turkish group

The German entity’s sector, size and status under Germany’s NIS2 implementation are confirmed. If the significance threshold is met, the 24-hour early-warning process begins. GDPR Articles 33 and 34 are assessed if workforce or customer data is affected. Access by the Turkish parent, shared controllership and cross-border data flows are analysed separately.

Scenario C — An actively exploited vulnerability in a Turkish software product sold in the EU

As at 26 August 2026, the manufacturer should be ready for the Article 14 start date of 11 September 2026. After that date, awareness of an actively exploited vulnerability requires a 24-hour early warning and 72-hour vulnerability notification. The deadline cannot be managed unless the organisation already has a product security incident response team, product register, EU establishment or representative analysis, coordinating CSIRT, user mitigation text and corrective-action record.

Frequently asked questions

Does Türkiye’s Law No 7545 apply only to critical-infrastructure companies?

No. Its scope language is broad and covers natural and legal persons present, active or providing services in cyberspace. That does not mean every detailed obligation applies identically: activity, Presidency classification, critical-infrastructure status, sector and secondary measures must be assessed together.

Must every cyber incident be reported under the KVKK within 72 hours?

No. The KVKK reporting process requires a personal data breach. A technical failure unrelated to personal data is not automatically reportable. A confidentiality, integrity or availability event may, however, require notification after the legal risk assessment.

Does NIS2 apply directly to a company in Türkiye?

NIS2 is an EU directive implemented through Member State law. An EU subsidiary, branch or defined digital-service role of a Turkish group may be in scope, and cross-border rules may require main-establishment or representative analysis. The definitive answer comes from the relevant Member State implementation.

Are directors or senior managers personally liable whenever a cyber incident occurs?

No. The event alone does not create automatic personal liability. Authority, role, fault, known risks, decisions, organisational design and the applicable special law matter. Turkish Commercial Code duties and NIS2 management oversight under national law are relevant frameworks.

Does a cloud provider’s certification satisfy the customer’s legal duty?

No. Certification may be useful evidence, but scope, configuration, sub-suppliers, countries, incident notice, log access, backups and exit still require review. Outsourcing does not remove the regulated entity’s responsibility.

Does the CRA become fully applicable on 11 September 2026?

No. Article 14 reporting for actively exploited vulnerabilities and severe product-security incidents begins on that date. The general application date is 11 December 2027, while Chapter IV has applied since 11 June 2026.

Can one notification satisfy NIS2, GDPR and DORA?

Generally not. Authorities, thresholds, content and deadlines differ. Even where a Member State provides a single reporting entry point, the organisation should document that each legal test and required content has been met.

Conclusion: cyber compliance is a decision architecture before it is a security product

Corporate cybersecurity obligations are not simply an IT control list. The board governs critical services, risk tolerance, budget, supplier dependencies and crisis choices. Legal functions establish scope, reporting tests, contracts and regulatory communication. Technical teams implement controls, detect and contain events and generate evidence.

A defensible programme has six elements:

1. an entity- and activity-based applicability matrix;
2. a critical-asset and service map;
3. incident classification and reporting clocks that are not conflated;
4. board decisions and a clear accountability line;
5. auditable supplier contracts and technical evidence;
6. regular exercises and post-incident improvement.

This architecture does more than reduce regulatory fines. It reduces service interruption, customer loss, contractual breach, governance ambiguity and the risk of inaccurate crisis communications. Cyber resilience is as much the company’s ability to place the right decision with the right person at the right time as it is the security team’s ability to defend a system.

---

Legal information notice

This study provides general information only. It is not a legal opinion, security audit, incident-notification decision or technical assessment for a specific organisation, sector, event or jurisdiction. NIS2 scope and sanctions depend on Member State implementation; Turkish duties depend on activity, critical-infrastructure or sector status, secondary measures and the facts of the incident. The English titles of Turkish legislation used in this study are unofficial translations provided for information only.

Bibliography

Primary and official materials

• Law No 7545 on Cybersecurity.
• Law No 7590 Amending Certain Laws and Decree-Laws.
• Law No 6698 on the Protection of Personal Data.
• Turkish Commercial Code No 6102, arts 369 and 553.
• Turkish Personal Data Protection Board, Decisions No 2019/10 and No 2020/905.
• Directive (EU) 2022/2555 (NIS2).
• Commission Implementing Regulation (EU) 2024/2690.
• Regulation (EU) 2016/679 (GDPR).
• Regulation (EU) 2022/2554 (DORA).
• Commission Delegated Regulation (EU) 2025/301.
• Regulation (EU) 2024/2847 (Cyber Resilience Act).

Academic literature

• Chiara PG, ‘Understanding the Regulatory Approach of the Cyber Resilience Act: Protection of Fundamental Rights in Disguise?’ (2025) 16 European Journal of Risk Regulation 469.
• Harel Y and Carmeli A, ‘A Strategic Cybersecurity Oversight Framework: A Board’s Imperative’ (2025) 11(1) Journal of Cybersecurity tyaf021.
• Lankton N, Price JB and Karim M, ‘Cybersecurity Breaches and the Role of Information Technology Governance in Audit Committee Charters’ (2021) 35(1) Journal of Information Systems 101.
• Lowry MR, Vance A and Vance MD, ‘Inexpert Supervision: Field Evidence on Boards’ Oversight of Cybersecurity’ (2026) 72(2) Management Science 783.
• van ’t Schip M, ‘The Regulation of Supply Chain Cybersecurity in the NIS2 Directive in the Context of the Internet of Things’ (2024) 15(1) European Journal of Law and Technology.
• Yücel E, ‘Türkiye’nin Siber Güvenlik Yaklaşımı ve 7545 Sayılı Siber Güvenlik Kanunu Üzerine Bir Değerlendirme’ (2025) 33(3) Selçuk Üniversitesi Hukuk Fakültesi Dergisi 1849.

Related reading

Related studies on the same subject and the broader practice page are listed below.

• Data Protection, Technology and Digital Regulation
• Is France Moving from Windows to Linux? DINUM’s Move, Digital Sovereignty, GDPR and Türkiye’s KVKK
• Cyber Resilience Act Reporting Duties Now Apply: What Changes for Manufacturers Supplying Digital Products to the EU?
• Responding to Türkiye’s Cybersecurity Presidency: A Company Guide to Official Notices, Vulnerability Remediation and Inspections
• When Your Cloud Provider Is Breached: A Türkiye–EU Cybersecurity Supply Chain and Contracting Playbook

Footnotes

---

1. Law No 7545 on Cybersecurity (Official Gazette 19 March 2025/32846) https://cdn.tbmm.gov.tr/KKBSPublicFile/D28/Y3/KanunMetni/9ac32dc5-35ee-46a8-8c47-7a16ec35d36f.htm; Law No 6698 on the Protection of Personal Data https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf; Directive (EU) 2022/2555 (NIS2) [2022] OJ L333/80 https://eur-lex.europa.eu/eli/dir/2022/2555/oj; Regulation (EU) 2016/679 (GDPR) [2016] OJ L119/1 https://eur-lex.europa.eu/eli/reg/2016/679/oj; Regulation (EU) 2022/2554 (DORA) [2022] OJ L333/1 https://eur-lex.europa.eu/eli/reg/2022/2554/oj; Regulation (EU) 2024/2847 (CRA) [2024] OJ L https://eur-lex.europa.eu/eli/reg/2024/2847/oj accessed 26 August 2026.↩︎

2. Law No 7545, arts 2 and 7.↩︎

3. NIS2, arts 2–3 and Annexes I–II; European Commission, ‘NIS2 Directive: FAQs’ https://digital-strategy.ec.europa.eu/en/faqs/directive-measures-high-common-level-cybersecurity-across-union-nis2-directive-faqs accessed 26 August 2026.↩︎

4. Turkish Commercial Code No 6102, arts 369 and 553 https://cdn.tbmm.gov.tr/KKBSPublicFile/D23/Y2/T1/KanunMetni/38650b69-c78b-48fe-b960-fe5fb6734047.html.↩︎

5. NIS2, art 20.↩︎

6. Law No 7545, art 7(1)(b); Turkish Personal Data Protection Board, Decision No 2019/10 (24 January 2019), current Authority notice https://www.kvkk.gov.tr/Icerik/8595/kamuoyu-duyurusu accessed 26 August 2026.↩︎

7. NIS2, art 23; GDPR, arts 33–34.↩︎

8. Commission Delegated Regulation (EU) 2025/301, art 5 https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng.↩︎

9. CRA, arts 14 and 71.↩︎

10. Law No 6698, art 12(2).↩︎

11. NIS2, art 21(2)(d) and recital 83; DORA, arts 5, 28–30.↩︎

12. Grand National Assembly of Türkiye, ‘Law No 7545 on Cybersecurity’ https://www.tbmm.gov.tr/Yasama/Kanun/af1dfbdb-e3e3-4820-a493-0194504c63b4; Cybersecurity Presidency, ‘Cybersecurity Law Published’ (19 March 2025) https://siberguvenlik.gov.tr/haberler/detay/7545_kanun_yayimlandi accessed 26 August 2026.↩︎

13. Emir Yücel, ‘Türkiye’nin Siber Güvenlik Yaklaşımı ve 7545 Sayılı Siber Güvenlik Kanunu Üzerine Bir Değerlendirme’ (2025) 33(3) Selçuk Üniversitesi Hukuk Fakültesi Dergisi 1849 https://doi.org/10.15337/suhfd.1700507.↩︎

14. Law No 7545, art 7.↩︎

15. Law No 7545, art 8.↩︎

16. Law No 7590 Amending Certain Laws and Decree-Laws (Official Gazette 31 July 2026/33326), arts 26–27 https://cdn.tbmm.gov.tr/KKBSPublicFile/D28/Y4/KanunMetni/152a9101-15fe-4138-aceb-99a304bb9ec3.htm.↩︎

17. Law No 7590, art 27(4)(b).↩︎

18. Law No 7545, arts 16–18; Law No 7590, art 27(4)(b).↩︎

19. Law No 6698, art 12.↩︎

20. Turkish Personal Data Protection Board, Decision No 2019/10 (n 6).↩︎

21. Turkish Personal Data Protection Board, Decision No 2020/905, published summary concerning a breach at an insurance company https://www.kvkk.gov.tr/Icerik/6848/2020-905 accessed 26 August 2026.↩︎

22. Turkish Commercial Code No 6102 (n 4), arts 369 and 553.↩︎

23. Yaniv Harel and Abraham Carmeli, ‘A Strategic Cybersecurity Oversight Framework: A Board’s Imperative’ (2025) 11(1) Journal of Cybersecurity tyaf021 https://doi.org/10.1093/cybsec/tyaf021.↩︎

24. Michelle R Lowry, Anthony Vance and Marshall D Vance, ‘Inexpert Supervision: Field Evidence on Boards’ Oversight of Cybersecurity’ (2026) 72(2) Management Science 783 https://doi.org/10.1287/mnsc.2023.04147; Nancy Lankton, Jean B Price and Mohammad Karim, ‘Cybersecurity Breaches and the Role of Information Technology Governance in Audit Committee Charters’ (2021) 35(1) Journal of Information Systems 101 https://doi.org/10.2308/isys-18-071.↩︎

25. NIS2, arts 2–3 and Annexes I–II; European Commission (n 3).↩︎

26. NIS2, art 20.↩︎

27. NIS2, art 21.↩︎

28. Commission Implementing Regulation (EU) 2024/2690 https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj.↩︎

29. NIS2, art 23.↩︎

30. NIS2, art 34.↩︎

31. GDPR, art 32.↩︎

32. GDPR, arts 33–34.↩︎

33. DORA, arts 2, 5, 6 and 28–30.↩︎

34. Commission Delegated Regulation (EU) 2025/301 (n 8), art 5.↩︎

35. CRA, arts 69 and 71; European Commission, ‘Cyber Resilience Act — Summary’ https://digital-strategy.ec.europa.eu/en/policies/cra-summary accessed 26 August 2026.↩︎

36. CRA, art 14; European Commission, ‘Cyber Resilience Act Reporting Obligations’ https://digital-strategy.ec.europa.eu/en/policies/cra-reporting accessed 26 August 2026.↩︎

37. Pier Giorgio Chiara, ‘Understanding the Regulatory Approach of the Cyber Resilience Act: Protection of Fundamental Rights in Disguise?’ (2025) 16 European Journal of Risk Regulation 469 https://doi.org/10.1017/err.2025.9.↩︎

38. Mattis van ’t Schip, ‘The Regulation of Supply Chain Cybersecurity in the NIS2 Directive in the Context of the Internet of Things’ (2024) 15(1) European Journal of Law and Technology https://ejlt.org/index.php/ejlt/article/view/989.↩︎