Cybersecurity Law No. 7545 and AI Systems:
Is Your Organization Ready?

What is Turkey's Cybersecurity Law No. 7545?

Cybersecurity Law No. 7545 is the framework law that regulates cybersecurity in Turkey at a national scale; it was published in the Official Gazette on 19 March 2025 and entered into force on that date. Its purpose is to protect the information systems of the public sector and critical infrastructure against cyber threats, to consolidate cybersecurity policy under a central authority, and to institutionalize incident management.

The law empowers two principal institutional bodies:

• Cybersecurity Directorate: the administrative authority that implements cybersecurity policy, collects incident notifications, conducts audits, and runs the enforcement process.
• Cybersecurity Board: the high-level board, chaired by the President, where strategic decisions and priorities are set.

The law defines concepts such as cybersecurity, critical infrastructure, cyber incident, vulnerability, and cyber threat, and it imposes on the obliged sector both a duty to take preventive measures and a duty of post-incident notification and cooperation. In other words, Law No. 7545 does not merely say "report it if you are attacked." It also requires organizations to take regular measures to protect their systems, to be audit-ready, and to provide the information and documents the Directorate requests.

This framework does not target a single class of asset — as KVKK does with personal data — but rather the organization's entire information surface. AI components are part of that surface, and precisely for that reason they fall within the law's scope. For international readers, the useful mental model is that 7545 is Turkey's national cybersecurity umbrella, closer in spirit to the EU's NIS2 posture than to a data-protection statute.

Which organizations does Law No. 7545 cover?

The obliged population is not "everyone" in daily life; it is primarily the public sector and producers of critical services. Broadly, the scope can be grouped into three clusters:

• Public institutions and organizations, including professional bodies with a public character.
• Critical infrastructure operators: energy, electronic communications, finance and banking, transport, water management, healthcare, and similar sectors whose disruption carries high societal or economic impact.
• Providers of cybersecurity products, services, or solutions: actors offering security software, auditing, penetration testing, and comparable services.

The common denominator across these clusters is that an interruption of their service or a compromise of their data security produces a public impact. A bank's mobile application, a hospital information system, an energy distribution SCADA network, or an e-government service sits at the center of this definition.

The critical point is this: most of these organizations now use AI. Customer-service chatbots at banks, policy assistants at insurers, document-summarizing RAG systems in public agencies, LLM-based routers in call centers. The moment an obliged organization uses AI, those components become part of its cybersecurity obligation — not a separate, exempt category.

How do AI systems fall under the scope of Law No. 7545?

The text carries no separate "artificial intelligence" heading. This does not mean AI systems are out of scope; on the contrary, because an LLM or AI agent is legally an information system and a data-processing component, it falls under the general obligations. Entry into scope happens along three paths:

a) AI is an attack surface

An LLM chatbot is an externally exposed endpoint, and like any such endpoint it can be attacked. Techniques such as prompt injection, jailbreaks, system-prompt exfiltration, and indirect injection differ in mechanism from classic web vulnerabilities but produce equivalent outcomes: unauthorized data access, service manipulation, and authentication bypass. The "protect your systems" duty in Law No. 7545 covers this new surface as well.

b) AI processes data

A RAG system reaches into customer records, contracts, or health data in the background. A model returning an unauthorized document, or executing an instruction that lands in its context window, is a security incident in its own right. Wherever data moves, a cybersecurity obligation moves with it.

c) AI takes action

A tool-calling AI agent can send an email, update a record, or call an API. This shifts the impact of an attack from "information leak" to "unauthorized transaction." Manipulating an agent carries the same severity as a classic privilege-escalation vulnerability and is subject to the same obligation framework.

In short: an AI system that an obliged organization builds or operates is — exactly like a web application or a database — an asset that must be protected, monitored, tested, and reported in the event of an incident. The assumption that "AI is a separate world" is, from a compliance standpoint, the most dangerous assumption of all.

What new cyber risk surfaces does AI open up?

AI components introduce a class of attack that traditional security controls often fail to see. The shared vocabulary for these risks is set by the OWASP LLM Top 10 (2025) and MITRE ATLAS. The principal surfaces:

Every one of these surfaces is meaningful under Law No. 7545 because each can trigger a cyber incident. A customer IBAN leaking from a bank's chatbot, health data emerging from a hospital's RAG system, or an unauthorized instruction sent by a manipulated agent is at once a realized security event and a situation that requires notification. Classic WAF, DLP, and EDR products largely miss these semantic attacks: at the packet level there is nothing "malicious," because the malice lives inside the language.

What does the periodic testing and audit obligation require?

The most concrete practical consequence of Law No. 7545 is that obliged organizations must be able to prove their security posture on a recurring basis. The Cybersecurity Directorate can conduct audits and request information and documents; the organization, in turn, must be in a position to show the measures it has taken and the findings from its tests. This expectation should be read to include AI components.

Yet the traditional penetration-testing approach falls short for LLMs. A web pentest methodology looks for SQL injection and XSS, but it does not cover prompt injection, jailbreak chains, multi-turn (crescendo) manipulation, or filter evasion through language-specific morphology. Auditing for AI systems needs the following layers:

• LLM penetration testing: adversarial testing targeting prompt injection, jailbreaks, system-prompt exfiltration, PII exfiltration, and tool abuse — including language-specific attack patterns. See LLM Penetration Testing.
• Runtime monitoring (guardrails): input and output inspection, PII masking, policy-violation detection, and incident logging. This is the organization's answer to "will I even know when an incident happens?"
• Records and evidence: retaining audit trails, notification processes, and test reports so they can be produced when the Directorate requests them.
• Re-test loop: repeating the test whenever the model, the system prompt, or an integration changes. AI systems change quickly, so a one-off test becomes stale in short order.

