Türkiye’s September E-Commerce Breaches: What to Ask Your Processor

Last updated: 28 September 2026

The September 2026 KVKK notices place processor-side systems at the center of several e-commerce breach reports. They describe unauthorized access involving service-provider systems, hosted databases or third-party software; some list stored password values or management-panel accounts among the potentially affected data.

For a retailer, the immediate question is whether its provider can explain what happened to its customers’ data, supply supporting evidence and help it respond on time. A working storefront does not answer those questions.

The notices warrant closer scrutiny of processor risk. They do not show that every named business was affected by the same attack, platform or vulnerability. Some provider relationships are publicly confirmed; others are not identified in the notices.

What changed between 16 and 23 September?

A review of the full register pages identifies 27 notices published under the Board’s 16 September 2026 decision numbered 2026/2039, followed by 15 under its 23 September 2026 decision numbered 2026/2081. These notices describe processor or service-provider involvement, although their technical detail varies.

Those are counts of notices grouped by publication decision. They are not counts of independently verified attacks. Other entries published on the same dates, including Canva and Vergi Müfettişleri Derneği, have separate publication decisions and should not be folded into the e-commerce comparison merely because they share a date.

The earlier group already contained references to processor systems, vulnerable software libraries and stored password values. The later group adds more controllers, including El Ayakkabı, Dirim and Puzmo. It also adds further examples of customers and management-panel account holders being affected within the same reported incident.

The response depends in part on what the provider can establish. Several notices leave the affected population or specific data fields unresolved. Without a reliable scope from the provider, a controller may struggle to identify whom to notify, choose account-security measures or describe the incident accurately.

Publication dates are not attack dates

Many notices say the controller discovered the breach when its processor notified it. That date must be kept separate from the date of unauthorized access, the processor’s own discovery, the controller’s notification to the Board and publication on the register.

For example, El Ayakkabı and Dirim report learning of their incidents through processor notifications on 10 September 2026. Puzmo reports 14 September 2026. All three notices were published on 23 September 2026.

There is also evidence of earlier activity. The public statements from DESA, Samsonite Türkiye and Dünyagöz Optik identify an incident period of 15–19 August 2026, with awareness on 10 September 2026. That window belongs to those statements; it cannot be assigned to every September notice. Güneş Engin’s notice, meanwhile, records processor notification on 27 August 2026.

A gap between awareness and public publication does not, by itself, prove a late notification to the Board. The filing date and the relevant awareness evidence would be needed.

Which providers are actually identified?

The KVKK summaries reviewed for the 42 notices do not name the processors. Controller statements provide some additional attribution: DESA, Samsonite Türkiye, Dünyagöz Optik and Yiğit Alışveriş identify Ticimax in their own incident disclosures.

That establishes a named provider connection for those businesses. It does not establish that every notice in both batches concerns the same provider or technical event.

For El Ayakkabı, Dirim and Puzmo, the reviewed KVKK notices identify processor or service-provider involvement without naming the organization. The evidence reviewed for this article does not establish that all three share the same incident provider. Website branding or the infrastructure used by a storefront today would not, on its own, establish which system held the affected records at the relevant time.

Linking these incidents requires evidence, such as matching provider incident references, affected environments, time windows, forensic findings or explicit confirmation. A shared publication decision is not enough.

The data fields that change the response

Names, email addresses, telephone numbers and postal addresses recur across the notices. Some include customer-account records, order information or IP addresses. The combinations differ, and a field mentioned by one controller should not be attributed to another.

Password-related descriptions also differ. Some notices say hashed passwords or hashed login information. Others refer more broadly to stored password values. Management-panel accounts appear in several disclosures, making it necessary to assess staff and administrator access as well as customer accounts.

These figures should not be added together as a total of unique people. Individuals may appear in more than one retailer’s records, some counts are estimates, and account counts are not necessarily counts of additional individuals.

“Hashed” does not settle password risk

Valmenti’s notice is the only reviewed disclosure that names a password-hashing algorithm: MD5. It describes login information in a dataset that may have been affected. The notice does not establish that other controllers used MD5.

MD5 is unsuitable for modern password storage because it permits fast password guessing. More generally, risk depends on the algorithm, its configuration, whether each password has a unique salt and the strength of the underlying passwords. A hash is not the plaintext password, but exposed hashes can enable offline guessing.

The reviewed notices do not provide a complete account of salting, work factors or password-storage configurations across the affected businesses. Nor do they establish that every affected management credential was immediately reusable or that attackers successfully took over those accounts.

Controllers should ask their providers for separate assessments of customer passwords, administrator credentials, active sessions and integration secrets. Where exposure warrants it, the response may require password resets, session invalidation, secret rotation and monitoring for misuse. The assessment should cover legacy records as well as the current login method.

