Penetration Testing for SMEs: Scan vs Real Test, and KVKK

Most of the documents that land on our desk labeled “penetration test report” are not penetration tests at all. They are the output of an automated scanner — hundreds of lines padded with informational findings, exported to PDF. The company paid, a file sits in a folder, and they walk into a KVKK audit saying “we got tested.” Then a real attack happens and it turns out the thing that was tested and the path the attacker used had almost nothing in common.

Confusing these two is dangerous precisely because it makes you feel safe when you aren’t. Let me draw the line clearly.

A vulnerability scan is not a penetration test

A vulnerability scan is automated. Software sweeps your network or application, matches known weaknesses against a signature database, and produces a list. It is fast, cheap, and worth running often. But a machine cannot tell whether a flaw it flagged is actually exploitable, or whether chaining two weaknesses together would let someone into the system. It produces false positives and it has no sense of business context.

A penetration test puts a human expert in the attacker’s seat. They exploit the weakness for real, escalate privileges, move laterally, and prove it: “I got this far, I reached this data.” An automated scan says “this lock looks weak.” A pen test opens the door, walks in, and photographs the file on the desk.

	Vulnerability Scan	Penetration Test
Method	Automated software	Human expert + tools
Output	List of flaws	Proof of exploitation + impact
False positives	High	Filtered, verified
Frequency	Continuous/monthly	Yearly + after major change
Cost	Low	Varies by scope
Answers	”What flaws exist?"	"What can an attacker actually do?”

They aren’t rivals; they complete each other. You run the scan continuously and commission the pen test once a year. The problem is providers who sell the first at the price of the second.

Does KVKK require a penetration test?

Short answer: indirectly but clearly, yes. Türkiye’s data protection law (KVKK, Law No. 6698) puts a duty on the data controller under Article 12 to ensure an “appropriate level of security.” It doesn’t spell out the words “run a pen test.” The real reference is the Board’s published Personal Data Security Guide (Technical and Administrative Measures), which explicitly lists vulnerability scanning and penetration testing among the expected technical measures.

In practice, the Board expects systems that process personal data to be pen-tested at regular intervals — industry practice being at least once a year, by an independent, qualified firm. When a breach investigation opens, one of the most concrete pieces of evidence that you genuinely maintained an “appropriate level of security” is a history of regular penetration tests. Not having done one can weigh as an aggravating factor in the administrative fine.

Beyond KVKK there are other drivers: ISO 27001 certification, PCI DSS (an annual test requirement for anyone handling card data), customer vendor-security audits, and increasingly the preconditions on cyber-insurance policies. Answering “no” to “did you run a penetration test in the last 12 months?” on a policy application raises your premium or narrows your coverage.

Which type of test fits you?

“Penetration test” is not one thing. Choosing the right scope and perspective decides whether your budget does anything useful.

By level of knowledge given to the tester:

• Black-box: the tester gets nothing and starts like an outside attacker. Realistic, but time-consuming.
• Grey-box: partial access and information (say, a standard user account). For most SMEs this is the sweet spot — you see how far a stolen user login can travel.
• White-box: source code, architecture, and full access. Deepest results, highest effort.

By target:

• External network: internet-facing servers, VPN, website, mail gateway — your visible attack surface.
• Internal network: what can an attacker who already got inside (or a malicious insider) do?
• Web/application: your customer portal, e-commerce site, internal admin panel.
• Social engineering: measuring the human factor with a simulated phishing campaign.

For most businesses a sensible start is external network + a critical web application + a grey-box internal test. Wherever personal data flows, the scope should cover it — a system you leave out of scope becomes a “why wasn’t this tested?” question in the audit.

What to expect from the report

The real value of a pen test shows up in the report. A good one includes:

1. Executive summary: a risk picture a non-technical decision-maker can read.
2. Findings ranked by severity: critical/high/medium/low, ideally with a CVSS score.
3. Proof of concept: for each serious finding, the “here’s how we got in” steps and a screenshot.
4. Actionable remediation: “update this, disable that setting” — specific enough to act on.
5. Retest: verification after you close the findings. For KVKK this is the critical part — finding a flaw isn’t what counts in an audit; documenting that it was closed is.

Also ask about the firm’s credentials, the testers’ certifications (OSCP, CEH and the like), and whether the engagement is bound by a confidentiality agreement. After all, you are showing this firm exactly where your weakest points are.

Frequently asked questions

We’re a small business — do we really need one? If you process personal data, the obligation is the same regardless of size. If budget is tight, start narrow with the external network and your most critical web application; you don’t have to test everything at once.

How often? Industry practice is at least once a year. On top of that, repeat it when you launch a new application, make a major infrastructure change, or after a security incident.

Isn’t a vulnerability scan enough? No. A scan finds flaws but doesn’t show whether they’re exploitable, their real impact, or chained risks. The KVKK guide expects both together.

Will the test damage our systems? A well-planned scope and schedule keeps production impact to a minimum. Risky scenarios run in a test environment or outside business hours — pin this down in the contract.

If you need help scoping a penetration test, choosing the right provider, or closing the findings that come out of one, get in touch — we organize the test and make sure the findings actually get fixed afterward.

Sources

• KVKK — Personal Data Security Guide (Technical and Administrative Measures, Turkish)
• Law No. 6698 on the Protection of Personal Data, Article 12 (Turkish)
• PCI DSS v4.0 — Penetration Testing Requirements (Requirement 11.4)