Written authorization for pentest under KZ-1 Art. 221 — why paper outranks tools

A penetration test without written authorization is not "ethical hacking" — it is a criminal offense under Article 221 of the Slovenian Criminal Code (KZ-1). In pentest work, sequence and evidence matter more than tools: paper first, Kali or Burp after. Below: what an authorization must actually contain, and which clause matters more in Slovenia than elsewhere.

KZ-1 Article 221 — what is actually criminalized

Title: Attack on an Information System. Four offenses, escalating:

• Para 1 — unauthorized intrusion or interception of non-public transmission: imprisonment up to 2 years.
• Para 2 — unauthorized use, modification, copying, transmission, destruction of data, or obstruction of transmission/system operation: up to 3 years.
• Para 3 — use of tools per Art. 306 or disruption of three or more systems: 3 months to 4 years.
• Para 4 — substantial damage, organized association, or critical infrastructure: 3 months to 5 years.

A Wi-Fi scan against a third-party domain and an nmap against a third-party IP without paper formally fall under Para 1. The moment a discovered XSS gets "tested" through real requests — Para 2. Automated testing against multiple customers in parallel — Para 3.

Adjacent articles that the authorization must reference:

• KZ-1 Art. 143 — Abuse of Personal Data. If personal data is in scope (and on web apps it usually is, at minimum in logs), this is a separate criminal exposure that GDPR alone does not displace. Up to 2 years for sensitive data, up to 5 years for identity assumption.
• KZ-1 Art. 220 — Damage to Another's Property. Relevant when the test may cause an outage or data loss (DoS, deletion, corrupted DB writes).

Canonical text: pisrs.si — KZ-1. Frozen numbers age — the authorization should reference the consolidated text on PISRS, not a snapshot.

Who has the right to authorize — Slovenia's most-violated pitfall

Rule: the signatory must hold actual legal authority over the system, not merely budget authority. For Slovenian organizations:

• Default: statutory representative on AJPES/PRS (director, prokurist, sole-proprietor owner).
• Delegation: CISO or head of IT may sign only with a written delegation from the statutory representative, attached to the test documentation.

The most-violated trap in Slovenian practice — hosting and CMS:

System	Who can validly authorize
Own web app on own server	The customer
Application on shared hosting (Slovenian provider)	Customer at the application layer; network/infra layer requires separate written permission from the host
Cloudflare / AWS / GCP / Azure	Provider-published pentest policies apply — verify and document before starting
WordPress.com, Wix, Squarespace, managed Shopify	Customer cannot validly authorize — testing breaches ToS and crosses Art. 221 against the provider

A customer who signs an "authorization" to pentest their Wix site has authorized nothing enforceable. The test is criminal against Wix, regardless of whose name is on the contract.

Nine clauses without which there is no authorization

No Slovenian or EU statute mandates a specific list. NIST SP 800-115 §3 and PTES Pre-engagement treat these nine as the baseline that serious practice does not go below:

1. Identification of parties — full name, registry number, tax ID, address, signatories.
2. Scope — explicit list of IP/CIDR/URLs/applications/user populations.
3. Explicitly out-of-scope — production DBs, third parties, social engineering, DoS, physical.
4. Time window — start/end dates, permitted hours (e.g., 22:00–06:00 for invasive steps).
5. Source-IP allowlist — tester IPs the customer can pin in their own WAF/SIEM.
6. Data handling + NDA — GDPR Art. 28(3)(a–h) clauses, exfiltration prohibition, encryption.
7. Evidence retention + reporting — who receives the report, for how long, where, how it is destroyed.
8. Escalation path on critical finding — 24/7 contact, threshold (e.g., CVSS ≥ 9.0), notification window.
9. Signature by a person with actual legal authority (with attached delegation, if not the statutory representative).

An authorization missing any of the nine is defective in practice.

Legal basis for processing personal data

When a pentest touches personal data (which on web apps usually means at minimum log lines):

• GDPR Art. 6(1)(f) and Recital 49 — network and information security is explicitly recognized as a legitimate interest of the controller.
• GDPR Art. 28 — a written processor contract is mandatory. The eight clauses of Art. 28(3)(a–h) must appear in the authorization (instructions, confidentiality, security, sub-processors, data-subject rights, assistance with Arts. 32–36, deletion/return, audit).
• ZVOP-2 (Official Gazette RS 163/22, in force since 26 Jan 2023) — Slovenia's IP RS is the supervisory authority; breach notification cross-references GDPR Arts. 33/34; biometrics and special categories are tightened.

A standard controller↔processor SCC template is published by the Slovenian Information Commissioner (ip-rs.si).

Technical framework that goes into scope

The authorization names the methodology so the reader knows what the test covers. Current references (June 2026):

• OWASP ASVS 5.0.0 (May 2025) — 17 chapters, ~350 controls. L1 baseline, L2 standard for sensitive data, L3 critical systems (finance, health). Scope writes as "L2 + selected L3 chapters."
• OWASP Top 10:2025 — A01 Broken Access Control through A10 Mishandling of Exceptional Conditions (new). SSRF folded into A01.
• PTES — seven phases (Pre-engagement → Intelligence Gathering → Threat Modeling → Vulnerability Analysis → Exploitation → Post-Exploitation → Reporting). The standard is stalled (~2014) but still methodologically useful.
• NIST SP 800-115 (September 2008, no Rev 1) — four-phase model Planning → Discovery → Attack → Reporting. Appendix B contains a Rules of Engagement template.
• MITRE ATT&CK v19 (April 2026) — maps findings to real-world TTPs.
• CVSS v4.0 (November 2023) primary, v3.1 secondary (NVD still scores most CVEs in v3.1). Thresholds: Critical 9.0–10.0, High 7.0–8.9.
• CWE 4.20 (May 2026) — root-cause classification.

Supporting tools: Kali Linux 2026.1, Burp Suite Pro 2026.4, Metasploit 6.4.x, WebTesterAI (in-house).

Our template

The PDF authorization we use and ship with every offer: pisno-pooblastilo.pdf ↗ (SL) / written-authorization.pdf ↗ (EN). It contains all nine clauses, the GDPR Art. 28(3) clauses, escalation path, and Slovenian-specific signatory data (statutory representative / s.p. owner).

The template is a working starting point, not legal advice. For engagements with significant liability exposure (banking, healthcare, critical infrastructure), have a counsel review the concrete execution.

When this is worth doing

When the answer is yes to at least one of:

• An auditor, regulator, or insurer requires evidence of a pentest.
• Before production release of a product handling customer data.
• After an incident — an outside view of the same attack surface.
• Before extending access (new integration, new service, public API).

Penetration testing ↗ · Start a project ↗