Supplier Data Breaches and KVKK: Managing Your Software Vendor

Supplier data breaches: who is left holding the responsibility?

When someone gains unauthorized access to a server run by the software, hosting or support vendor that holds your customer data, the resulting data breach is still your breach under Türkiye's Personal Data Protection Law (KVKK). Article 12 makes the data controller jointly responsible for the security measures that must be taken at the processor, and the duty to notify the Personal Data Protection Board and the affected people also sits with the controller.

This article covers why supplier-caused breaches happen, the respective duties of controller and processor, the clauses your contract needs, the technical controls that reduce risk, and how to run the first 72 hours after a breach. It ends with ten questions to ask your software vendor. This is not legal advice; work with your legal counsel on your specific situation.

In short

• Under KVKK Article 12(2), when data is processed on the controller's behalf by another person, the controller is jointly responsible with that person for the security measures.
• Under Board decision 2019/10, a breach must be reported to the Board within 72 hours of the controller learning of it; that window shrinks if the vendor tells you late.
• Of 33 breach notices published on 2 September 2026, 22 described unauthorized access to a server in a data processor's systems.
• Contracts need a breach-notice SLA, a sub-processor list, audit rights and deletion on termination; technically you need least privilege, MFA and central logging.
• Ask for evidence, not policy text: access logs, a penetration test summary and the sub-processor list are verifiable.

What happened on 2 September 2026?

The breach notification page of Türkiye's Personal Data Protection Authority lists 33 notices dated 2 September 2026. Twenty-two of them describe unauthorized access to a server in the data processor's systems that held the controller's data. The related Board decisions are dated 2 September 2026 and numbered 2026/1881 to 2026/1902.

Most of these notices state that the processor informed the controllers of the breach on 27 or 28 August 2026. The affected data categories were first and last name, email, address, phone and hashed login credentials, and the notices say the number of affected people and records could not be determined precisely. The processor is not named.

What does this picture tell us?

A single incident at a single vendor forced dozens of unrelated companies to file notifications at the same time, each under its own name in its own public notice. Vendor selection and management is therefore not just a procurement topic; it is a direct KVKK and reputation issue.

The picture also shows how tight the timing is: only a few days passed between the processor's notice and the Board decisions. In that window every controller had to identify the affected data categories, decide and complete the notification form. Without a prepared incident response plan and an agreed channel with the vendor, that window is very narrow.

Why do supplier-caused breaches happen?

Most supplier-caused breaches come not from sophisticated attacks but from a handful of recurring weaknesses. The four patterns below are the topics to probe most often in vendor assessments.

Shared credentials

A single admin account used by the whole support team, or a common password for accessing customer environments, enlarges the attack surface and leaves "who did what" unanswerable after an incident. API keys sitting in a code repository or on a wiki page carry the same risk.

Over-privileged support access

A vendor's support account can often reach every customer's data, at any hour, with no expiry. When such an account is compromised, the blast radius is never limited to one customer. The multiple notices on 2 September are a concrete picture of that risk.

Unpatched systems

Internet-facing admin panels, outdated operating systems and components with known vulnerabilities are risks in the vendor's infrastructure that you cannot see. That is why asking for an SBOM (software bill of materials) and a patch SLA matters: you need to know which component runs which version.

Invisible sub-processors

Your software vendor also buys cloud, email, logging, backup or call-centre services from other firms. If these sub-processors are not listed in the contract, you cannot know where your data sits or who can reach it.

Controller and processor: what does KVKK Article 12 say?

Under KVKK, the data controller determines the purposes and means of processing personal data; the data processor processes data on the controller's behalf based on the authority it is given. Software, hosting and maintenance vendors are usually processors.

Joint responsibility (Article 12(2))

The law is explicit: where personal data is processed on its behalf by another natural or legal person, the controller is jointly responsible with that person for taking the measures set out in the first paragraph. Those measures are the technical and organisational steps needed to prevent unlawful processing and access and to safeguard the data. Paragraph 3 obliges the controller to carry out or commission audits, and paragraph 4 keeps confidentiality obligations in force after people leave their roles.

Responsibility cannot be contracted away

