Penetration testing compliance: How to ensure compliance and effectiveness

Not every penetration test report will pass an auditor's desk. That statement sounds surprising, but in practice it is exactly the problem that hits a significant share of security teams in Europe. Companies invest in pentests, receive documents with a list of vulnerabilities, and then it turns out the report does not meet ISO 27001, GDPR or any other standard. A pentest by itself is not compliance. Compliance is a set of requirements around scope, authorisation, methodology and documentation - without them, no test has evidentiary value.

Table of contents

• What penetration testing compliance is and why not every pentest counts

• Which regulations and standards require compliance-grade pentests in Europe

• Pentest vs assessment: what meets the requirements and what does not?

• Effective execution: how to prepare and deliver a compliance-grade pentest

• What is missing in most compliance pentests - our observations

• Tools and support for effective compliance-grade penetration testing

• Frequently asked questions

Key takeaways

What penetration testing compliance is and why not every pentest counts

Let's start with a clear distinction. Penetration testing compliance is more than just running the test. The SANS Glossary defines a pentest itself as a controlled simulation of an attack aimed at verifying system resilience - the term "penetration testing compliance" goes beyond that definition and means aligning such tests with specific regulations and policies: with a legal, authorized and controlled execution and with evidentiary value for audit. It is not about whether someone ran Nmap and Metasploit. It is about whether the whole process meets the formal and procedural requirements set by a regulator or a standard.

In practice, compliance requires several elements that an ordinary penetration test may not include:

• Written authorisation: every test must have explicit permission from the system owner. Without an authorisation document, the test does not exist from the auditor's point of view.

• Defined scope: exactly what is tested - which IP addresses, systems, applications and within which time window.

• Rules of engagement: rules defining which techniques are allowed, what is forbidden and who is the point of contact in emergencies.

• Methodology: a reference to a recognised methodology. For web applications - OWASP WSTG (Web Security Testing Guide); for mobile - OWASP MASTG. For infrastructure, networks and Active Directory - PTES (Penetration Testing Execution Standard), NIST SP 800-115 or OSSTMM. For the financial sector under DORA - TIBER-EU/TLPT.

• Results documentation: not a list of vulnerabilities but documented evidence of exploitation, real attack paths and risk assessment.

The key difference between a compliance pentest and a regular assessment is that compliance requires evidence, not just results. The auditor does not ask "was there a test", but "what did it prove and how was it carried out".

How does a compliance-grade pentest differ from a vulnerability assessment? A vulnerability assessment is, in short, automated or partially manual discovery of known flaws based on the CVE database. A pentest goes further. The pentester actively tries to exploit vulnerabilities, chain them into attack paths and prove real risk. For compliance, that real-attacker simulation element is exactly what matters.

It is also worth pointing out that "ticking off" a pentest on a task list is one of the most common mistakes. Organisations commission a test, receive a PDF report and drop it into a compliance folder. The auditor asks about scope, authorisation, rules of engagement and exploitation evidence. If those elements are missing, the report is useless from a compliance perspective.

Which regulations and standards require compliance-grade pentests in Europe

We have the definition. Now the concrete regulations and standards that impose real requirements in this area.

GDPR (General Data Protection Regulation)

Article 32 of GDPR requires organisations processing personal data to implement "a process for regular testing, assessing and evaluating the effectiveness of technical and organisational measures". GDPR does not mention the word "pentest", but European regulators and supervisory authorities have repeatedly interpreted that provision as a requirement for regular technical security testing. As GDPR cybersecurity requirements notes, GDPR promotes regular testing of security control effectiveness, which is often interpreted as a pentest requirement.

What does this mean for the pentester? If you run a test for an organisation under GDPR, the report has to clearly show which personal-data protection measures were tested and how effective they are. A bare CVE list proves nothing here.

ISO 27001

ISO/IEC 27001:2022 is the current version of the information security management standard (the transition period from the 2013 version ended on 31 October 2025 - auditors today refer to the new numbering). Control A.8.8 "Management of technical vulnerabilities" (formerly A.12.6.1 in the 2013 version) covers management of technical vulnerabilities, and control A.5.36 "Compliance with policies, rules and standards for information security" (formerly A.18.2.3) explicitly requires technical compliance reviews. ISO 27001 does not mandate pentests by name, but auditors expect objective evidence of control effectiveness. In practice, this means that if your ISMS (Information Security Management System) states that the controls are effective, you have to prove it. And a properly documented pentest is exactly that proof.

NIST SP 800-115

