Penetration Testing Standards in Türkiye: A 7-Point Enterprise Guide

A penetration test is the technical counterpart of the "cyber-security audit" clause in a contract. The team enters the customer's systems as an authorised attacker would, documents the paths a real adversary could take, and reports the issues for remediation. The pentest market in Türkiye has matured rapidly over the last five years; but practical knowledge about which standard is mandatory for which sector, how to choose the right vendor, and what a report should contain remains scattered.

This article walks through the seven-point enterprise guide an organisation in Türkiye needs before commissioning a penetration test. Legal framework, technical standards, vendor selection and post-test workflow in one piece. We share the practical findings of our cybersecurity services team from 40+ pentest projects over the past 36 months.

1. Regulatory framework — who must, who doesn't

In Türkiye, the obligation to perform a pentest is defined not by a single law but at the intersection of multiple regulators. Placing your sector in the correct category determines both scope and budget.

Entities under BDDK regulation (banks, payment / e-money institutions): under the BDDK Information Systems Regulation Article 31 + the Independent Audit Communiqué, at least one external pentest per year is mandatory. The test team is required to come from a BDDK-approved audit firm or be at minimum an ISO 27001-certified independent specialist. The report is retained for 3 years and presented during BDDK audits.

Entities under EPDK regulation (energy): the 2024 EPDK Information Security Regulation requires an annual pentest plus a SCADA/OT-specific test for electricity distribution, generation and natural-gas companies. SCADA tests require specialised expertise; a standard IT pentest team is insufficient.

Entities processing special-category personal data under KVKK (healthcare, legal, biometric system operators): KVKK Article 12's phrase "every technical measure necessary for data security" is interpreted in KVKK Board opinions as a regular pentest. The obligation is not explicit, but answering "no" to "did you carry out an annual pentest?" during an audit materially raises the risk of administrative sanctions.

TS 13638 (Information security — penetration testing methodology): the Turkish Standards Institute standard frequently cited in government tenders. Defines A/B/C-level penetration tests — A is the most comprehensive (10+ engineer-days), C the lightest (1-3 days). If you compete for public-sector tenders, you need to learn these levels.

Entities outside regulated sectors: no obligation but real pressure. Cyber-insurance policies require an annual pentest, large enterprise customers ask "date of last pentest" in vendor questionnaires, and investor due diligence has made it standard.

2. Standard selection — PTES, OWASP, NIST: which one?

Three baseline pentest standards exist; naming the right framework in your RFP or vendor contract is the first step that locks scope clearly.

PTES (Penetration Testing Execution Standard): industry-neutral general pentest methodology. Seven phases: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting. Suitable for both network and application testing. Most Turkish pentest firms default to PTES.

OWASP (Open Web Application Security Project): web-application focused. OWASP Top 10 (the most common 10 categories of web flaw) + OWASP Testing Guide (300+ test scenarios) + OWASP ASVS (Application Security Verification Standard, 14 sections × Level 1/2/3). Deeper than PTES for web/API testing.

NIST SP 800-115 (Technical Guide to Information Security Testing): US federal standard; more for large networks and enterprise infrastructure. Less requested in Türkiye but useful for organisations with an international customer base.

Practical combination: our recommendation to enterprise customers is PTES framework + OWASP content tests. The web/API parts run to OWASP ASVS Level 2, the network/infrastructure parts to PTES. This approach provides both breadth and depth.

The standard to be used must be written into the contract. "Best practices will be applied" is insufficient — during an audit, the question "who defined best practices?" is hard to answer.

3. Black vs gray vs white box — when to use which

The three test types serve different purposes; choosing the right one leads to the right outcome.

Black box: zero prior information given to the team. Only the target URL/IP list. External-attacker simulation — realistic but shallow. Reconnaissance is completed in 2-3 engineer-days; most findings come from the discovery phase, while deep architectural flaws are skipped.

Gray box: standard user privileges granted, architecture summary provided, but no code access. The most common B2B choice. Combined internal+external threat model — tests what a real attacker could do with leaked user credentials. 5-10 engineer-days.

White box: source code + architecture diagram + admin account provided. In-depth review — finds 3-5× more issues than black box. 10-20 engineer-days. The most appropriate for KVKK audit preparation, critical infrastructure first pentest, M&A technical due diligence.

Practical selection rule:

Our red team simulation service differs from classical pentest by targeting a specific objective (e.g. exfiltrating customer data); it uses every path including social engineering. Classical pentest finds issues; red team tests your defensive capacity. They serve different purposes and don't substitute for each other.

4. Scope definition — the pre-engagement phase

The most often-debated part of a pentest project is the scope definition. Insufficient scope → critical issues remain unseen because they're out of scope; excessive scope → testing drags on, prices balloon.

A minimum scope-definition document must contain six sections:

1. Assets to be tested: URL/IP list, API endpoints, mobile app versions. A net list, not a wildcard ("*.example.com").
2. Assets NOT to be tested (exclusions): third-party SaaS (Google Workspace, Microsoft 365), production CRM, backup servers. Accidental testing risks business-continuity impact.
3. Test windows: time range (e.g. 02:00-06:00 off-hours) + weekdays. To minimise impact on production traffic.
4. Payloads NOT to be tested: Denial of Service (DoS), user-data exfiltration, physical attack simulation. Explicitly forbidden in the contract.
5. Emergency protocol: who is called during a prod outage during testing, on which line, criteria for stopping the test.
6. Communication channels: daily status reports, critical-finding emergency notification line (usually within 4 hours).