The Authority's "common misconceptions" publication makes the same point: handing security obligations to a vendor by contract does not remove the controller's responsibility. A contract is a tool for defining measures and collecting evidence, not for transferring liability.

The duty to notify (Article 12(5))

If processed data is obtained by others unlawfully, the controller must notify the data subject and the Board as soon as possible. Under Board decision 2019/10 of 24 January 2019, that means within 72 hours at the latest of learning of the breach, and data subjects must be notified within the shortest reasonable time. Board decision 2025/2451 of 25 December 2025 capped how long breach notices stay published at 60 days; a notice can come down earlier if the controller documents that it has notified the data subjects.

Which clauses belong in the vendor contract?

A data processing agreement (DPA) puts in writing why, where and under which safeguards the vendor processes your data. The table below summarises the key clauses and the evidence you can request. Values such as the notice deadline are not in the law; they are internal targets you set so you can still meet the Board's 72-hour window.

Clause / control	Why it matters	Evidence to request
Data processing agreement (DPA)	Purpose, data categories and safeguards are written down	Signed DPA with a data inventory annex
Sub-processor list and approval clause	You know who holds your data and in which country	Current sub-processor list, change notification process
Breach-notice SLA (e.g. 24 hours)	Leaves time for analysis and decisions inside the 72-hour window	Incident response procedure, contact list
Audit rights	Lets you meet the audit duty under Article 12(3)	Audit report or independent audit summary
Encryption in transit and at rest	Makes stolen data harder to read	Description of encryption and key management
Access logs and retention period	Shows who accessed what after an incident	Sample log entry, retention commitment
Return and deletion on termination	Data does not stay with the vendor once the relationship ends	Deletion record or destruction certificate
Penetration test reports	Shows known vulnerabilities have been closed	Executive summary of the latest test and remediation status
SBOM and patch SLA	Lets you know quickly whether a critical vulnerability affects you	Current SBOM, critical-patch timeline commitment

Which technical controls reduce breach risk?

Contract clauses only become real through technical controls. The controls below are the minimum set to require from vendors and to apply in your own systems.

Least privilege and time-bound support access

Support access should use named accounts, reach only the relevant customer environment and be granted just in time, closing automatically when the work is done. Our article on RBAC access model design is a good starting point for role design.

MFA and single sign-on

Admin panels and support tools should be protected with multi-factor authentication. We cover session security for customer portals in detail in SSO and session security in customer portals.

A secrets vault

API keys, database passwords and certificates belong in a secrets vault, not in code or documents, and should be rotated regularly and after every incident.

Central logging and alerting

Access to personal data, permission changes and bulk exports should be logged centrally, with alerts for unusual volumes or out-of-hours access. Without logs, you cannot even establish the scope of a breach.

Data minimisation and environment separation

Give vendors only the data the work requires. Test and development environments should use masked data, never live data. The same rule applies to data sent to AI services; our article on a KVKK-aware AI Ops layer covers this.

Where should you start reviewing existing vendors?

In most companies the vendor list is scattered across procurement, IT and business units. The first step is to collect every vendor that touches personal data into one list: software and SaaS providers, hosting firms, maintenance and support teams, call centres and marketing agencies.

Prioritise by risk

Score each vendor on three questions: which data categories does it access, how many people's data, and is the access permanent or time-bound? Vendors with permanent access to special-category data or to the whole customer base go to the top of the list and are assessed first.

Verify access technically

What the contract says and what the systems show often differ. Pull vendor accounts from identity management and VPN records and close unused, shared or non-expiring accounts. That single exercise often removes the biggest risk.

What should a vendor's breach notice contain?

Define the content of the notice in the contract, not just its deadline: when the incident was detected, affected systems, data categories, estimated number of people and records, first containment steps and the vendor's contact person. That information becomes the skeleton of your own notification to the Board.

How do you run the first 72 hours after a breach?

The 72-hour clock starts when the controller learns of the breach. The later the vendor tells you after spotting the incident, the less time you have for analysis and decisions. That is why the timeline should be written in advance and tied to the notice SLA in the contract.

