The September Turkish Retail Breach Wave: What 12 KVKK Notices Reveal

Last updated: 2026-09-21

Twelve data breach notices appeared on Türkiye’s data protection authority’s website on 16 September 2026. The affected-person counts disclosed in 11 of them add up to 10,218,802. The twelfth notice did not yet have a confirmed count.

The total does not establish how many unique people were affected: someone with accounts at several affected businesses may appear more than once. Nor do the notices establish that one incident affected all 12 organizations.

All 12 notices involve data processors, and seven mention vulnerabilities in third-party software libraries. Retailers and technology providers need to be able to establish what happened to customer data when a supplier holds the systems and evidence.

What was published on 16 September?

The notices cover businesses in retail, clothing, cosmetics, coffee and food-related activities. Each summarizes a notification submitted by a data controller. All refer to a processor, although the descriptions of the affected systems vary in detail.

Each notice cites the Board’s decision of 16 September 2026, numbered 2026/2039, authorizing publication while the investigation continues. This is a publication decision, not a final finding that a particular company breached its security obligations.

The comparison below preserves the differences between reported exposure and possible exposure. Organization names are shortened for readability.

The total of 10,218,802 is the arithmetic sum of the 11 available counts. It excludes İnternet Tekstil, whose affected population was still undetermined. It should be described as the sum of reported affected-person counts, not as the number of unique victims or stolen records.

The Eve Kozmetik notice also limits the organizational scope. Although Eve Mağazacılık had merged into Yeni Mağazacılık, their systems remained separate, and the notification identifies only Eve Kozmetik customers as affected. Extending that finding to every customer of the merged business would overstate the notice.

Separate publication, discovery and incident dates

The shared publication date does not tell us when unauthorized access began.

Nine notices give a controller discovery date tied to a processor’s notification: İnternet Tekstil on 9 September; Shaya Mağazacılık, Shaya Kahve, Haşema, Deniz Deniz Butik, Yiğit, Eve Kozmetik and Valmenti on 10 September; and Back and Bond on 11 September. The notices for Taşkınırmak, Mersin Mana and İyileştiren Mamuller do not state that date.

The underlying access periods are not stated in the 12 KVKK summaries. However, Eve Kozmetik’s own customer announcement dates its provider’s security incident to 15–18 August 2026. It says names, telephone numbers and email addresses were subject to unauthorized access. It also states that order history, credit-card information and payment information were unaffected, that unauthorized access was blocked, and that security measures were taken and legal processes initiated.

Those are Eve’s statements about its incident. They do not establish the incident dates, excluded data or remediation status of the other organizations.

The public chronology also cannot establish whether anyone notified late. That assessment needs the provider’s discovery time, the controller’s actual awareness time, the information available then, and the time the Board received the notification. The date KVKK publishes a notice is not the date the controller submitted it.

Do the notices identify a common provider or vulnerability?

Seven notices explicitly describe a third-party software library vulnerability: Haşema, Deniz Deniz Butik, Back and Bond, Yiğit, Eve Kozmetik, Mersin Mana and İnternet Tekstil.

The other five refer to unauthorized access and processor involvement without specifying a software library as the cause.

None of the 12 KVKK summaries names the processor, library, affected version or vulnerability identifier. The primary material reviewed for this article does not establish a shared provider or shared infrastructure across the organizations.

Similar wording and closely grouped notification dates are reasons to investigate a possible connection. They are insufficient to prove one. Even if two businesses use the same technology supplier, that alone would not establish that the same environment, flaw or intrusion affected both.

There is another technical distinction. Exploiting a vulnerable third-party library is not, by itself, proof that an attacker compromised the library’s publisher or inserted malicious code into a software update. The notices support discussion of software dependency risk; they do not establish a common software supply-chain attack.

For a controller seeking answers, the next request should be specific: which legal entity processed the data, which service and environment were affected, what component failed, and what evidence connects that failure to this controller’s records?

What data was affected and what remains uncertain?

Names and contact information recur throughout the notices. Several also identify postal addresses, passwords or login information. The Shaya notices include employees as well as customers. Taşkınırmak lists employees, subscribers or members, customers and prospective customers, and includes management-panel account information.

These distinctions change the response. A customer contact list calls for a different assessment from a dataset containing administrative account information.

Authentication information needs its own assessment

Eight notices include passwords or login information within the affected or potentially affected data. Most describe hashes. Yiğit refers to password values stored in the database without specifying their protection. Valmenti explicitly identifies MD5-hashed login information in a potentially affected dataset.