This document must be signed by both sides before the test starts. Subsequent changes go through a change-request process; verbal agreements are not valid.

5. Report format — evidence chain and reproducibility

The shared trait of a good pentest report is that the findings are reproducible. "There is SQL injection at URL X" is not enough; a developer must be able to send the same request and observe the same result.

The five sections of a standard pentest report:

Section 1 — Executive summary (1-2 pages). Non-technical language: how many findings, how many critical/high/medium/low, a risk-score summary chart, business-impact commentary. Senior management reads, decides.

Section 2 — Scope and methodology. Which systems were tested, which standard was used (PTES + OWASP Level 2 etc.), which tools (Burp Suite, Nmap, Metasploit, custom scripts), test windows. For reproducibility.

Section 3 — Findings table (sorted by CVSS 3.1 score). For each finding: ID + title + risk level + affected asset + CVSS score. Shows all findings at a glance.

Section 4 — Detail page per finding:

• Description (one paragraph, technical language)
• Impact: what happens if this issue is exploited? Data leak? Account takeover? System access?
• Reproduction steps: full URL + HTTP method + headers + payload + expected response
• PoC (Proof of Concept): screenshot, HTTP traffic (Burp export), video capture
• Recommended fix: specific. Not "do input validation" — "use this library in this function in this way".
• References: OWASP/CWE/CVE number

Section 5 — Re-test results. The re-test result after remediation. Which findings closed, which partially closed, which remained open. The pentest vendor must provide a free re-test within 30 days.

A report not conforming to this structure makes it harder for our incident-response team to use it as a reference after a future breach. Report quality directly affects the speed of post-breach forensic work.

6. Vendor selection criteria — 7 items

Seven concrete criteria to weigh when selecting a pentest vendor:

1. Team certifications: OSCP (Offensive Security Certified Professional) minimum, OSCE/OSEP/OSWE upper tier, eMAPT for mobile, GIAC certifications. Ask for the CV of the engineer who will actually test — the project manager's certificate is insufficient.
2. Sector experience: A firm doing banking tests isn't always right for SCADA. Ask how many tests the vendor has done in your sector in the last 12 months.
3. Methodology documentation: Is there a written pentest methodology? PTES- or OWASP-based? Updated over the years?
4. Tool inventory: Burp Suite Professional + Nessus + Metasploit Framework + Cobalt Strike (for red team) + custom scripts — an explicit tool list should be available.
5. Insurance + NDA: Professional indemnity insurance (min 1M TL cover) + strict NDA + a liability clause for data incidents during testing.
6. Re-test policy: Free within 30 days? 60? Who defines the re-test scope?
7. Reference checks: Verifiable references from the last 3 customers; ideally an example (anonymised) pentest report.

Few vendors score green on all seven; you can work with at least 5 green + 2 yellow flags. Whether yellow areas are critical for your project is for you to judge.

7. After the pentest — remediation loop and SLA

The pentest report is a beginning, not an end. The real engineering happens in remediation. Industry-standard remediation SLAs:

Mitigation ≠ fix. Mitigation is short-term risk reduction (WAF rule, IP block, temporary feature toggle); a fix is the permanent code/configuration change. Both are required for a critical finding.

Internal process filing is critical during remediation. Open a ticket for each finding, assign an owner, set a deadline, define who validates the fix. Our recommendation: the pentest vendor should offer a 30-minute free technical-advisory session for the remediation plan; to answer the developer team's "how do we fix this in code" question.

The re-test is taken within 30 days, free, from the same vendor. The re-test report is an annexe to the original; three columns — "closed findings" + "still open" + "newly discovered" (re-tests sometimes uncover new issues).

After remediation is complete, our SOC team sets monitoring signals — any re-attack attempt against the closed vulnerability is detected immediately. This is the link that ties the pentest cycle into ongoing security operations.

Decision matrix: how often to pentest

Pentest frequency depends on sector, regulation and risk profile:

The decision to pentest is not a budget but a risk question. The average cost of one critical breach (KVKK fine + customer loss + reputation damage) is 20-50× the annual pentest cost. With this calculation done, a pentest is not a "luxury" but "low-cost insurance". Run the numbers for your own organisation and present them to senior leadership in this framing — acceptance rates rise noticeably.

Next step

If you are planning a pentest for your organisation — for an annual routine, regulatory requirement, or new product launch — evaluate the seven items above against your own scenario. Which standard fits, which type (black/gray/white) takes priority, which vendor criterion is critical for you — these are answered together end-to-end with the team.

You can request a preliminary pentest call via our contact page; in a free 45-minute call we share a scope draft + budget range + standard recommendation. After the call, you decide whether to pentest and which vendor to use; our recommendation is only a reference point.

The next posts continuing this series will be announced on our blog: "Red team simulation practical guide" and "SOC deployment — a 90-day roadmap". If a topic is a priority for you, mentioning it on your enquiry lets us share the relevant technical material.