This distinction matters for DESA and Samsonite. Their own statements describe login using one-time codes and a narrower set of potentially affected fields. Their KVKK summaries also list stored password values. The public documents do not explain that difference. It would be premature to conclude either that the records were harmless historical values or that current passwords were compromised.

Mehmet Salih Araç’s notice adds a different issue: payment API keys appear among the affected items. That is not proof that payment-card data were stolen. It does mean an incident review must consider integration permissions and key rotation, rather than stop at customer password resets.

What the notices establish—and what remains unresolved

The notices record controllers’ reports of unauthorized access and affected or potentially affected information. Several expressly attribute access to exploitation of a vulnerability in a third-party software library used in processor systems.

The reviewed e-commerce notices do not identify the library, its affected version or a CVE. They also do not specify an exploitation technique sufficiently to label it SQL injection, remote code execution or a malicious software update. A vulnerable dependency does not itself establish a compromise of the software’s development or distribution process.

The notices do not always say whether data were merely accessible or copied out. Access to a server or database can be established without a complete account of which records were taken. Conversely, the absence of published evidence of exfiltration does not prove that no data left the system. Where a notice says records “may have been affected,” their exposure remains uncertain.

The public record reviewed here does not establish a common attacker, complete incident overlap between the two dates or the full subprocessor chain. The notices state that examination is ongoing; the publication decisions are not final findings that particular parties breached their legal duties.

There is some public information about response measures. Dünyagöz Optik says it reset account passwords. Yiğit Alışveriş describes access restrictions, password resets and provider security measures. DESA and Samsonite describe coordinated technical work and precautions around one-time codes. These are company-reported measures, not independent verification that every route of access was closed.

Public statements also do not prove that every affected individual received a direct notification. Contact details in a regulator notice show where people can seek information; they do not establish the timing, delivery or completeness of individual notices.

Controller responsibility continues when processing is outsourced

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. Where another party processes data on the controller’s behalf, Article 12(2) establishes joint responsibility for taking the relevant security measures.

A contract can allocate operational tasks and cooperation duties. It does not remove the controller’s statutory security responsibilities. Equally, a reported breach does not automatically establish liability for every party involved; the controls, circumstances and evidence still matter.

A previous retail decision illustrates the issue. In decision 2021/1021, the Board examined security oversight and the handling of data retained by a former processor. The decision demonstrates that supplier oversight and exit arrangements can matter even after a commercial relationship ends. It is a separate historical case, not a finding about the September 2026 controllers.

In a vendor review, ask for evidence about who has privileged access, which security assessments cover the service you use, how findings are closed and what happens to customer data when the contract ends.

For another example of why supplier oversight needs a complete system map, see Kooch’s Mefa Endüstri analysis on ransomware and data inventories.

Notification terms need to work before the investigation is complete

For the breach circumstances covered by Article 12(5), Board decision 2019/10 requires controllers to notify the Board without delay and within 72 hours of becoming aware. Information that cannot initially be supplied may follow in stages without undue delay; a justified late notification must explain the delay.

Once affected individuals are identified, notification to them must follow within the shortest reasonable time: directly where contact details are available, or through suitable alternatives where they are not. Processors must inform controllers without delay when personal data they hold are unlawfully obtained.

A processor should therefore not treat 72 hours as its own waiting period. A useful contract requires prompt preliminary notice, even while the scope is being established.

For a critical e-commerce service, a controller could negotiate an initial alert without delay and an outer contractual target of, for example, four hours after the provider becomes aware of a suspected or confirmed incident affecting the controller’s data. That is a proposed commercial target, not a KVKK deadline or permission to wait four hours.

The arrangement should specify a continuously monitored contact route, the initial information required and an update cadence. It should require a clear distinction between confirmed facts, working assessments and missing evidence. Counsel should check the notification trigger and contractual wording against the actual service and applicable duties.

Secure access to forensic evidence

A provider’s statement that an issue has been fixed does not tell a controller which records were exposed. Before an incident, agree what evidence the provider will preserve and supply, who can request it and how quickly it can be made available.

The initial request should cover:

• The affected service, environment and customer tenant, with the earliest and latest known unauthorized activity.
• Relevant authentication, application, database and administrative logs, including retention gaps and time zones.
• The basis for affected-field and population estimates, and the evidence concerning viewing, extraction or alteration.
• The exposed password formats, sessions, API keys and other credentials, together with containment actions and their times.
• The root-cause assessment, remediation evidence and outstanding investigative questions.

Provide a secure route for tenant-specific extracts or independent review where a shared environment prevents unrestricted log disclosure. Preserve evidence while containing the incident, record who collected it and avoid requesting unrelated customers’ data.

Map subprocessors and software dependencies separately