A hash is not a guarantee that a password is safe. Attackers who obtain password hashes can test guesses offline. The hashing algorithm, salt, computational cost and password strength affect how difficult that is. MD5 is not an appropriate modern password-storage method.

Where authentication data may have been exposed, the response should assess password resets, session invalidation, account monitoring and migration away from weak password storage. Administrative accounts need separate attention. The notices do not establish that passwords were successfully cracked or that management accounts were subsequently used.

Unauthorized access does not establish the full extent of copying

The notices describe unauthorized access. They do not provide a complete forensic account of which records were viewed, queried, downloaded or transferred elsewhere.

Valmenti and İnternet Tekstil use qualified language about potentially affected information. Mersin Mana confirms certain categories but says it requested further information from the processor to establish whether addresses were also affected.

For communications, preserve those distinctions. Explain what is confirmed, what may have been accessible, and what remains under investigation. Do not turn “potentially affected” into “all records stolen,” or an absence of published exfiltration evidence into an assurance that no data left the environment.

Controller and processor responsibilities continue after outsourcing

Under Article 12 of Law No. 6698, controllers must take appropriate technical and organizational measures to prevent unlawful processing and access and to protect personal data. When another party processes data on their behalf, the controller and that party are jointly responsible for taking the required security measures. Controllers also have audit obligations.

A supplier contract should give the controller a workable way to obtain assurance, investigate incidents and act on findings. Outsourcing a platform does not remove the controller’s security obligations.

The breach-notification rules distinguish the parties’ roles. A processor must notify the controller without delay when personal data it holds is unlawfully obtained. The controller must notify the Board without delay and no later than 72 hours after learning of the breach. Where all required information is unavailable, it may be provided in stages without delay; an overdue notification must explain the reasons.

Once affected individuals are identified, they must be informed within the shortest reasonable time. Direct communication is required where contact details are available; suitable alternatives, such as a website announcement, apply where they are not.

The statutory duties and timing should be translated into operating procedures with qualified Turkish counsel where the notification threshold, awareness date or allocation of responsibility is disputed.

Make notification SLAs usable during an incident

A service-level agreement that merely gives a processor “72 hours to notify” can consume time the controller needs for its own response. The processor’s applicable obligation is notification without delay.

Require an immediate initial alert and agree a short maximum period for escalation. The contract should make clear that the provider must report sooner when it can. For a critical customer-data platform, the parties might agree an initial alert within four hours of awareness of a suspected incident affecting the controller’s data. Four hours is an example contractual target, not a general KVKK deadline.

Define the trigger carefully. A vendor should not wait for a completed forensic report before raising a credible incident. The initial alert should identify the affected service, known facts, immediate containment and an incident contact, with unresolved questions clearly marked.

The agreement should also specify update frequency, out-of-hours contacts, escalation if the named recipient does not respond, and how subcontractors feed information into the process. Test whether those contacts actually work.

Secure access to evidence before you need it

The controller needs information specific to its data. A general statement that a platform is secure again cannot answer which customers require notification or whether administrative credentials need to be replaced.

Agree in advance how the provider will supply:

• A timeline separating first suspicious activity, provider discovery, controller notification and containment.
• The affected services, environments, customer datasets and known access paths.
• Relevant logs and findings distinguishing access, queries, exports and confirmed transfers, including gaps in logging.
• An explanation of the counting method and the treatment of duplicate or historical accounts.
• Details of credential exposure, patching, access revocation and checks for continued unauthorized access.

Evidence access need not mean unrestricted access to another customer’s data or an entire shared platform. Secure extracts, independent forensic findings and agreed confidentiality arrangements may provide the necessary detail. The contract should prevent those arrangements from becoming an avoidable delay.

Mersin Mana needed further information from its processor to establish whether addresses were affected.

Review software dependencies and vendor concentration

For critical platforms, ask who tracks third-party components, evaluates relevant vulnerabilities and confirms that fixes reach production. A software bill of materials lists the components in a system and can help identify dependencies. Assign someone to assess relevant vulnerabilities and verify that affected deployments have been checked.

Look beyond the direct supplier. Several providers may depend on the same hosting environment, software component, administrative service or subcontractor. Conversely, a single supplier may operate separately controlled environments. Assess the actual dependency before deciding whether diversification would reduce risk.

Useful review questions include:

• Can one privileged account reach several brands’ customer databases?
• Are production systems separated from exports, test copies and historical databases?
• Which shared services could affect several business functions at once?
• Can the business retrieve essential records or contact customers if its main platform is unavailable?

