When Your Cloud Provider Is Breached: A Türkiye–EU Cybersecurity Supply Chain and Contracting Playbook

Legal position last verified: 31 August 2026.

Moving customer data, workforce systems, accounting applications or production infrastructure to the cloud transfers part of the operation. It does not transfer the customer’s entire legal responsibility. Cloud provider data breach liability can turn not only on the supplier’s security failures, but also on the customer’s decisions on vendor selection, contract terms, identity configuration, monitoring, incident escalation and exit preparedness.

Türkiye’s Law No 7545 on Cybersecurity adopts life-cycle security, accountability and responsibility for implementing measures that prevent or reduce the effects of cyberattacks.¹ Article 12(2) of the KVKK provides that where personal data are processed by another person on the controller’s behalf, the controller and processor are jointly responsible for the required data-security measures.²

In the EU, the GDPR requires controllers to use processors providing sufficient guarantees and to govern the relationship through an Article 28 contract. NIS2 expressly includes supply-chain security within the minimum cybersecurity risk-management measures. DORA goes further for financial entities: outsourcing ICT services does not remove the financial entity’s responsibility for compliance.³ The Data Act also turns cloud exit from a technical preference into a regulated contractual process covering switching, data portability, transition assistance and deletion.⁴

This study extends the incident-management framework in our work on the first 24 hours of cyber incident reporting and corporate cybersecurity legal obligations to supplier governance and contracting.

Core conclusion: “The breach happened at the supplier” is not an automatic defence. The relevant questions are which legal role each party performed, which risks each party controlled, how the customer selected and supervised the provider, what the contract required, and how both parties acted during the incident.

Cloud provider data breach liability: executive summary

1. Start with the role analysis: “cloud provider” is not one legal role

“Cloud provider” is a technical umbrella term. Legal classification depends on what the parties actually do, not the product label or invoice description.

1.1 Processor

A provider may act as processor where it hosts, backs up or otherwise processes personal data solely on the customer’s documented instructions. The contract should then define the subject matter, duration, nature, purpose, data, data subjects, security, subprocessors, assistance and deletion or return.

1.2 Independent controller

The provider may act as a separate controller for defined purposes such as account security, fraud prevention, billing, compliance, product analytics or service improvement. A statement that “customer content is not used for training” does not answer how telemetry, security logs, support tickets or account data are used.

1.3 Possible joint controllership

Where customer and provider jointly determine particular purposes and essential means, joint controllership may arise. This is fact-sensitive and should not be inferred merely because a platform is standardised. The EDPB emphasises that role classification follows actual functions rather than contractual labels.⁵ Recent cloud scholarship also shows why traditional controller–processor categories can become difficult to apply across complex service layers.⁶

1.4 The subprocessor chain

The primary provider may depend on data centres, support vendors, security monitoring, content delivery, analytics or software components. The customer should be able to identify:

• each relevant subprocessor;
• the service performed;
• data and systems accessible;
• countries involved;
• change dates;
• flow-down obligations;
• the route for objection or termination.

A contract naming only the main provider does not make the downstream chain disappear.

2. The shared responsibility model is not a complete legal allocation

Cloud providers often publish a “shared responsibility model”. In IaaS, the provider may control physical infrastructure and the hypervisor while the customer controls operating systems, identity, security groups and applications. In SaaS, the provider operates a much larger technical layer.

This model is useful operationally but does not, by itself, allocate statutory responsibility. The organisation needs three separate maps:

1. Technical control map: who implements each control?
2. Legal role map: who is controller, processor, NIS2 entity, DORA financial entity or CRA manufacturer?
3. Contract risk map: who must notify, cooperate, remedy and indemnify?

Where a contract assigns a control to the provider, the customer’s task changes from implementation to verification that the provider performs it effectively.

3. Türkiye’s Law No 7545: outsourcing does not end the life-cycle duty

