Four Turkish companies reported remarkably similar personal data breaches: unauthorized access to a server in a processor’s systems, exposure involving identity and contact information, hashed login details, and an affected population that had not yet been established.
The disclosures raise a practical question for any business using an outsourced platform: could you assess and respond to a breach if the most important evidence sits with your supplier?
The four notices do not identify the processor or establish that a single incident affected all four companies. A common provider remains an unconfirmed inference. Their shared features nevertheless make a useful starting point for reviewing processor contracts, technical safeguards and incident readiness.
On 9 September 2026, Türkiye’s Personal Data Protection Authority published notices concerning Bo Kozmetik, Dekonil, Çiçek İç Giyim and Suud Tekstil. Each summarizes a controller’s breach report while examination continued; the publication decisions are not final findings of fault or announcements of fines.
Across the four reports, the recurring facts are:
The dates in the table are the reported processor-to-controller notification dates. They do not establish when unauthorized access began, when the processor discovered it, or when each controller submitted its notification to the Board.
Nor does the list of data types establish that every field was exposed for every person. In particular, “identity information” should not be rewritten as “national identity numbers”: those numbers are not specified in these four notices.
A shared supplier or infrastructure incident is one possible explanation for the similarities. Other possibilities include separate incidents described through standardized reporting language. The public summaries do not resolve that question.
The pattern also extends beyond these four disclosures. Notices published on 2 September 2026 for FF Tekstil and Vitaberg Kozmetik describe similar processor-server access and affected-data categories. Their existence supports discussing a broader pattern of reports, but does not establish that they share the same compromised infrastructure.
As of this article’s update, the primary materials reviewed did not establish:
Contact channels in a public announcement show where people can seek information. They do not prove that individual notifications have been completed. Equally, not finding a public record of direct notification does not prove that none was sent.
These limits matter when describing the incident: “hashed login information was listed as affected” is supported; “plaintext passwords were stolen” is not. The notices also do not establish that access was limited to viewing or that no exfiltration occurred.
A controller determines the purposes and means of processing personal data. A processor handles personal data on the controller’s behalf under its authorization. The actual activity determines the role; a supplier may have different roles for different processing operations.
Article 12 of Law No. 6698 requires appropriate technical and organizational measures to prevent unlawful processing and access and to protect personal data. When processing is outsourced, the controller and the party processing on its behalf are jointly responsible for taking the measures specified in Article 12(1).
This does not make them joint controllers or allocate every possible liability identically. It means outsourcing does not remove the controller’s security responsibilities. The controller also has an audit obligation, while both controllers and processors are subject to restrictions on unauthorized disclosure and use.
Operationally, assign owners for supplier review, access approval, incident escalation and remediation. A contract saying that the vendor “handles security” leaves too much unresolved.
Hashing is a protective measure, not a guarantee that exposed credentials are harmless. If password hashes are obtained, an attacker may test guesses offline. The algorithm, cost settings, password strength and implementation influence how practical that becomes.
Unique salts make precomputed attacks and bulk guessing less effective. Salts normally accompany stored hashes and are not intended to be secret; their presence alone is not a design failure. A separately protected secret, often called a pepper, serves a different purpose.
The four notices do not identify the credential-storage design. A controller should request the algorithm, settings, treatment of older accounts and exact fields in the affected dataset before making assurances.
Recommended response questions include:
These are investigation and containment options, not findings about the four companies. Resetting a password also cannot recover already disclosed contact details.
Under Decision 2019/10, a processor must notify the controller without delay when personal data in its custody have been unlawfully obtained by others. The controller must notify the Board without delay and no later than 72 hours after learning of the breach. Incomplete information can be supplied in stages without delay; late notification requires an explanation.
After affected individuals are identified, they must be notified within the shortest reasonable time, directly where contact details are available, or through suitable alternatives where they are not. This is not a separate blanket 72-hour deadline for individuals.
A contract should make rapid escalation workable. For a critical platform, consider the following illustrative contractual targets, adapted to the service and reviewed with counsel:
These example targets are recommendations, not statutory KVKK time limits or permission to wait. Provide a monitored emergency route, backup contacts and an acknowledgement process. Define elapsed hours, including weekends, and test the escalation path.
Avoid clauses that allow the processor to wait for its final report, a confirmed headcount or marketing approval before alerting the controller.
Concentration risk arises when several important business functions depend on the same underlying service or privileged access path. Separate supplier names do not necessarily mean independent infrastructure.
For example, a retailer might use different agencies for its storefront, customer support and order integration while all three depend on one platform account. That is an illustrative scenario, not an established feature of these cases.
Ask the provider which boundaries limit a compromise:
A shared platform is not inherently unsuitable. The assessment should establish how access is separated and how the provider would support multiple customers during the same incident.
A processor may rely on hosting providers, support contractors or other organizations to deliver its service. Map which parties actually process personal data; do not label every commercial supplier a subprocessor automatically.
For relevant downstream providers, request the legal entity, function, data involved, hosting and support locations, access permissions and notification route. Assess any cross-border implications separately.
As a contractual safeguard, agree how changes will be communicated and reviewed. Require the primary processor to coordinate downstream evidence and incident updates so the controller does not have to chase an unknown chain of suppliers.
This is a recommended control arrangement. Specific approval and contract requirements depend on the applicable legal framework and processing; GDPR provisions should not simply be presented as identical KVKK rules.
A supplier’s general assurance that “the issue is contained” rarely answers the controller’s essential questions: whose information was exposed, what happened to it, and what evidence supports that conclusion?
Agree access to relevant authentication, administrator, database, export and security logs. Require timestamps and time zones, a record of preservation, and an explanation of coverage gaps. Protect the logs themselves and avoid recording plaintext passwords or usable tokens.
Evidence access need not mean unrestricted access to other customers’ data. Customer-specific extracts, appropriately redacted reports and independent forensic validation can be designed into the contract.
Ask the investigator to distinguish observed access, confirmed copying, plausible exposure and activity that cannot be determined. Missing logs limit confidence; they do not establish that no data left the environment.
The provider’s findings should feed the controller’s decision process. They should not substitute for it.
Create a working assessment with five parts:
Do not assume that an unknown headcount prevents an initial notification. Conversely, do not describe every security alert as a proven personal data breach. Where the facts or legal trigger remain disputed, obtain prompt legal assessment while investigation and necessary protective action continue.
For organizations subject to more than one jurisdiction, assess each applicable notification regime separately. One report or one supplier’s legal conclusion should not be assumed to cover every obligation.
A processor breach does not automatically make immediate migration the best response. An unplanned exit can interrupt services, lose evidence or move compromised information into a new environment.
Establish decision criteria for continued use, restricted use or migration. Relevant questions include whether unauthorized access has been contained, whether credible evidence is available and whether the provider can deliver agreed remediation.
A usable contingency plan should identify:
Keep forensic evidence appropriately protected before routine deletion or contract termination. Test whether the business can operate with reduced supplier access instead of relying on an untested promise of a rapid switch.
Use these questions at onboarding, renewal and material service changes. For each item, record the evidence reviewed, remaining gap, owner and next review date.
A completed questionnaire is only the beginning. For critical services, ask the provider to demonstrate an incident handover, a customer-specific log extract and a usable data export. These exercises expose practical gaps that general assurances may miss.
The four disclosures show why processor oversight needs to reach beyond a signed contract. Controllers need a reliable route to timely information, usable evidence and decisions about the people whose data may be affected.
Whether these reports ultimately prove to share a provider remains unconfirmed in the reviewed primary material. Businesses can still act on the operational lesson: map outsourced processing, test escalation and evidence access, and make recovery and exit plans usable before they are needed.
Kooch’s KVKK and GDPR Gap Analysis can review agreed vendor controls, data flows, security evidence and incident processes, with prioritized findings and proposed remediation owners. Questions requiring legal interpretation are escalated to the client’s counsel.
Primary materials checked on 16 September 2026. The incident notices summarize controller reports; they should not be read as final forensic or liability findings.