A retailer needs to understand both the organizations handling its data and the software operating on it.

For the processing chain, identify hosting, managed support, backup and other parties that actually process personal data on behalf of the provider. Record their roles, access, locations and escalation routes. A software-library author is not automatically a subprocessor merely because its code is used; the relevant question is whether that party processes personal data in the service relationship.

For the technical chain, ask the provider to maintain a dependency inventory covering direct and transitive components—the libraries brought in by other libraries. Relevant records include component versions, affected deployments, vulnerability monitoring and responsibility for remediation. A software bill of materials can help, but it needs to be connected to the systems actually running the service.

Retailers buying managed software may not need every component record themselves. They do need a provider capable of answering whether a named vulnerability affects their environment and showing that the response was implemented and tested.

Assess concentration beyond the supplier list

Several storefronts can depend on the same provider, shared administration environment or underlying service. That can leave a business handling multiple affected brands while competing for the same provider’s incident-response resources.

Assess concentration by asking which stores share administration, hosting, backups and integrations; whether one privileged account can reach multiple environments; and how the provider prioritizes customers during a widespread incident. Include the time and evidence needed to recover or move the service.

Changing providers is not an automatic remedy. Migration can leave old databases, accounts and integrations behind. Any exit should include access revocation, data return and documented deletion arrangements, with legal retention and evidence-preservation needs accounted for.

A practical remediation checklist

Use the following as an operational review, with an owner and evidence requirement for each item:

• Establish your own scope. Obtain written confirmation of affected environments and records; do not infer exposure from another retailer’s notice.
• Record the chronology. Separate attack activity, discovery, processor notification, controller awareness and external notifications.
• Preserve evidence. Agree log preservation and a controlled process for obtaining findings before normal retention cycles remove relevant records.
• Assess account and integration exposure. Review customer and administrator access separately; reset or revoke credentials and sessions where justified.
• Verify containment. Request the affected component or root cause, the implemented fix and evidence that relevant deployments were checked.
• Complete the notification assessment. Use the statutory requirements and available evidence; document uncertainties and subsequent updates.
• Review the processing chain. Confirm the parties with access, onward processing arrangements and incident escalation duties.
• Check retained data and vendor exit controls. Address unnecessary historical records, dormant accounts and copies held by former providers without destroying required incident evidence.
• Exercise the response. Run a scenario in which the provider initially supplies an incomplete customer list. Test whether your team can still escalate, make decisions and communicate accurately.

The September notices give retailers a concrete reason to test what they can obtain from their processors during an incident. Start with the provider that holds customer accounts or controls store administration. Ask it to demonstrate how it would identify your affected records and deliver the evidence your team needs to act.

For a focused review of supplier oversight and incident-response arrangements, see Kooch’s KVKK & GDPR Gap Analysis. It can help turn agreed review questions into prioritized findings, owners and next steps.

Sources / References

Reviewed on 28 September 2026. The incident summaries report controller submissions; company statements are attributed disclosures.

Incident register and controller notices

• KVKK breach register, page 1 and pages 2, 3 and 4. Pagination can change as new entries are published.
• El Ayakkabı, Dirim and Puzmo: processor involvement, awareness dates, affected fields and populations.
• Valmenti: MD5 disclosure and qualified description of the dataset.
• Mehmet Salih Araç: management-panel information, stored password values and payment API keys; affected-person count not supplied.
• DESA’s KVKK notice and Samsonite’s KVKK notice: compare their descriptions of affected fields with the company statements below.

First-party company disclosures

• Dünyagöz Optik / Ademur Optik: names Ticimax, gives the August incident period and reports password resets. Its field descriptions vary within the statement; no narrower field list is used to override the regulator notice.
• DESA and Samsonite Türkiye: name Ticimax, give the August incident period and describe one-time-code login. The difference from the regulator summaries remains unresolved.
• Yiğit Alışveriş: incident statement within the page, dated 17 September 2026; names Ticimax and describes response measures. Those measures and its statement about filing on time are company assertions, not independent findings.

Legal and technical sources

• KVKK: obligations concerning data security, explaining Article 12 of Law No. 6698.
• Board decision 2019/10: breach-notification procedures, including processor escalation, the controller’s 72-hour deadline, individual notification and staged submissions.
• Board decision 2021/1021: separate historical retail case addressing processor oversight, retained data and notification content.
• OWASP Password Storage Cheat Sheet: modern password hashing, salts, work factors and the limitations of legacy algorithms.
• OWASP Vulnerable Dependency Management Cheat Sheet: direct and transitive dependencies, mitigation and verification of fixes.

For context, see Kooch’s earlier review of the first 12 retail notices, published on 21 September. That was an earlier snapshot; the 27/15 comparison here reflects later register pages.