Law No 7545 has broad scope and adopts principles including life-cycle security, accountability and responsibility for cyber measures.⁷ For relevant actors providing services or processing data through information systems, duties may include:

• implementing applicable cyber measures;
• reporting detected vulnerabilities and cyber incidents without delay;
• complying with regulatory instruments of the Cybersecurity Presidency;
• providing requested data, documents and technical cooperation.⁸

A company does not cease to be the affected service provider merely because its infrastructure, monitoring or application layer is outsourced. Even where the vendor detects the event first, the customer should separately assess:

• impact on its own services;
• whether and to what extent the duty to notify a detected vulnerability or cyber incident without delay under Article 7 of Law No 7545 applies;
• any critical-infrastructure or sector rule;
• how the supplier’s direct communication with the Presidency affects, but does not necessarily replace, the customer’s own duty.

3.1 Procurement is the first stage of the security lifecycle

A life-cycle approach means security should be designed into requirements, selection, integration, operation, change and termination. A cyber clause should therefore cover more than “notify us after a breach”.

4. The KVKK: why a processor breach does not automatically release the controller

Article 12(2) of the KVKK states that where personal data are processed by another person on the controller’s behalf, the controller and processor are jointly responsible for the required security measures. The controller must also conduct or commission the necessary audits.⁹

The Authority’s official explanation similarly states that the controller should ensure the processor provides the necessary level of security and should carry out appropriate oversight according to the risk and nature of the data.¹⁰

4.1 What do the Board’s published decisions show?

A compromised service-provider account created in 2003

Decision No 2022/711 concerned a ransomware event that began through a user account used by a service provider since 2003. The Board referred to Article 12(2) and found that the controller also bore responsibility for failing to ensure the necessary security level.¹¹

A systemic error at a software-support provider

Decision No 2021/187 involved personal data being sent to the wrong employer customers following a system error at a data processor providing information-systems support. The Board referred to the need to integrate security requirements into procurement, development and maintenance.¹²

A vulnerability in a third-party customer panel

Decision No 2023/412 concerned a hosting company whose third-party customer-management panel was exploited, resulting in data transfer to a foreign IP address and later publication on the dark web.¹³ The case illustrates why “the defect was in a third-party product” is not a complete substitute for the controller’s security programme.

The common lesson is that regulators examine account governance, procurement, patching, logging, monitoring and the controller’s assurance over the provider. The provider’s conduct does not automatically reduce the customer’s responsibility to zero.

5. Contractual liability under Turkish law: what a contract can and cannot do

Statutory obligations and contractual risk allocation are different. A regulator will not treat the customer’s statutory duties as extinguished merely because the contract places operational tasks on the provider. The contract can, however, allocate between the parties:

• breach-response costs;
• forensic and notification support;
• data restoration and migration costs;
• third-party claims;
• service credits;
• indemnities;
• suspension and termination rights.

Under Articles 112, 115 and 116 of the Turkish Code of Obligations, a debtor that fails to perform properly is liable unless it proves absence of fault; advance exclusion of liability for gross fault is invalid; and liability may arise for auxiliary persons.¹⁴

5.1 Negotiating the liability cap

The customer should separate:

• the general cap;
• a higher privacy and confidentiality cap;
• exclusions for intent, gross fault or intellectual-property claims;
• incident-response and restoration expenses;
• third-party claims;
• insurance coverage;
• any restrictions on indemnification of administrative fines under applicable law.

A cap tied only to one year of fees may not reflect the risk created by critical customer data or prolonged outage. Unlimited liability may also be commercially unrealistic. A more defensible structure uses differentiated caps and clearly defined recoverable loss categories.

6. GDPR: the controller must select a processor providing sufficient guarantees

Article 28 GDPR requires the controller to use only processors providing sufficient guarantees that appropriate technical and organisational measures will be implemented. The contract must cover at least:

