Penetration Testing Under Turkish KVKK: Technical Measures, Board Decisions, and Evidentiary Value

In 2020, the Turkish Personal Data Protection Board (KVKK) fined an insurance company 330,000 TL. The reasoning was notable: the company's own IT security procedure stated that "system vulnerabilities should be checked through periodic penetration testing services." The procedure existed — but the test server involved in the breach was not included in the annual penetration test scope.

The fine was not for failing to do penetration testing. It was for declaring a security control and failing to apply it.

That decision captures penetration testing's place in KVKK compliance: it is no longer "a good practice" but a declared technical measure that must be provable. This guide covers the legal basis, the Board's case law, frequency and scope questions, and whether your pentest report would hold up as evidence in an audit.

Legal Basis: Article 12 and the Personal Data Security Guide

Article 12 of Law No. 6698 (KVKK) imposes three obligations on data controllers:

1. Prevent unlawful processing of personal data
2. Prevent unlawful access to personal data
3. Safeguard personal data

To fulfill these, the data controller "is obliged to take all necessary technical and administrative measures to ensure an appropriate level of security." The law itself doesn't enumerate measures — but the Board's Personal Data Security Guide does.

The Guide's technical measures table explicitly lists Penetration Testing, alongside access matrices, access logs, encryption, intrusion detection systems, DLP, and backup. The Guide further states that information systems should be protected against known vulnerabilities through "regular vulnerability scanning and penetration testing," with evaluations based on test results.

Summary: the law demands appropriate security, the Guide names penetration testing as a technical measure, and Board decisions concretize the expectation in practice.

Penetration Testing in Board Decisions: Three Lessons

Lesson 1: What's in your procedure must be done (2020/905)

The insurance case above. The procedure mentioned penetration testing; the application excluded a server. The Board found a violation of Article 12(1). Lesson: Everything you declare in security policies must be applied across every asset. Every server you exclude from scope becomes evidence against your own policy.

Lesson 2: Late notification is a separate fine (2020/905 and 2019/10)

In the same decision, the company was fined separately for failing to notify the breach "without undue delay" — 72 hours in Board practice. Delays in log analysis were also cited. Lesson: Penetration testing is not just prevention; it is a rehearsal of your detection and evidence-gathering capacity during an incident. Missing breach-response hours due to absent log infrastructure creates a second violation.

Lesson 3: Fine amounts increase every year

For violations of data security obligations (Article 18(1)(b)), the 2025 administrative fine range was 204,285 TL to 13,620,402 TL, indexed annually — the 2025 revaluation rate was 43.93%. Higher bands apply to large datasets and sensitive data categories. Lesson: The gap between a pentest budget and a potential fine widens every year.

Is "We Did a Pentest" Enough? The Evidentiary Value Test

In an audit or breach investigation, the Board looks not for the pentest invoice but for proof that testing was a process. Your report's evidentiary value is tested by these questions:

Question	Weak evidence	Strong evidence
Scope	"The website was tested"	Scope document matching the asset inventory, with justified exclusions
Frequency	One test three years ago	Annual testing + tests triggered by significant changes
Methodology	Scanner output	Defined methodology (OWASP, PTES) + manual exploitation evidence
Findings	Screenshot list	CVSS-scored, reproducible findings with PoC
Remediation	"FYI"	Fix per finding + retest records
Governance	Report sits in IT	Executive summary + risk acceptance records + remediation timeline

If you can't answer with the right column across the board, your report is "the invoice for a service we bought" — not evidence of a security measure.

How Often, and What Should You Test?

KVKK prescribes no single number; "appropriate security level" is risk-based. A practical framework derived from Board practice and the Guide:

Frequency:

• Annually, at minimum, covering all critical systems
• Triggered by significant changes: new application releases, architectural changes, cloud migration, merger integrations
• Post-incident: independent verification that the closed vulnerability actually closed

Scope — every layer that touches personal data:

• Internet-facing applications and APIs
• Internal networks and servers — the 2020/905 lesson: even "unimportant" test servers
• Mobile applications (if processing personal data)
• Cloud configurations and identity management
• Employee access paths (VPN, remote desktop, phishing simulation)

Common mistake: testing only the external perimeter while skipping the internal network. Most real breaches arrive via phishing and supply chains; if internal authorization is weak, external testing protects nothing.

Data Processor Relationships: The Pentest Clause in Contracts

Under Article 12, data controllers are jointly responsible with data processors for taking security measures. Practical consequences:

• Your cloud provider, CRM, and payment provider must document security commitments in contracts
• Your own pentest does not cover processors' systems — integration points need separate testing
• Enterprise customers increasingly request your pentest report (now standard in B2B sales) — an annual testing cadence becomes part of your sales cycle

Penetration Testing's Role in the 72-Hour Window

When a personal data breach occurs, controllers must notify the Board and affected parties without undue delay — 72 hours in Board practice. In those hours you need:

1. Detection: Which system, which entry path? (Log infrastructure + pre-tested detection rules)
2. Scope: Which data sets were affected? (Data inventory + proof that network segmentation actually works)
3. Containment: Verification that the attack path is cut (Exploitation paths, once known, can be verified as closed)

All three are rehearsed through regular penetration testing and red team exercises. A detection process improvised on breach day misses the 72-hour window — and as 2020/905 shows, late notification is a separate fine.

KVKK Penetration Testing Checklist

• If your security policy commits to penetration testing, are all assets in scope?
• Was a full-scope test performed within the last 12 months?
• Do test reports contain CVSS-scored findings with PoC?
• Are retest records kept for closed findings?
• Does the scope document match your data inventory?
• Are internal networks and cloud configurations tested, not just the external surface?
• Has the 72-hour breach notification process been exercised?
• Are security commitments documented in data processor contracts?

If half your answers are "no," your current state carries audit and post-breach investigation risk.

Frequently Asked Questions

Is penetration testing legally mandatory under KVKK?

The law doesn't mandate it by name; Article 12 requires "all necessary technical and administrative measures for an appropriate security level." The Board's Personal Data Security Guide explicitly lists penetration testing among technical measures, and Board decisions show that declared-but-unapplied security controls become grounds for fines. In practice: periodic penetration testing is the expected standard for any controller processing personal data.

Is one penetration test per year sufficient?

Annual testing is the baseline for critical systems. Significant architectural changes, new releases, and post-incident reviews require additional tests. High-risk sectors (finance, health, e-commerce) expect multiple tests per year combined with continuous automation.

Can a pentest report be used as evidence in a KVKK audit?

Yes — with a scope document, methodology, CVSS-scored findings, and remediation/retest records. Scanner output alone, or an old report with unclear scope, loses evidentiary value. The 2020/905 decision shows why scope must reflect real assets.

What's the fine for not doing penetration testing?

For violations of data security obligations, the 2025 administrative fine range is 204,285 TL to 13,620,402 TL, indexed annually. Fines depend on the nature of the data, breach magnitude, and omitted measures.

Do we need penetration testing for our cloud systems?

Yes. Cloud configuration, identity management (IAM), and applications processing personal data are in scope. The provider's responsibility ends at the infrastructure layer; configuration and application security belong to you under the shared responsibility model.

Closing: Compliance Is Evidence Work

In KVKK compliance, security is not what you declare — it's what you can prove. Penetration testing is the technical link in that chain of evidence: it shows whether your policies match reality, whether your detection capacity works on breach day, and whether remediations actually closed.

At Eresus Security, every engagement is delivered in a structure that holds up as KVKK audit evidence: scope-inventory matching, CVSS-scored findings, exploitation evidence, and retest records.

To validate whether your systems meet KVKK technical measure expectations, request a scoping call.