Commissioning a Penetration Test: Scope, Providers, and Making the Most of Results

What a penetration test is and what it isn't

A penetration test is the controlled attempt to break into your company's systems — with your permission and by qualified specialists. The goal is not to cause damage but to identify vulnerabilities that a real attacker could exploit.

It's important to distinguish a pentest from related but different methods:

Vulnerability scan: An automated scan that identifies known vulnerabilities in systems. Fast, inexpensive, but superficial. A scanner finds that a server uses an outdated software version but doesn't check whether the vulnerability is actually exploitable.

Penetration test: Goes significantly further. A pentester uses automated tools and manual techniques to find and exploit vulnerabilities. They chain multiple vulnerabilities to demonstrate that an attacker can progress from internet access to domain admin privileges. The result is a realistic picture of the attack surface.

Red teaming: The top discipline. A red team simulates a real attack over an extended period (weeks to months), uses all available attack vectors (technical, physical, social engineering), and tests not only technical security but also detection and response capabilities. Significantly more resource-intensive and expensive than a pentest.

For most SMEs, a penetration test is the right choice: more comprehensive than a vulnerability scan, but with manageable effort and budget.

Step 1: Define the scope

Why scope determines everything

The scope defines what is tested, how deeply it is tested, and what methods are permitted. A poorly defined scope is the most common reason for unsatisfactory pentest results: either the scope is so broad that the pentester only scratches the surface of everything, or so narrow that critical areas aren't tested at all.

Scope dimensions

What is tested?

• External network: All systems and services reachable from the internet (web server, VPN gateway, email server, DNS). The most common entry point for attacks.
• Internal network: Systems on the internal network. Requires the pentester to have access to the internal network (physically on-site, VPN, or simulated insider).
• Web applications: Specific web applications (customer portal, web shop, intranet). Tests OWASP Top 10, authentication, authorization, input validation.
• Mobile applications: Company apps for iOS/Android. Tests the app itself and the API communication.
• Wi-Fi: Security of the corporate WLAN, guest Wi-Fi, segmentation.
• Social engineering: Phishing campaigns, phone calls, physical access. Optional and separate from the technical pentest.

How is testing conducted?

• Black box: The pentester has no prior information about the target systems. They act like an external attacker who only knows the company from public sources. Most realistic but also most time-intensive.
• Grey box: The pentester receives limited information, e.g., IP address ranges, network diagrams, or user credentials. A good compromise between realism and efficiency.
• White box: The pentester gets full access to documentation, source code, configurations, and architecture documents. Most efficient because the pentester doesn't spend time on reconnaissance, but least realistic.

What is forbidden?

Explicitly define what the pentester may not do:

• Denial-of-service attacks (could take down production systems)
• Access to certain systems (e.g., production databases with customer data)
• Social engineering against specific individuals (e.g., executive management)
• Testing outside defined time windows (e.g., not during peak business hours)
• Physical access to certain areas

Scope recommendation for the first pentest

If you're commissioning a pentest for the first time, I recommend a two-part approach:

1. External network pentest: Test all systems reachable from the internet. This is the area an attacker sees first, and this is where the most critical vulnerabilities often lie.

2. Web application pentest for the one or two most important web applications (customer portal, web shop). Web applications are a common attack vector and require specialized testing.

You can plan the internal network pentest as a second step once the external vulnerabilities have been remediated.

Step 2: Find the right provider

Qualifications and certifications

The pentest industry has no uniform regulation, which means quality varies significantly between providers. Look for the following qualifications:

Individual certifications of the pentesters:

• OSCP (Offensive Security Certified Professional): The de facto standard for technical pentest competence. Requires demonstrating practical skills in a 24-hour exam.
• OSCE/OSWE/OSEP: Advanced Offensive Security certifications for specialized areas.
• CREST CRT/CCT: British standard, internationally recognized.
• CEH (Certified Ethical Hacker): Entry-level certification, less hands-on than OSCP.

Company certifications:

• BSI recognition: Germany's BSI maintains a list of recognized IT security service providers. Recognition as a penetration testing provider by the BSI is a strong quality indicator.
• CREST accreditation: International accreditation for pentest companies.
• ISO 27001 of the provider: Shows that the provider itself takes information security seriously.

Comparing proposals

Obtain at least three proposals and compare them using the following criteria:

Understanding of the scope: Has the provider understood the scope and asked follow-up questions? A provider that submits a proposal without questioning the scope either has little experience or little interest in a high-quality result.

Number of pentesters and test days: How many people will test for how long? An external network pentest for a mid-sized company should comprise at least five test days. A web application pentest for a complex application requires at least five to ten days.

Methodology: What methodology is used? Established frameworks include the OWASP Testing Guide (for web applications), PTES (Penetration Testing Execution Standard), and the BSI practical guideline for IS penetration tests.

Sample report: Request an anonymized sample report. The quality of the report is the most important differentiator. A good report contains a management summary, a risk assessment in business context, detailed technical descriptions of findings with evidence (screenshots, logs), and prioritized recommendations.

Retest: Does the provider offer a retest to verify whether vulnerabilities have actually been closed after remediation? A retest is essential and should be included in the proposal or available as an option.

Price range

Pentest prices vary widely, but as a reference for the German market:

• External network pentest (mid-sized company, 5-10 test days): 8,000 to 20,000 euros
• Web application pentest (one application, 5-10 test days): 8,000 to 25,000 euros
• Internal network pentest (5-10 test days, incl. travel): 10,000 to 25,000 euros
• Wi-Fi pentest (2-3 test days, on-site): 4,000 to 8,000 euros