• documented instructions;
• confidentiality;
• Article 32 security;
• subprocessors;
• assistance with rights;
• assistance with Articles 32–36;
• deletion or return;
• information and audit cooperation.¹⁵

A processor must notify the controller without undue delay after becoming aware of a personal data breach. A supplier clause permitting notice only after 72 hours is therefore often operationally unsafe: the controller needs time to investigate and make its own notification decision.

6.1 A third-party attack is neither automatic liability nor automatic exoneration

In Natsionalna agentsia za prihodite, the Court of Justice held that unlawful access by a third party does not, by itself, prove that the controller’s measures were inappropriate. Equally, the fact that the attack was committed by a third party does not automatically exempt the controller. Appropriateness must be assessed against the risk, state of the art, cost and circumstances.¹⁶

Applied to cloud incidents:

• customers are not automatically liable for every provider attack;
• “a criminal caused it” is not a complete defence;
• the customer should be able to prove selection, configuration, monitoring and response decisions.

7. NIS2: supply-chain security is an express risk-management duty

Article 21(2)(d) NIS2 includes supply-chain security, including the security-related aspects of relationships with direct suppliers or service providers. Entities should consider each direct supplier’s specific vulnerabilities, the overall quality of products and services and suppliers’ secure-development practices.¹⁷

Recital 83 also makes clear that outsourcing maintenance does not remove the entity’s risk-management and reporting duties.¹⁸

What should an NIS2 entity do?

• classify suppliers supporting critical services;
• obtain visibility into material sub-suppliers;
• assess secure development and vulnerability management;
• measure impact on the entity’s service;
• assess single-provider and substitutability risk;
• review the relevant Member State implementation.

Academic analysis of NIS2 supply-chain security finds that the framework broadly reflects established risk-management principles but leaves practical visibility challenges in complex IoT and software chains.¹⁹

8. Financial services: under DORA, “the provider did it” is particularly weak

DORA has applied since 17 January 2025. Article 28 DORA states that financial entities remain fully responsible for compliance when they use ICT third-party services. Before entering the arrangement, the financial entity should assess:

• whether the service supports a critical or important function;
• supervisory conditions;
• all relevant risks and concentration risk;
• suitability of the provider;
• conflicts of interest.²⁰

8.1 Minimum DORA contract areas

Article 30 requires contractual provisions covering matters such as:

• a complete description of services;
• subcontracting conditions;
• service and data-processing locations;
• data security, access, recovery and return;
• service levels;
• incident assistance;
• cooperation with authorities;
• access and audit rights;
• termination and exit;
• continuity.²¹

Delegated Regulation (EU) 2024/1773 requires the policy for ICT arrangements supporting critical or important functions to assess the provider’s location, data, concentration, substitutability and outage impact.²² Delegated Regulation (EU) 2025/532 adds detail for subcontracting chains.²³

8.2 The DORA register of information

DORA financial entities must maintain a structured register of ICT third-party arrangements. It is more than a vendor list: it links services, functions, locations, subcontractors and criticality.²⁴

9. The EU Data Act: the overlooked cyber-resilience control—exit

If a provider becomes unsafe or unreliable, inability to switch is itself a cyber risk. The Data Act has applied since 12 September 2025 and directly regulates switching between data-processing services.²⁵

9.1 Required contractual switching terms

Under Article 25, a written contract should cover:

• switching to another provider or on-premises infrastructure;
• a generally applicable maximum 30-day transitional period;
• reasonable assistance;
• continuity;
• a high level of security during transition;
• support for the exit strategy;
• exportable data and digital assets;
• at least a 30-day retrieval period;
• erasure following successful switching.²⁶

Where 30 days is technically unfeasible, the provider may, within 14 working days, give reasons and specify an alternative period not exceeding seven months. The customer may also extend the transitional period once.

9.2 Switching charges

