A cybersecurity breach is no longer a problem only for large technology companies. According to the Information Technology Usage in Enterprises Survey that TÜİK (the Turkish Statistical Institute) published on 10 September 2026, 9.4% of enterprises with at least 10 employees reported at least one information and communication technology (ICT) security breach in 2025. Roughly one in every ten companies.
The legal framework also changed during the same period. Cybersecurity Law No. 7545 (Siber Güvenlik Kanunu), which entered into force on its publication in the Resmî Gazete (Türkiye's Official Gazette) on 19 March 2025, contains an obligation concerning the notification of cyber incidents. In this article we look first at the numbers, then at what the text of the law says on the subject, and finally, through an international framework, at the steps that can be followed during an incident.
What do the numbers say?
According to TÜİK data, the share of enterprises taking any security measure in their ICT systems rose from 76.0% in 2024 to 83.0% in 2026. The share rises with company size: 81.2% among enterprises with 10-49 employees, 90.5% among those with 50-249 employees, and 97.2% among those with 250 or more employees (TÜİK).
But taking precautions does not bring breaches down to zero. The share reporting at least one breach in 2025 was 9.3% among enterprises with 10-49 employees, 10.2% among those with 50-249 employees, and 8.4% among those with 250 or more employees. Although almost all large companies take security measures, roughly one in every twelve large companies still reported a breach.
Looking at the types of breach, the picture becomes more concrete (TÜİK):
- 6.4% of enterprises were unable to access ICT services because of attacks from outside.
- 5.6% experienced data loss or corruption because of malware or unauthorized access.
- 5.3% faced a breach of data confidentiality because of intrusion, fraud, phishing or deliberate actions by employees.
The fact that the most common type of breach is the inability to access services shows that a cyber incident is not just an IT issue but directly a business-continuity issue.
What does the text of the law say about notification?
This section is not a legal assessment; it is a summary of the relevant provisions of the text of the law.
Scope (Article 2): According to the text of the law, the scope is defined to include public institutions, professional organizations with public-institution status, natural and legal persons, and entities without legal personality that have a presence, carry out activities or provide services in cyberspace (Resmî Gazete). Certain intelligence and military activities are excluded from the scope.
Notification (Article 7/1-b): The law places a number of responsibilities on those within its scope who provide services through information systems, collect or process data, or carry out similar activities. One of them, in the law's own words, is "to notify the Presidency without delay of the vulnerabilities or cyber incidents they detect in the area in which they provide services". The Presidency here is the Siber Güvenlik Başkanlığı (Cybersecurity Presidency).
Who sets the details (Article 6): The law says that the Presidency will determine the procedures and principles for notifications; that it may also classify the institutions and persons within the scope; and that, where necessary, it may create provisions covering only a certain part of them. In other words, how the obligation applies to a company in practice depends not only on the law but also on the Presidency's secondary regulations.
Sanctions (Article 16): The law provides for administrative fines for those who fail to fulfill the responsibilities in the relevant sub-paragraphs of Article 7. According to the current text in the Mevzuat Bilgi Sistemi (Türkiye's Legislation Information System), this provision was amended by Law No. 7590, which entered into force on 31 July 2026 (Mevzuat Bilgi Sistemi). This shows why it matters to follow the current version of the text from the official source.
Where your company falls within the scope of this obligation may vary depending on your sector and activity. To answer this question, we recommend consulting the text of the law, the regulations published by the Presidency, and your legal counsel. This article is not a substitute for legal advice.
What to do when an incident occurs: NIST's current framework
One widely used reference for incident response is the SP 800-61 Rev. 3 guide, published in April 2025 by the U.S. National Institute of Standards and Technology (NIST). The guide replaced the earlier 2012 version and linked incident response to the six functions of the NIST Cybersecurity Framework (CSF) 2.0 (NIST).
The guide's key finding is this: incidents used to be rare, narrow in scope and able to be closed in a day or two; today they occur frequently and do more damage, and recovery often takes weeks or months. For this reason, incident response is treated not as occasional work done by a separate team but as a process spread across the whole of risk management.
The NIST model is divided into two layers:
1. Preparation (Govern, Identify, Protect): Not incident response itself, but the broad risk-management work that makes it possible. Defining roles in advance is critical here. The guide lists senior management, the incident response team, technology specialists, legal, corporate communications, human resources, physical security and asset owners among the possible roles. It recommends that the sharing of responsibility with external service providers be clearly defined in the contract.
2. Response (Detect, Respond, Recover): The steps taken at the time of an incident. The notable recommendations in the guide:
- Verify and prioritize: Put an incoming report through preliminary review to confirm whether it is really an incident, then estimate its severity and urgency. Consider assigning an owner for each incident.
- Measure the scope: According to the guide, determining the size of an incident is one of the hardest aspects of response; if it is done superficially, the incident may continue unnoticed in other systems.
- Keep records: Record the actions taken and the data collected in a way that preserves their integrity. Even though not every incident ends up in court, the data collected can serve as evidence.
- Contain and eradicate: First stop the spread (isolation, quarantine), then remove persistence mechanisms and entry points.
- Notify and communicate: The guide stresses that notifications should comply with the legislation applicable to the organization's sector and to the geographies where it and its customers are located, and that this area is constantly changing. It recommends writing down in a procedure, in advance, whom to notify, what to notify and when.
- Recover and learn: Return systems to normal, verify that they are working, and share lessons learned at the moment they are noticed, before the incident is over.
This last item reflects an important change: in the previous model, lessons were compiled after the incident, whereas in the new model continuous improvement is spread across all functions.
Checklist for managers
To bring the picture that emerges from these sources onto the management agenda, the following questions can be a starting point:
- Do we have a written incident response plan, and when did we last run an exercise?
- Who holds decision authority during an incident; who makes high-impact decisions such as shutting systems down?
- Is the sharing of responsibility during an incident with our external service providers (cloud, network, security) written into the contract?
- Have we clarified with our legal department whom we must notify, and when, under Law No. 7545 and other legislation?
- Is our business continuity plan up to date for a service-disruption scenario?
From Orient Global's perspective
The quality of incident response is largely determined before an incident begins: organizations whose roles, authorities and notification flow have been written down in advance can act faster and more consistently. For that reason, a practical starting point could be to compare the existing plan against a framework such as NIST, clarify notification obligations together with the legal department, and test the plan with at least one tabletop exercise a year.
Why logistics experience matters here. The most common breach type in the TÜİK data is loss of access to ICT services, and in a logistics operation that means orders, stock and shipments can stop moving. One of our consultants brings more than 30 years in operations, logistics and supply chain: at a technology distribution company of roughly one billion dollars in scale, he ran logistics, warehousing, technical service and administrative operations end-to-end, building and leading teams of 100+ people and delivering lasting gains through KPI-driven programs. He has also managed nationwide warehouse and transport operations, large-scale distribution networks, and network and capacity planning at leading retail, logistics and distribution organizations. An industrial engineer, he now brings that supply-chain discipline to SMEs through AI and automation. Meet our consultants.
#interimmanagement #forwarddeployedengineering