NIST Special Publication 800-115 is the technical document describing the methodology for conducting security tests. It defines four phases: planning, discovery, attack and reporting. For compliance, what matters is that NIST requires documenting each stage of the process with enough precision to allow the results to be reproduced.

European context

DORA (Digital Operational Resilience Act), in force for the financial sector since 17 January 2025, requires Threat-Led Penetration Testing (TLPT) for critical institutions. TLPT is based on the TIBER-EU framework developed by the European Central Bank - an operational document defining requirements for scope, threat intelligence and red teaming under national regulator oversight.

NIS2 (EU Directive 2022/2555) is today the main driver of pentests in the EU for essential and important entities: energy, transport, healthcare, water, digital infrastructure, ICT service providers, public administration. In Poland it is implemented through the Act on the National Cybersecurity System (KSC). Article 21 requires cybersecurity risk management, including assessment of control effectiveness - regulators interpret this as a requirement for regular technical testing. Penalties: up to EUR 10 million or 2% of global turnover (essential entities), up to EUR 7 million or 1.4% (important entities).

CRA (Cyber Resilience Act, Regulation EU 2024/2847) entered into force in December 2024 (main obligations from 11 December 2027). It imposes security-by-design requirements and security testing on manufacturers of products with digital elements - IoT hardware, software, connected devices. Pentest becomes part of the conformity assessment before placing a product on the EU market.

Pentest vs assessment: what meets the requirements and what does not?

You already know which regulations matter. Time for a practical distinction: which actions actually meet compliance requirements.

Pentest and vulnerability assessment sound alike. In practice they are two different services with completely different evidentiary value. As SANS pentest vs. assessment puts it, a pentest is an attack simulation, an assessment is the identification of known vulnerabilities - and compliance generally requires the former.

What exactly does a compliance auditor check in a pentest report? Here is the list of key elements that have to appear in the documentation:

1. Authorisation document signed by the system owner or the board.

2. Scope with a precise list of the systems, networks and applications covered by the test.

3. Rules of engagement describing allowed and forbidden techniques.

4. Methodology reference (PTES, OWASP, NIST SP 800-115 or another recognised standard).

5. Exploitation evidence: screenshots, logs, PoC (proof of concept) for every critical vulnerability.

6. Business risk assessment in the context of the tested environment.

7. Remediation recommendations with prioritisation.

8. Date and report version with the name of the person responsible.

NIST and ENISA guidance for EU regulations agree on this point: compliance requires evidence of a test in adversarial conditions. That means a pure automated scan, even with thousands of results, will not replace a documented exploitation attempt.

Pro tip: before you start the test, prepare a documentation template aligned with the standard you need to meet. Fill it in as you go, not after the test ends. Auditors can tell live-written documentation from one written post factum.

It is also worth reading the fuzzing guide, which covers advanced vulnerability discovery techniques that map directly onto proving the reality of attacks.

Effective execution: how to prepare and deliver a compliance-grade pentest

With the differences and the standards behind us, it is time to show in practice how a compliance-grade pentest plays out step by step.

A properly run compliance pentest goes through six phases:

1. Planning and authorisation: a meeting with the client, defining business and technical goals, signing the authorisation document. This stage sets the legal frame. Without this step, none of the later ones has any value.

2. Scope and rules of engagement: a precise list of systems, production systems sensitive to downtime excluded, test windows, contact details. The scope has to be detailed enough to be verifiable once the test ends.

3. Reconnaissance and discovery: gathering information about the infrastructure, mapping the network, identifying potential attack vectors. The output of this stage must be documented, because it shows what was available to a hypothetical attacker.

4. Exploitation and proof: active attempts to exploit vulnerabilities, chaining them into attack paths, escalating privileges. Every successful exploitation must be documented with a screenshot or a log, with a precise timestamp and the tool version.

5. Post-exploitation and risk assessment: what could the attacker actually do after breaking through? Could they reach personal data, payment systems, critical infrastructure? This stage matters most for compliance because it shows the real business risk.

6. Reporting and review: the report comes in two layers - technical (for pentesters and developers) and an executive summary (for the board and auditors). The report has to allow the findings to be defended at audit.

As CREST guidance on "defensible penetration test" puts it, what matters is the quality of the evidence: scope, rules of engagement, precise documentation and the ability to defend the report at audit.

What do auditors look for in the documentation? Above all, consistency. The scope defined at the start has to match the systems discussed in the report. Exploitation evidence has to be tied to specific vulnerabilities. Recommendations have to be actionable and tied to risk.