As at 28 August 2026, a provider may impose reduced switching charges that do not exceed direct switching costs. From 12 January 2027, switching charges are prohibited. Standard service charges and separately requested additional professional services remain distinct.²⁷

9.3 Do not write the exit plan after the breach

At least annually, test:

• export format;
• portability of identities, roles, logs and configuration;
• key ownership;
• restoration to another environment;
• feasibility of a 30-day transition;
• dependency on proprietary APIs and managed services;
• proof of retrieval and deletion.

Data Act scholarship notes that the switching provisions are intended to reduce vendor lock-in, while practical uncertainty remains around technical complexity and the boundary between switching assistance and chargeable additional services.²⁸

10. CRA: security lifecycle for software and product suppliers

Not every cloud service is automatically a “product with digital elements” under the CRA. The Act is not an unlimited general regime for all services. Where an organisation supplies hardware, software, connected devices or covered components, however, its CRA role requires separate analysis.

The CRA’s general provisions will apply from 11 December 2027, while Article 14 reporting obligations will begin on 11 September 2026.²⁹ Once the general provisions apply, manufacturers will need to address:

• risk-based secure design;
• absence of known exploitable vulnerabilities at market placement;
• secure-by-default configuration;
• vulnerability handling;
• security updates;
• technical documentation and conformity.³⁰

A customer contract should not merely repeat that the supplier will comply with the CRA. It should define the product and version, support period, vulnerability channel, component or SBOM visibility, patch timing and emergency mitigations.

11. Thirty questions before signature

A. Corporate and legal structure

1. Which legal entity provides the service?
2. Who owns or supplies the infrastructure, model, software or data centre?
3. What are the parties’ KVKK/GDPR roles?
4. For which purposes does the provider process data independently?
5. In which countries are hosting, support and remote access performed?
6. Are regulatory permissions or sector approvals required?

B. Sub-suppliers and concentration

7. What is the current subprocessor and subcontractor list?
8. Which sub-supplier accesses which data or system?
9. How far in advance is change notified?
10. Does the customer have an objection or termination right?
11. Is a critical service dependent on one region, one data centre or one provider?
12. What are the provider’s own critical upstream dependencies?

C. Security

13. How are MFA, privileged access and tenant isolation implemented?
14. How is data encrypted in transit and at rest?
15. Who controls keys?
16. What secure-development and code-review practices are used?
17. What are the vulnerability and patch timelines?
18. What is the scope of penetration testing and independent assurance?
19. How are customer misconfigurations detected?
20. Which logs are available, for how long and in what format?

D. Incident and continuity

21. Within how many hours is the customer notified?
22. Does notice run from suspicion, awareness or confirmation?
23. What forensic and regulatory support is provided?
24. What are the tested RTO and RPO?
25. How are resources allocated if the same event affects many customers?
26. Who controls communications during ransomware or supply-chain compromise?

E. Exit and liability

27. In which formats can data and digital assets be exported?
28. What are transition, retrieval and deletion periods?
29. What liability caps apply to privacy, confidentiality and continuity?
30. What cyber insurance exists and at what limit?

An “unknown” or confidential answer is not always a rejection. For a critical control, however, compensating safeguards, contract protection and explicit risk acceptance are required.

12. Twenty-four minimum contract provisions

13. The first 24 hours of a supplier breach

The customer should not simply wait for the provider’s next bulletin.

First two hours

• open an incident ID;
• invoke the contractual incident clause;
• record the supplier’s and customer’s awareness times separately;
• request affected service, tenant, data, country and sub-supplier details;
• rotate credentials, tokens or links controlled by the customer;
• preserve every version of the provider’s status notice.

Hours 2–12

• run the Law No 7545, KVKK, NIS2, GDPR, DORA and contract matrix;
• do not confuse the supplier’s reporting with the customer’s own duties;
• decide who controls customer communications;
• impose a deadline for logs and evidence;
• activate alternative or manual processes.

By hour 24

