A penetration test shows what an attacker could do to your application, API or infrastructure - before someone actually does it. For a test to deliver value, you need the right scope, approach and provider, and then you need to be able to read the report and plan the fixes. That is what this category is about.
Our guide to comparing penetration testing proposals shows how to send every provider the same request for proposal, how to set the proposals side by side in a comparison table, which questions to ask and which red flags to look out for - so that you judge the scope, the report and the rules of engagement before you look at the price.
When we write about penetration testing, we focus on what matters for your decision: how to tell a real penetration test from a vulnerability scan, what a good report should contain - technical evidence, steps to reproduce and a severity rating such as a CVSS score - and why a retest should be part of the proposal. How a standard penetration test differs from threat-led penetration testing under DORA is explained in our DORA category: penetration testing vs TLPT.
We draw on our own tests, but without client data - sample vulnerabilities are demonstration data. We state the versions of the standards (OWASP Top 10:2025, ASVS 5.0, WSTG v4.2) explicitly, so it is clear what we work to.
If you are planning a test, see our penetration testing services and the factors that affect the cost of a pentest. Terms such as IDOR, grey-box and OWASP Top 10 are explained in our glossary.