The most common mistakes in compliance pentests are:

• No authorisation document, or authorisation from someone without the right authority.

• Scope too vague: "all IT infrastructure" without a list of IP addresses and system names.

• No timestamps in the exploitation evidence.

• Report only technical, with no business risk assessment and no executive summary.

• No methodology reference: the auditor cannot tell which criteria guided the pentester.

• Test run purely automated: scanners do not replace manual verification and exploitation.

Pro tip: if you want your report to truly stand up to auditor questions, add a "Limitations" section describing what the test did not cover and why. That shows methodological maturity and prevents scope misunderstandings.

Advanced techniques like fuzzing map directly onto documenting the reality of exploitation. A detailed approach is covered in the application fuzzing article, which works well as a methodology complement.

What is missing in most compliance pentests - our observations

Working with security specialists and tracking the reports that land on auditors' desks, we see a clear pattern. Most compliance problems do not come from poor technical quality of the test. They come from a lack of documentation discipline and a misreading of what the auditor is actually looking for.

The first and most common problem is a scope described too broadly. "We tested the client's network infrastructure" is a sentence that proves nothing. The auditor needs a list: which servers, which applications, which IP ranges, in which time window. Without that precision, even a technically excellent test cannot be accepted as compliance evidence.

The second problem is the lack of exploitability verification. Many reports contain long lists of vulnerabilities at CVSS 9.0+, but not a single proof that any of them is actually exploitable in the tested environment. Compliance demands a real-attack simulation, not a list of theoretical threats. Auditors increasingly understand this difference and increasingly reject reports built purely on automated scans.

The third problem is reports written exclusively for technicians. Compliance touches the whole organisation, and decisions are taken by the board. A report without an executive summary and a business risk view is useless to a decision maker and often blocks auditor acceptance.

In our view, the most important parameter of pentest compliance is how realistic the simulated attack is. It is not about whether the pentester used the newest technique. It is about whether the test reflected the real threats facing the specific environment. The attackers that really threaten European companies are not academic researchers. They use simple, proven vectors: phishing, weak passwords, outdated public-facing services. A pentest that focuses only on exotic exploits and skips those vectors creates a false sense of security.

A separate issue is the quality of the upfront agreements. Rules of engagement, scope and the business goal of the test should be agreed in writing before the start. We see too many cases where pentesters begin work without clear framing and then have to "retrofit" the documentation to a finished report. It always shows. Experienced auditors recognise it.

When it comes to tooling, good laboratory gear has a serious effect on the quality of the evidence. Equipment for Wi-Fi testing, RFID/NFC analysis kit and dedicated attack-simulation accessories produce reproducible evidence - the kind that can be verified and replayed. That is exactly the standard a solid compliance pentest demands. For more on advanced evidence-gathering techniques, take a look at the practical fuzzing guide, which describes methods that translate directly into the evidentiary value of the report.

Tools and support for effective compliance-grade penetration testing

You have the knowledge. Now it is time to gear up with hardware that lets you apply it in practice and produce evidence auditors will accept.

Sapsan is a European distributor of specialist gear for pentesters and IT security professionals. The lineup covers Wi-Fi testing tools, RFID/NFC analysis devices, SDR (Software Defined Radio) equipment, BadUSB accessories and Flipper Zero add-ons. It is hardware made for real testing in lab and production conditions, producing exploitation evidence in a form auditors accept. Every device available at sapsan-sklep.pl is chosen with professional use cases in mind: wireless network pentests, physical access security testing, radio protocol analysis and IoT attack simulation. Orders ship across Europe.

Frequently asked questions

Is every regular vulnerability scan enough for compliance?

No - compliance demands realistic pentest-class testing rather than just automated scanning. As SANS pentest vs. assessment notes, compliance requires real attack simulations, not just gap detection.

Does GDPR mandate pentesting by name?

GDPR does not explicitly call out pentesting, but Article 32 imposes an obligation of regular testing of security control effectiveness. As the GDPR cybersecurity requirements stress, the obligation to regularly test the effectiveness of controls is interpreted by regulators as the need to run pentests.

What form of pentest report do compliance auditors accept?

Auditors prefer reports with a clear scope, written agreements, evidence from realistic tests and concrete recommendations. According to penetration testing code compliance, the quality of the report has to allow the findings to be defended at audit.

How often should compliance-grade pentests be run?

The frequency should come from a risk analysis: the volatility of the environment, the sensitivity of the data and the pace of change in IT systems. The European context calls for a risk-based approach, not a fixed test calendar.