• submit required early notifications;
• identify unknowns in supplier statements;
• decide whether customers or individuals need protective instructions;
• reserve liability and insurance rights;
• assess suspension or switching.

This workflow should be used together with the separate “First 24 Hours of a Cyber Incident” reporting matrix.

14. Exit and multi-provider strategy

Multi-cloud is not automatically safer. Two providers can also create two control environments, two skill sets and greater complexity. A company should nevertheless retain:

• provider-independent backups for critical data;
• infrastructure-as-code where feasible;
• identity and access configuration;
• data dictionaries and export schemas;
• an alternative communications route;
• a named exit owner.

Annual exit exercise

For at least one critical service:

1. export data;
2. verify hashes and record counts;
3. restore a limited data set elsewhere;
4. test identity and log portability;
5. measure time and cost;
6. compare the result with the contractual 30-day claim;
7. report gaps for management decision.

15. A 30–60–90-day implementation plan

Days 1–30 — visibility

• critical supplier inventory;
• service and data flows;
• role and country matrix;
• contracts and DPAs;
• subprocessors;
• concentration risks;
• 24/7 contacts.

Deliverable: critical supplier register and red-risk list.

Days 31–60 — contracts and evidence

• 30-question due diligence;
• privacy/security schedule remediation;
• DORA and Data Act applicability;
• logging and incident-notice test;
• RTO/RPO and backup evidence;
• liability and insurance review.

Deliverable: contract remediation plan and assurance file.

Days 61–90 — testing and governance

• supplier-breach tabletop;
• export and restoration test;
• KVKK/NIS2/DORA reporting exercise;
• supplier scoring and reapproval;
• management risk decision;
• closure dates.

Deliverable: operating supply-chain governance and annual calendar.

16. Three practical scenarios

Scenario 1 — A foreign support subprocessor of a Turkish HR SaaS provider is compromised

• The employer remains controller and retains its KVKK Article 12 duties.
• The SaaS provider may be processor; the support company may be subprocessor.
• International transfer and subprocessor-change mechanisms are checked.
• The employer records its own breach awareness and affected-person risk.
• Contractual cooperation and indemnity rights are invoked separately.

Scenario 2 — A cloud region supporting an EU financial entity becomes unavailable

• The financial entity remains fully responsible under DORA Article 28.
• The incident is classified under DORA Article 18 and the applicable technical standards; the reporting timetable is activated if the thresholds for a major ICT-related incident are met.
• Critical-provider oversight does not replace the entity’s own responsibility.
• Concentration, substitutability and exit are reassessed.
• RTO/RPO and assistance clauses are invoked.

Scenario 3 — A third-party component in an EU-market software product is actively exploited

• The Turkish supplier’s manufacturer role under the CRA is assessed.
• After 11 September 2026, Article 14 reporting may apply.
• The component supplier’s notice does not replace the manufacturer’s product and user assessment.
• Product versions, SBOM, patch and user mitigation are mapped.
• If NIS2 services are also disrupted, the entity-level workflow runs separately.

Frequently asked questions

Is a customer always liable when its cloud provider is breached?

No. There is no automatic liability. The customer is nevertheless assessed against its legal role, supplier selection, configuration, oversight and incident decisions. Provider fault does not automatically remove the customer’s obligations.

Does the processor bear every penalty under the KVKK?

No. Article 12(2) provides joint responsibility for security measures. The addressee of an administrative sanction and contractual recourse between the parties require a fact-specific assessment.

Is SOC 2 or ISO 27001 sufficient assurance?

Not by itself. Review the scope, period, exceptions, customer responsibilities, subservice organisations and relevance to the actual service. Certification does not replace contracting, configuration testing or incident cooperation.

Can the supplier wait 72 hours before telling the customer?

For many regulated customers, that is too late. Because the customer may have its own 24- or 72-hour obligations, the supplier should provide an hour-based early notice from suspicion or awareness, followed by updates.