If a provider is significantly below these figures, you should question how much manual work is actually being performed. A pentest that essentially consists of an automated vulnerability scan with an attached report is not a pentest.

Step 3: Prepare for the pentest

Contractual foundations

Before the pentest begins, the contractual foundations must be in place:

Authorization letter (Permission to Test): A formal letter from executive management authorizing the pentest and defining the scope. Without this document, the pentester is potentially acting illegally, regardless of the contractual agreement.

Non-disclosure agreement (NDA): The provider commits to confidentiality regarding the results and all information obtained during testing.

Scope document: Detailed description of the test scope: IP addresses, URLs, test period, test methods, exclusions, contacts, escalation paths.

Liability clause: What happens if the pentest inadvertently causes damage (e.g., crashes a server)? Most pentesters carry professional liability insurance, but the liability question should be contractually settled.

Internal preparation

Designate a point of contact: Define a primary contact for the pentester. This person must be reachable during the test period and able to make decisions (e.g., "The scanner found a critical vulnerability and the exploit attempt could impact the server. Should I proceed?").

Inform the IT team: Inform the IT team about the pentest. Define whether the pentest is covert or open. In a covert test, the IT team doesn't know when the test takes place, and detection and response capabilities are tested as well. In an open test, the team knows and can classify unusual activity.

Verify backups: Ensure current backups exist for all in-scope systems. For the unlikely but possible case that the pentest impacts a system.

Adjust monitoring: If you operate an IDS/IPS or SIEM, decide whether the pentester's IP addresses are whitelisted (open test) or whether detection remains active (covert test).

Step 4: Read and understand the pentest report

Structure of a good report

A professional pentest report typically consists of the following sections:

Management summary (1-2 pages): A non-technical summary of the results, aimed at executive management. Overall security assessment, number and severity of findings, the three to five most critical risks, and an overall assessment.

Methodology: Description of methods used, tools, and timeline.

Findings: The heart of the report. Each finding contains:

• Title and identifier
• Severity (Critical / High / Medium / Low / Informational)
• Description of the vulnerability
• Proof of concept: screenshots, logs demonstrating the vulnerability is actually exploitable
• Impact: What an attacker can achieve with this vulnerability
• Recommended remediation: Concrete, actionable measures
• References: CVE numbers, OWASP categories, CWE classification

Positive findings: What's working well. This section is unfortunately missing from many reports but is valuable because it shows where the company is already well-positioned.

Putting the severity in context

The severity rating in the pentest report is typically based on technical criteria (CVSS score or a comparable system). This rating is important, but it doesn't represent business risk. A technically critical vulnerability on a test system has different business relevance than the same vulnerability on the ERP system.

Transfer the technical findings into your ISMS risk context: Assess each finding by likelihood (how difficult is exploitation? how exposed is the system?) and business impact (what data, processes, or systems are affected?). This assessment provides the basis for prioritizing remediation.

Step 5: Implement results

Prioritizing findings

Not all findings need to be fixed immediately. Prioritize by the combination of severity and feasibility:

Immediate (within one week): Critical and high findings that are exploitable from the internet and can lead to compromise. Example: SQL injection in the customer portal, unprotected admin access.

Short-term (within one month): High and medium findings that are exploitable in combination with other vulnerabilities. Example: Missing network segmentation, outdated software versions with known exploits.

Medium-term (within three months): Medium and low findings that improve the security posture but don't pose an acute risk. Example: Missing security headers on web pages, informational findings.

Risk accepted: Findings that, after conscious risk assessment, are accepted because remediation is disproportionately costly or the residual risk is bearable. This decision must be documented and approved by the risk owner.

Create an action plan

For each finding that will be remediated, create a measure with:

• Description of the measure (What exactly will be done?)
• Responsible party (Who implements the measure?)
• Deadline (By when must the measure be implemented?)
• Verification (How will it be checked whether the measure is effective?)

Commission a retest

After remediating critical and high findings, a retest should take place. The pentester specifically checks whether the reported vulnerabilities have actually been closed. A retest is typically much cheaper than the initial test because the scope is limited to the known findings.

The retest gives you evidence that vulnerabilities have been remediated — documentation you can include in the ISMS and present during audits.

Penetration testing as a recurring process

Frequency

A single pentest is a snapshot. The security posture changes continuously: new vulnerabilities are discovered, systems are updated, new services go online. Therefore, pentests should be repeated regularly:

• Annually: For the critical infrastructure and the most important web applications.
• After major changes: New system, new web application, network restructuring, cloud migration.
• Before certification audits: A current pentest report with remediated findings makes a positive impression on the auditor.
• After security incidents: To ensure that entry points are closed and no further vulnerabilities exist.

Pentest results in the ISMS

Pentest findings feed into multiple ISMS processes:

• Risk assessment: Critical findings are captured and assessed as risks. In ISMS Lite, pentest findings can be imported directly as measures and linked to the associated risk, including deadline, responsible party, and retest status.
• Action tracking: Remediation is tracked as a measure with responsible party and deadline.
• Management review: Executive management receives a summary of results and remediation status.
• Internal audit: The auditor verifies whether pentest findings are systematically addressed.
• Continual improvement: Recurring vulnerability patterns indicate systemic issues that need to be addressed beyond individual remediation.

A penetration test is an investment that only pays off when you consistently implement the results. A report that sits unread in a drawer is wasted money. A report whose findings are systematically remediated and tracked is one of the most effective instruments for improving your security posture.

Further reading

• Building vulnerability management: From scan to remediation
• Risk assessment in the ISMS: Methodology, matrix, and practical example
• Network segmentation for SMEs: Fundamentals and implementation
• Patch management for mid-market companies: Process, tools, and prioritization
• Working with external consultants and service providers