A penetration test shows what is theoretically dangerous – and what an attacker can actually exploit.

A security audit documents where the risks are. A penetration test goes one step further: I test your systems in a controlled way, like a real attacker, and demonstrate which weaknesses are practically exploitable. The result is not a list of findings without weighting, but evidence with a reproducible attack path.


What is tested

The scope is agreed in writing before anything starts – what is tested, which systems, which techniques, which limits. Typical targets:

  • External test: Your publicly reachable infrastructure – web applications, e-mail, VPN, public interfaces.
  • Internal test: From the perspective of an employee or an attacker who already has access – segmentation, privilege escalation, critical systems.
  • Web application: Following OWASP, from login to data storage.

What is not in scope stays out. No surprises for your team: time windows, contact paths and abort criteria are clarified beforehand.


How the test works

Penetration Test Workflow

  1. Scope & rules: Written agreement on targets, time windows, and escalation. No test starts without this foundation.
  2. Active testing: Reconnaissance, identification and controlled exploitation – like an attacker, with documented procedure.
  3. Report: Prioritized findings with proof of exploitation, attack path and concrete remediation advice – in technical and plain language.
  4. Debrief & re-test: A session with your team and verification of the applied fixes.

Methodology

I work according to established frameworks (OWASP, PTES) and rate findings using CVSS. As an OSCP-certified security engineer I bring the offensive perspective – and because I harden cloud, Linux, and container environments day to day, I also know from the other side how a finding becomes a lasting fix.


What you get at the end

  • A report your IT team and management can read: executive summary plus technical detail per finding
  • Reconstructible attack paths with proof of exploitation – no theoretical “might be” entries
  • Prioritized recommendations: what now, what this quarter, what later
  • A re-test of the critical fixes, so the proof actually holds

Billed transparently by the hour – scope and frame are agreed in writing beforehand, you will not get unplannable invoices.


Frequently asked questions

Do I need a security audit first? For most businesses, yes. The audit shows what a pentest should focus on – without that frame, a test often misses the biggest gaps. As a second step after the audit, a penetration test is the most sensible use.

How long does a penetration test take? It depends on the scope: an external test of a limited infrastructure is much smaller than an internal test including cloud. You get a realistic frame in the intro call – in writing, before anything starts.

Will my system be damaged during the test? No. The test follows agreed rules, in defined time windows, with a documented procedure. Destructive techniques are not part of my methodology; abort criteria are clarified in advance.

What happens to access and data after the test? Findings, credentials, and test data are deleted or returned after the project is completed. What is documented is in the report – nothing stays with me.

Does the price differ by scope? The overall frame is based on the agreed scope and is fixed beforehand. What drives the effort and how to compare offers is explained in my article What does a pentest cost?.


Intro call – free

30 minutes, no obligation: you describe your systems, I explain what can be tested in your case and what a realistic frame looks like. For an initial technical assessment.