Can a customer always object to a new subprocessor?

The right depends on the contract and applicable law. GDPR Article 28 requires specific or general written authorisation and information on intended changes. The effect of an objection and any termination right should be defined.

Does the Data Act apply to every cloud contract?

Its switching chapter applies to data-processing services and contains specific exceptions, including certain custom-built or limited-duration test services. The precise service model and contract require assessment.

Will cloud switching be entirely free after 12 January 2027?

Providers may not impose switching charges. Standard service fees, proportionate early-termination charges and additional professional services requested by the customer remain separate questions.

Does a liability cap mean no damages can be claimed?

No. The cap’s scope, carve-outs, governing law, level of fault and mandatory limits must be reviewed. Regulatory duties also do not disappear because of a contractual cap.

Conclusion: moving to the cloud changes the control model, not the existence of responsibility

Cloud provider data breach liability makes the limits of outsourcing visible. A company may outsource the data centre, application layer or part of security operations. It cannot fully outsource:

• its statutory role;
• risk assessment;
• selection of a suitable provider;
• secure configuration;
• reporting decisions;
• continuity and exit planning.

A defensible supply-chain programme rests on five forms of evidence:

1. accurate role and data-flow mapping;
2. risk-based due diligence;
3. measurable contract and security schedules;
4. incident and assurance evidence;
5. a tested exit plan.

The value of a cloud contract is not merely to identify the party at fault after a breach. A strong contract allows the customer to learn early, obtain evidence, continue services, protect affected people and switch provider safely where necessary.

---

Legal information notice

This article provides general information only. It is not a legal opinion, supplier audit, data protection impact assessment or technical security review for any particular organisation, provider, contract, sector or incident. NIS2 depends on Member State implementation; DORA depends on entity status; and liability under Turkish law depends on the parties’ roles, fault, measures and contract.

Bibliography

Primary and official materials

• Law No 7545 on Cybersecurity.
• Law No 6698 on the Protection of Personal Data.
• Turkish Code of Obligations No 6098.
• Turkish Personal Data Protection Board, published summaries of Decisions No 2021/187, 2022/711 and 2023/412.
• Regulation (EU) 2016/679 (GDPR).
• EDPB Guidelines 07/2020.
• Directive (EU) 2022/2555 (NIS2).
• Regulation (EU) 2022/2554 (DORA).
• Commission Delegated Regulations (EU) 2024/1773 and 2025/532.
• Regulation (EU) 2023/2854 (Data Act).
• Regulation (EU) 2024/2847 (Cyber Resilience Act).
• VB v Natsionalna agentsia za prihodite (C‑340/21) EU:C:2023:986.

Academic literature

• Ehlen T, Fritz G and Blum B, ‘Cloud-Switching unter dem Data Act: Kostenloser Wechsel in jedem Fall?’ (2025) 41(3) Computer und Recht 141.
• Fischer C, ‘Re-thinking the Allocation of Roles under the GDPR in the Context of Cloud Computing’ (2024) 14(1) International Data Privacy Law 53.
• Svoboda J, ‘Public Procurement and Vendor Lock-in within the Area of Data Migration’ (2022) Milan Law Review.
• 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.

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
• The First 24 Hours of a Cyber Incident: A Türkiye–EU Legal Reporting Playbook

Footnotes

---

1. Law No 7545 on Cybersecurity, art 4(1)(ç), (e) and (f) https://cdn.tbmm.gov.tr/KKBSPublicFile/D28/Y3/KanunMetni/9ac32dc5-35ee-46a8-8c47-7a16ec35d36f.htm accessed 28 August 2026.↩︎

2. Law No 6698 on the Protection of Personal Data, art 12(2) https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf.↩︎