Here, AltaySec's Guardian is positioned as a domestic runtime-monitoring layer built around the local attack landscape and the KVKK context; the aim is to make the "we took measures and we are monitoring" claim provable with concrete logs at audit time, rather than a statement made on trust.

What are the administrative sanctions for non-compliance?

Law No. 7545 provides for administrative fines in cases of non-compliance, and for certain serious acts, criminal sanctions (provisions extending up to imprisonment) can apply. This article deliberately gives no figures: penalty amounts are updated by regulation and vary with the nature of the incident, the size of the organization, and the gravity of the breach. What matters is grasping the logic:

• Failing to take measures / failing to cooperate with an audit: an obliged organization that does not take the required security measures, or does not cooperate with the audit process, is subject to administrative sanction.
• Failing to report an incident: not notifying the Directorate of a cyber incident constitutes a separate violation. Deciding not to report an LLM data leak because "we handled it internally" only enlarges the risk.
• Serious acts: unauthorized storage of data abroad, deliberate manipulation of systems, or creating public fear or panic through false content are among the acts for which the law reserves criminal dimensions.

The critical takeaway for AI: the cost of a prompt-injection incident is not limited to the leaked data. The same event can stack a KVKK penalty on top of a 7545 sanction. Moreover, the "we didn't know" defense is no longer protective — because lacking the capacity to monitor and report is itself a deficiency.

How do Law No. 7545, the EU AI Act, and KVKK intersect?

For organizations operating in or selling into Turkey and the EU, AI compliance is not settled by a single law; several frameworks interlock. Each answers a different question, but a real incident usually triggers all of them at once. This is where the EU AI Act becomes especially relevant for any organization with cross-border exposure.

The EU AI Act deserves particular attention. It classifies AI by risk tier, and for high-risk systems it imposes obligations that include accuracy, robustness, and cybersecurity (notably under its Article 15). Its provisions phase in on a staggered timeline — prohibitions and AI-literacy duties first, then obligations for general-purpose AI models, and later the full weight of high-risk requirements. A Turkish organization that exports a product, serves EU customers, or embeds a third-party model built in the EU can find its AI system treated as high-risk. In that case, the very same prompt-injection leak that triggers a 7545 notification and a KVKK breach also reads as a robustness and cybersecurity shortfall under the EU AI Act. Where KVKK maps closely to the GDPR for personal data, the EU AI Act is the product-safety layer for the model itself — and the two increasingly travel together.

To make this concrete: an insurer's policy chatbot leaks a customer's medical history through prompt injection. This single event simultaneously produces — a special-category data breach under KVKK (Article 6); a reportable cybersecurity incident under Law No. 7545; and, where a cross-border or high-risk structure exists, a robustness gap under the EU AI Act. Three frameworks converge at one point.

The practical conclusion: managing compliance as three separate silos is inefficient. The same technical control set — LLM penetration testing, a runtime guardrail, an incident-notification process, and PII masking — satisfies the core expectation of all three frameworks at once.

Is your organization ready for Law No. 7545? Preparation steps

Readiness rests not on a single audit day but on a sustainable structure. The steps below form a practical roadmap that includes AI components:

1. Build an AI inventory. Which LLMs, RAG pipelines, and agents are in production? What data do they access? Which tools can they call? A component you cannot see, you cannot protect.
2. Classify your data. Label the data each AI component touches (personal, special-category, financial, confidential). This map determines your KVKK and 7545 risk.
3. Plan LLM penetration testing. Test regularly for prompt injection, jailbreaks, PII exfiltration, and tool abuse — including language-specific attack patterns.
4. Set up runtime monitoring. Without input/output inspection, PII masking, policy-violation detection, and incident logging, the "report the incident" obligation hangs in the air.
5. Define the incident-notification process. When an AI incident occurs, who reports what, above which threshold, to the Cybersecurity Directorate? This flow must be written down in advance.
6. Map to standards. Align your controls with the OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF, and the EU AI Act; this provides a common language and evidence at audit time.
7. Establish a re-test loop. Repeat the test whenever the model, system prompt, or an integration changes; one-off compliance ages fast in AI.
8. Institutionalize governance. Anchor responsibility to an AI security/governance process, not to a single individual.

Much of this overlaps with an organization's general cybersecurity maturity; the difference is explicitly including the AI-specific layer (semantic attacks, model behavior, data pipeline). Organizations that neglect this layer remain exposed on the new surface within scope of Law No. 7545 — even when their traditional controls are strong.

Conclusion

Cybersecurity Law No. 7545 has tied the cybersecurity of Turkey's public sector and critical infrastructure to a central framework. Even though the text does not say "AI," the LLM assistants, RAG systems, and AI agents of obliged organizations — as information systems and data-processing components — sit squarely inside it. A prompt-injection event is no longer merely a technical hiccup; it is an incident that can trigger three distinct obligations under KVKK, the EU AI Act, and Law No. 7545 at the same time.

The correct reading is this: compliance is not a stack of paperwork assembled on audit day; it is a testable, monitorable, and reportable AI security structure. Organizations that build this structure early stand on the prepared side of the 2026 wave of AI compliance. At AltaySec, working as one of the pioneering voices in this field in Turkey, we focus on helping obliged organizations build that readiness with concrete, domestic tooling.

Frequently Asked Questions