• T0 (awareness): Open an incident record, bring in the decision-maker and the KVKK contact person, and request a written incident report from the vendor.
• T0 + 24 hours: Cut vendor access if needed; rotate the relevant keys, passwords and tokens; preserve logs and images as evidence.
• T0 + 48 hours: Run the impact analysis: which groups of people, which data categories, roughly how many records.
• No later than T0 + 72 hours: Notify the Board. If some facts are still unknown, state them with the reason and complete them later.
• Afterwards: Notify data subjects within the shortest reasonable time, run a root-cause analysis and revise the contract and controls.

The Authority's video on technical and organisational measures (in Turkish) helps teams build a shared vocabulary:

10 questions to ask your software vendor

Use these questions when selecting a new vendor and in the annual review of existing ones. Ask for evidence with every answer:

1. Who can access our data, with which accounts and under what conditions?
2. Is support access named, time-bound and protected with MFA?
3. Who are your sub-processors, in which countries is our data stored, and how do you tell us about changes?
4. When you detect a breach, within how many hours, through which channel and with what information will you tell us?
5. Do you keep logs of access to personal data, how long are they retained and can you share them with us?
6. Is data encrypted in transit and at rest, and who manages the keys?
7. When was your last penetration test, and have critical findings been closed?
8. Can you share your software's SBOM, and within how many days do you apply critical patches?
9. Is live personal data used in your test and development environments?
10. When the contract ends, how do you return and delete our data, and how do you document it?

Incident response: define roles and contacts in advance.

Secrets belong in a vault, not in code.

Vendor audits: ask for evidence, not policies.

How Aksiyon Soft can help

For the systems we build and maintain, Aksiyon Soft answers these questions in writing, with evidence. On a new project, work starts with discovery: we map the data inventory, access model and vendor chain. We then build an MVP with role-based access, logging and alerting, move forward with two-week sprint demos, and provide hypercare and SLA-backed support after go-live.

For existing systems, our maintenance and support service can take over access, logging and patching processes; for new needs we deliver enterprise software solutions. For roles and permissions we use our role-based enterprise management and self-service solution. Before an assessment, you may also find our pre-security assessment checklist useful. We are headquartered in Samsun, work remotely across Türkiye and make planned on-site visits when needed.

Frequently asked questions

Who notifies the Board about a data breach at our vendor?

The duty to notify sits with the controller. In the 2 September 2026 notices, each controller filed under its own name for a single incident at the processor. The vendor's job is to give you fast and complete information.

When does the 72-hour window start?

Under Board decision 2019/10, the clock runs from the moment the controller learns of the breach. When the vendor tells you is therefore critical; a notice deadline in the contract reduces that risk.

Can we notify before all the facts are clear?

Yes. If some information is still unknown within 72 hours, you can state it with the reason and complete it later. The 2 September notices themselves said the number of affected people could not be determined precisely.

Is writing "the vendor bears all responsibility" in the contract enough?

No. KVKK Article 12(2) provides for joint responsibility, and the Authority states that responsibility cannot be transferred by contract. Use the contract to define measures, demand evidence and govern recourse between the parties.

Is it realistic to ask a small software vendor for this much evidence?

The form of evidence can scale; a penetration test summary or a sample log entry may be enough instead of an independent audit report. What matters is that each claim can be verified.

How long does a breach notice stay published?

Under Board decision 2025/2451, no more than 60 days. It can come down earlier if the controller documents that it has notified the data subjects.

Sources

• Personal Data Protection Authority (KVKK) — Public announcement on breach notifications and their publication (20 Jan 2026, Turkish)
• Personal Data Protection Authority (KVKK) — Data breach notifications (notices of 2 Sep 2026, Turkish)
• Personal Data Protection Authority (KVKK) — Obligations regarding data security (Article 12, Turkish)
• Personal Data Protection Authority (KVKK) — Common misconceptions about personal data protection (PDF, Turkish)
• CyberArts — KVKK agenda: compliance deadlines, regulations and 33 data breaches (9 Sep 2026, Turkish)

Let's talk about your project

If you want to review your software vendors' access model, map your contract and evidence list to the technical side, or add logging, MFA and role-based access to an existing system, get in touch with us. In a first call we will sketch your vendor chain together and pinpoint the three riskiest points.