3. Regulation (EU) 2016/679 (GDPR), arts 28 and 32 https://eur-lex.europa.eu/eli/reg/2016/679/oj; Directive (EU) 2022/2555 (NIS2), art 21 https://eur-lex.europa.eu/eli/dir/2022/2555/oj; Regulation (EU) 2022/2554 (DORA), arts 28–30 https://eur-lex.europa.eu/eli/reg/2022/2554/oj accessed 28 August 2026.↩︎

4. Regulation (EU) 2023/2854 (Data Act), arts 23–30 https://eur-lex.europa.eu/eli/reg/2023/2854/oj.↩︎

5. European Data Protection Board, ‘Guidelines 07/2020 on the Concepts of Controller and Processor in the GDPR’ (Version 2.0, 7 July 2021) https://www.edpb.europa.eu/documents/guideline/guidelines-072020-on-the-concepts-of-controller-and-processor-in-the-gdpr_en accessed 28 August 2026.↩︎

6. Cyril Fischer, ‘Re-thinking the Allocation of Roles under the GDPR in the Context of Cloud Computing’ (2024) 14(1) International Data Privacy Law 53 https://doi.org/10.1093/idpl/ipad023.↩︎

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

8. Law No 7545, art 7.↩︎

9. Law No 6698, art 12(2)–(3).↩︎

10. Turkish Personal Data Protection Authority, ‘Data Security Obligations’ https://www.kvkk.gov.tr/Icerik/2040/Veri-Guvenligine-Iliskin-Yukumlulukler accessed 28 August 2026.↩︎

11. Turkish Personal Data Protection Board, Decision No 2022/711 (21 July 2022), published summary https://www.kvkk.gov.tr/Icerik/8848/2022-711.↩︎

12. Turkish Personal Data Protection Board, Decision No 2021/187 (4 March 2021), published summary https://www.kvkk.gov.tr/Icerik/6999/2021-187.↩︎

13. Turkish Personal Data Protection Board, Decision No 2023/412 (21 March 2023), published summary https://www.kvkk.gov.tr/Icerik/8853/2023-412.↩︎

14. Turkish Code of Obligations No 6098, arts 112, 115 and 116 https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6098.pdf.↩︎

15. GDPR, art 28(1)–(3) and art 33(2).↩︎

16. VB v Natsionalna agentsia za prihodite (C‑340/21) EU:C:2023:986 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0340.↩︎

17. NIS2, art 21(2)(d) and 21(3).↩︎

18. NIS2, recital 83.↩︎

19. 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.↩︎

20. DORA, art 28(1) and 28(4).↩︎

21. DORA, art 30.↩︎

22. Commission Delegated Regulation (EU) 2024/1773, arts 1–7 https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj.↩︎

23. Commission Delegated Regulation (EU) 2025/532 https://eur-lex.europa.eu/eli/reg_del/2025/532/oj.↩︎

24. European Banking Authority, ‘Preparations for Reporting of DORA Registers of Information’ https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act/preparation-dora-application accessed 28 August 2026.↩︎

25. Data Act, art 50; EUR-Lex, ‘Rules on Fair Access to and Use of Data’ https://eur-lex.europa.eu/summary/ENG/4723374 accessed 28 August 2026.↩︎

26. Data Act, arts 25–27.↩︎

27. Data Act, art 29.↩︎

28. Theresa Ehlen, Gernot Fritz and Benjamin Blum, ‘Cloud-Switching unter dem Data Act: Kostenloser Wechsel in jedem Fall?’ (2025) 41(3) Computer und Recht 141 https://doi.org/10.9785/cr-2025-410307; Jan Svoboda, ‘Public Procurement and Vendor Lock-in within the Area of Data Migration’ (2022) Milan Law Review https://doi.org/10.54103/milanlawreview/18741.↩︎

29. Regulation (EU) 2024/2847 (Cyber Resilience Act), arts 14 and 71 https://eur-lex.europa.eu/eli/reg/2024/2847/oj.↩︎

30. Cyber Resilience Act, art 13 and Annex I.↩︎