Do you know which country's servers your organization's security event logs are currently stored on? Most security teams cannot give a clear answer to this question. While looking at the alert dashboard on the SOC screen, questioning where that data physically passes through and which legal jurisdiction it falls under isn't usually the first thing that comes to mind. Yet the legislation that has come into force one after another in Turkey over the past two to three years has turned this question from a matter of idle curiosity into a direct compliance and penalty risk.
The vast majority of organizations in Turkey run their security operations through well-established, capable foreign SIEM platforms with strong documentation, such as Splunk, IBM QRadar, and Microsoft Sentinel. This preference is understandable: the products are mature, the integration ecosystem is broad, and training material is abundant. But beneath this convenience lie three layers of risk that are often never put on the table when the purchasing decision is made: personal data protection legislation, data localization requirements, and supply chain security. All three are now too intertwined to be considered independently of one another.
What's interesting is this: all three of these risk layers have strengthened one after another within the last twenty-four months. KVKK's cross-border transfer regime changed in June 2024, Turkey's first comprehensive cybersecurity framework law came into force in March 2025, and the official list of critical infrastructure sectors was announced in May 2026. This is not a coincidence; data sovereignty and domestic capacity are no longer treated as separate agenda items but as different facets of the same strategic priority.
Why is SIEM talked about so much?
SIEM (Security Information and Event Management) is a security layer that collects and correlates logs from dozens of different sources across an organization's network, endpoints, and cloud environments in a single center, aiming to catch anomalous behavior early and speed up incident response. Today it has effectively become a component that many audit and compliance frameworks actually look for; it's now hard to imagine a corporate security audit without a SIEM in place.
But just as important as what SIEM does is who operates it, where, and under what rules. Because a SIEM platform, by definition, continuously collects an organization's most sensitive data — user behavior, access logs, IP addresses, sometimes file names and URL parameters — in a constant stream.
Where does this data stream actually go?
If a foreign SIEM platform is used as a cloud-based (SaaS) service, it means a significant portion of the logs are processed and stored in the manufacturer's data centers abroad. Even if the deployment is "on-premise," data can still flow back to the manufacturer for support, diagnostics, threat intelligence updates, and occasionally configuration backups. Moreover, this isn't a one-time transfer; it's an ongoing, 24/7 data movement that's part of the organization's normal operating routine.
Consider a concrete example: a mid-sized e-commerce company subscribes to a foreign cloud SIEM to monitor customer logins and payment page errors. This SIEM processes users' IP addresses, session IDs, and sometimes even entered email addresses; all of it automatically flows to the manufacturer's infrastructure abroad. While the company's IT team sees this as a "log management" matter, the legal department is forced to evaluate the same flow through an entirely different lens — that of personal data transfer. Often these two perspectives never even talk to each other.
The point that gets missed here is this: an IP address, username, or email information in a log line can be considered personal data under KVKK (Law No. 6698 on the Protection of Personal Data). In other words, a significant portion of what we call "just technical logs" actually qualifies as personal data. As a result, SIEM turns into a system that is, in practice, subject to KVKK's cross-border transfer regime — a fact rarely discussed.
Things get complicated when you look at it through the KVKK lens
Until 2024, Article 9 of KVKK made cross-border data transfer almost entirely dependent on explicit consent; in practice, there was hardly any other functioning mechanism. According to the Personal Data Protection Authority's 2023 activity report, only eighty-one undertaking (taahhütname) applications were filed that year, and only seven of them received a positive outcome. These figures alone show how unworkable the old system had become, especially for cloud-based software.
Law No. 7499, published in the Official Gazette on March 12, 2024, fundamentally changed Article 9 of KVKK; the amendment took effect on June 1, 2024. Under the new system, cross-border transfer is possible through one of three routes: an adequacy decision issued by the Board for the relevant country, sector, or organization; "appropriate safeguards" such as a standard contract or binding corporate rules; or, in the absence of either, explicit consent. The Board clarified the procedure for these mechanisms through the Regulation that took effect on July 10, 2024, and published a dedicated guideline on the topic in January 2025.
The fact that the new regulation establishes a structure closer to GDPR is a positive step, but it also brings an additional responsibility for organizations: now not only data controllers but also data processors are held directly responsible for cross-border transfers. If you haven't checked whether the contract you signed with your SIEM provider has been updated to reflect this new regime, you may unknowingly be out of compliance.
In practice, this means: if you don't know which systems in your inventory send data abroad, your KVKK compliance is already incomplete. Your VERBİS registration should clearly state the categories of data processed through SIEM and the transfer methods used, your privacy notice should cover this transfer, and your contract with your supplier — who is now also held responsible in their capacity as a data processor — should explicitly define one of the safeguard mechanisms envisioned by the Board. The number of organizations that have never carried out this check is higher than one might assume.
Data localization is no longer a matter of preference
Alongside KVKK, Cybersecurity Law No. 7545, which took effect on March 19, 2025, was added to the picture — Turkey's first comprehensive framework law in this area. The law established the Cybersecurity Board, chaired by the President, and the Cybersecurity Directorate; the Directorate's first head was appointed in October 2025.
Article 7 of the law requires that cybersecurity products, systems, and services used in public institutions and critical infrastructure be procured from suppliers authorized and certified by the Directorate. Failure to comply with this obligation can result in an administrative fine ranging from 1 million to 10 million Turkish lira. The Cybersecurity Board, which convened on May 5, 2026, finally clarified which sectors would be considered "critical infrastructure": digital infrastructure, digital services, electronic communications, energy, finance, food and agriculture, manufacturing industry, public services, media and crisis communication, postal and cargo services, health, defense industry, water management, transportation, and space. The list is broad enough to cover nearly the entire economy.
This expansion isn't actually a fresh start but the enlargement of an existing framework. The Cybersecurity Board had also made a critical infrastructure definition back in 2014, but that list only included transportation, energy, electronic communications, finance, water management, and critical public services. Twelve years later, the new list nearly triples the scope; sectors that were previously never considered — from food and agriculture to the defense industry, from space to media — now fall under the same oversight framework. This isn't a reflex unique to Turkey either; the European Union's NIS2 directive similarly and significantly expanded its scope compared to its predecessor, the NIS directive. In other words, this isn't a single country's regulatory preference; it reflects a globally accepted recognition that in digitalizing economies, the definition of critical infrastructure can no longer be limited to the classic energy-water-transportation trio.
The implication for SIEM is clear: the SIEM used by an organization operating in these sectors may fall within the scope of this procurement regime as a cybersecurity service. Whether your provider can complete the authorization and certification process before the Directorate is no longer merely a technical detail — it has become a question that carries direct contractual and compliance risk. In the same context, it's also worth remembering Law No. 5651, which comes into play regarding internet traffic and log retention; some of the logs fed into SIEM are already traffic information that must be retained under this law.
The language of the official announcement itself offers a clue: the protection of critical infrastructure, data sovereignty, cyber resilience, and increased domestic capacity are mentioned in the same breath, as parts of the same strategic framework. In other words, the issue is no longer just "which product works better"; the questions organizations need to start asking themselves going forward are also becoming clearer: Where do the SIEM and similar cybersecurity products we use come from? Is this supplier in a position to meet the authorization and certification requirements the Directorate will seek? If our supplier's status changes, what kind of exit or audit rights does our current contract grant us?
The supply chain: what's behind the screen?
When you purchase a SIEM platform, you effectively take on the manufacturer's entire supply chain as well: subcontractors, cloud infrastructure providers, third-party threat intelligence sources, automatic update mechanisms. None of these are under your control.
The 2020 SolarWinds incident is a concrete manifestation of this risk. Attackers infiltrated a routine update of the company's Orion software, directly compromising thousands of organizations, including U.S. federal agencies. None of the victims had a vulnerability in their own systems; the problem was in the update channel of a supplier they trusted. For a SIEM specifically, this scenario could have even more severe consequences, because SIEM is already the point where an organization's entire security visibility is concentrated; if that point is compromised, the very mechanism meant to detect the attack can itself be blinded.
Add to this geopolitical risk and currency risk. License fees are usually billed in dollars or euros, which has significantly complicated budget planning for Turkish organizations in recent years. Sudden restriction of access due to sanctions, export controls, or a manufacturer's change in market strategy — decisions entirely outside the organization's control — is also a possibility that can't be ignored; finding someone to address such a situation with is far harder than it would be with a local supplier.
There's also a gap in audit and visibility. While requesting a code review, penetration test report, or infrastructure audit from a local supplier can be resolved with relatively simple email exchanges, the same request to a large foreign software giant can take weeks, sometimes months — and often the organization's bargaining power remains limited. This gap is particularly pronounced for small and medium-sized organizations; changing a large foreign supplier's standard contract is rarely feasible, whereas negotiating special terms with a local provider is much easier.
What concretely changes with a switch to a domestic SIEM?
Against this backdrop, domestic SIEM solutions — such as Turkey-based platforms like Oriana SIEM — offer advantages on multiple fronts: data stays within Turkey's borders, the obligation to deal with KVKK's cross-border transfer regime is largely eliminated, compliance with the Cybersecurity Law's supplier authorization process becomes relatively more predictable, and you can communicate with the support team in the same time zone and the same language.
There's also a separate advantage for companies working with public institutions or critical infrastructure operators: products holding a domestic goods certificate can benefit from the price advantage recognized in public tenders. In addition, it becomes much easier for a request regarding the product roadmap — a new integration, a Turkish-language reporting template, adaptation to a local regulatory change — to make it onto the manufacturer's prioritization list; in a global product, the Turkish market generally isn't the top-priority segment. With domestic solutions like Oriana SIEM, this kind of feedback tends to reach the roadmap faster, simply because the relationship with the supplier is direct.
So what should be done now?
That said, a word of caution is warranted: the fact that critical infrastructure sectors have been announced doesn't mean all the implementation details have been clarified. The secondary regulations referenced in the law's transitional articles — the regulations and communiqués that will specify which thresholds and audit procedures apply to which sector — have already missed their targeted date of March 19, 2026, and the certification process that cybersecurity companies will be subject to has not yet actually been opened. Moreover, the framework itself continues to expand: a new bill submitted to the Turkish Grand National Assembly in July 2026 proposes extending the Directorate's authority into areas such as domain name management and electronic communications. This picture should not be read as a reason for organizations to relax, but rather as a preparation window: once the secondary regulations take effect, systems already in use will not be exempt from their scope. Reviewing your contract, inventory, and supplier relationship now is the cheapest way to avoid a last-minute scramble once the regulation is published.
The purpose of this piece is not to alarm every organization using a foreign SIEM. But it's at least worth asking these questions: Has your contract with your SIEM provider been updated in line with the amended Article 9 of KVKK from 2024? If your organization operates in one of the critical infrastructure sectors defined under the Cybersecurity Law, are you tracking your supplier's authorization process? And finally, if a supply chain disruption occurs, do you actually have a working Plan B — for instance, a roadmap for switching to a domestic alternative like Oriana SIEM?
More often than not, the honest answer to these questions isn't "everything's fine." That's precisely why data localization and supply chain security are no longer a secondary technical detail but an agenda item that needs to sit at the center of enterprise risk management.