These are risk-review questions, not findings about the architecture behind the September notices. A current website footer or platform logo is not sufficient evidence of which supplier held the affected data when an incident occurred.

Reduce the customer data exposed to each system

The published counts do not establish how much data was historical or whether any controller retained it unlawfully. Review how much personal data each system could expose.

Under the KVKK framework, personal data must be erased, destroyed or anonymized when the reasons requiring its processing no longer exist. Retention decisions must also account for applicable legal obligations and justified preservation needs.

A useful review separates active customer accounts, accounting records, marketing contacts, support records, exports and backups. Each needs a defined purpose, access model and retention decision. A requirement to preserve an invoice does not automatically justify leaving every associated profile field or old login credential in an internet-facing system.

Include suppliers and former suppliers in the review. Confirm what they retain after migration, how deletion instructions reach subcontractors, and what happens when a backup is restored. Obtain evidence that the agreed process operates.

During an incident, preserve the evidence needed for investigation before carrying out routine deletion. Data minimization should not erase the logs needed to determine the scope of a breach.

What is known about notifications, remediation and final findings?

Many of the KVKK summaries provide a contact channel through which individuals can obtain information. That is not proof that every affected person received a direct notice. İyileştiren Mamuller refers to information through email and SMS, but its summary does not establish completed delivery to every affected person. Eve has a public customer announcement; the reviewed material does not establish the full extent of direct notification.

Eve reports blocked access and further security measures. The 12 KVKK summaries do not set out a complete remediation programme, patch identifier, forensic closure report or verification of effectiveness for each organization.

All 12 summaries state that examination is continuing. No final merits finding on these incidents was identified in the official material reviewed as of 21 September 2026. Publication should not be presented as proof of a fine, an established security failure attributable to a named supplier, or regulatory acceptance of the remediation.

A remediation checklist for retailers and their providers

The following checklist is recommended operating practice. It does not imply that the named organizations omitted these measures.

• Establish scope: identify the controller, processor, affected service, data categories and people, with confirmed facts separated from hypotheses.
• Preserve the chronology: record event times, each party’s awareness, escalation and notification decisions, including the supporting evidence.
• Contain access: close the identified route, review privileges and address exposed credentials or sessions where relevant.
• Obtain evidence: secure appropriate logs and forensic findings, and document what unavailable evidence prevents you from concluding.
• Assess notification: evaluate the Board and individual-notification duties promptly, provide staged updates where needed and keep delivery records.
• Check the fix: verify the affected deployment was remediated and assess whether unauthorized access could continue through another route.
• Reduce unnecessary exposure: review historical accounts, weak password hashes, exports and supplier-held copies after evidence-preservation needs are addressed.
• Test the supplier process: exercise escalation, evidence delivery and customer communications using a realistic incident scenario.

Review your processor arrangements

Start with your main customer-data platform: identify who holds the data, how much is retained, how quickly an incident reaches your team and what evidence the provider can supply.

Kooch’s KVKK & GDPR Gap Analysis and Ongoing Compliance Services can help turn those questions into a prioritized improvement plan, with clear owners, supplier-review requirements and incident procedures. If your customer platform is outsourced, start by reviewing the processor relationship and testing whether your team can obtain the information it would need during a breach.

Sources / References

Sources checked on 21 September 2026. Incident details come from the controller notifications summarized by KVKK and Eve’s customer announcement. The operational recommendations are Kooch’s analysis.

• Publication date and notice set: KVKK breach register.
• Shaya Mağazacılık: KVKK notice.
• Shaya Kahve: KVKK notice.
• Haşema: KVKK notice.
• Deniz Deniz Butik: KVKK notice.
• Back and Bond: KVKK notice.
• Yiğit Alışveriş Merkezleri: KVKK notice.
• Yeni Mağazacılık / Eve Kozmetik: KVKK notice.
• Valmenti: KVKK notice.
• Taşkınırmak Giyim: KVKK notice.
• Mersin Mana: KVKK notice.
• İyileştiren Mamuller: KVKK notice.
• İnternet Tekstil: KVKK notice.
• Eve’s incident dates, excluded data and reported containment: Eve customer announcement.
• Security obligations and controller–processor responsibility: KVKK explanation of Article 12.
• Breach notification timing, processor escalation and staged reporting: Board Decision 2019/10, dated 24 January 2019.
• Erasure, destruction and anonymization: KVKK official explanation.
• Password hashing risks and remediation: OWASP Password Storage Cheat Sheet.
• Supply-chain risk assessment background: NIST SP 800-161 Rev. 1, updated November 2024. This is technical guidance, not Turkish law.