What Is Included in a Professional Penetration Test? (And What Most Vendors Leave Out)
Most companies that commission a penetration test have never done it before. They know they need one, they know it matters, and they know that the quote in front of them looks either surprisingly cheap or surprisingly expensive. What they usually do not know is what a thorough engagement actually looks like from the inside.
That knowledge gap is where a lot of money gets spent on very little value.
The penetration testing market is not well regulated in most regions. Anyone can build a website, use the right terminology, and sell a security assessment. The output of a poor engagement looks remarkably similar to the output of a thorough one, at least until the moment a real attacker finds the gap that the vendor missed.
Understanding what a professional penetration test is supposed to include is not a technical exercise. It is a buyer decision. And it is one of the most important decisions a security-conscious company makes. Capture The Bug has conducted engagements across hundreds of organisations in Australia, New Zealand, and the United States. What follows is a clear account of what a professional penetration test includes, what distinguishes quality from surface coverage, and what buyers most commonly find missing from the report they received.
Scoping: The Foundation That Determines Everything Else
A penetration test without a properly defined scope is not a penetration test. It is a guessing exercise.
Professional scoping begins with a structured conversation about what the organisation does, what systems are in play, what data those systems handle, what the highest-risk areas are likely to be, and what the testing is intended to prove or discover. The output of that conversation is a written scope document that both parties agree to before testing begins.
The scope document should define which systems, applications, and environments are included. It should define what is explicitly excluded and why. It should identify any systems that require special handling, such as production databases that cannot be taken offline during testing. And it should establish the rules of engagement, including the testing timeframe, the hours during which active testing is permitted, and the communication protocol if a critical vulnerability is discovered mid-engagement.
What most vendors leave out at this stage is the challenge conversation. A professional scoping process does not just record what the client says they want tested. It asks whether the scope as defined actually reflects the real attack surface. It identifies gaps between what a client thinks is in scope and what an attacker would realistically target. A vendor that simply accepts the first scope draft without questioning it is already leaving value on the table.
Reconnaissance: Understanding the Target Before Testing Begins
Before any active testing occurs, a professional penetration test includes a structured reconnaissance phase. This is the process of gathering information about the target from publicly available sources to understand how the organisation and its systems appear from the outside.
Reconnaissance covers a range of areas. It includes mapping the domains, subdomains, and internet-facing assets associated with the target. It includes reviewing publicly exposed information such as job listings (which often reveal the technology stack in use), public code repositories, and any data that has appeared in previous security incidents. It includes identifying third-party services and integrations that may represent indirect attack paths.
This phase matters because attackers do not skip it. A threat actor planning to target an organisation does not start by firing requests at the login page. They spend time understanding the perimeter, identifying the most accessible entry points, and looking for information that reduces the effort required to get in.
A penetration test that skips meaningful reconnaissance is a test conducted in an unrealistic context. It may find vulnerabilities, but it will not find the ones a real attacker, working methodically, would find first.
The Testing Methodology: What Gets Covered and How Deeply
The core of a professional penetration test is the active testing phase, and this is where the most significant variation between vendors exists.
For a web application engagement, professional testing covers the full OWASP Top 10 as a baseline, but does not stop there. Injection vulnerabilities across multiple input types are explored. Authentication mechanisms are tested for weaknesses including credential brute-forcing resistance, session management flaws, and multi-factor authentication bypass paths. Access control is tested both horizontally (can one user access another user's data) and vertically (can a lower-privileged user access functionality reserved for administrators). Business logic vulnerabilities, which are specific to the way the application works rather than generic vulnerability classes, are explored through manual testing.
For API testing, professional engagements test every endpoint, not just the ones documented in a public API reference. They test for authentication requirements on each endpoint individually rather than assuming authentication is applied globally. They test for rate limiting, mass assignment vulnerabilities, and the handling of unexpected input types. They test for differences in access control behaviour between the web interface and the API layer, which is a common source of real vulnerabilities that generic assessments miss.
For network and infrastructure engagements, professional testing covers service enumeration, configuration review, privilege escalation paths, and lateral movement opportunities within the defined scope.
What most vendors leave out is depth of manual testing. A significant portion of the market uses primarily known-vulnerability checks, which find issues that match a known signature or pattern. Manual testing, conducted by a skilled tester who understands the specific application, finds the logic flaws and configuration issues that do not match any known signature because they are unique to that system. Capture The Bug's approach to penetration testing is built around manual-led engagements. The scope of what that covers and how engagements are structured is detailed at our services page.
Exploitation: Proving the Vulnerability Is Real
Finding a vulnerability and proving it is exploitable are two different things. A professional penetration test includes controlled exploitation of identified vulnerabilities to demonstrate real-world impact.
This matters for two reasons. The first is accuracy. Not every identified vulnerability is actually exploitable in the context of the specific environment. A finding that looks serious on paper may be mitigated by a compensating control elsewhere in the system. Exploitation attempts separate confirmed vulnerabilities from theoretical ones and allow the report to prioritise accurately.
The second reason is business communication. Telling a development team or a board that a cross-site scripting vulnerability exists in the login page is one level of communication. Showing them a demonstration of that vulnerability being used to capture a session token and log in as an arbitrary user is a different and more impactful level. Exploitation evidence makes the business case for remediation in a way that a description alone does not.
What most vendors leave out is evidence. Reports that list vulnerability names without exploitation evidence, session recordings, screenshots, or proof-of-concept documentation are harder to act on and harder to evaluate. A thorough engagement produces evidence that a developer can understand and a non-technical stakeholder can appreciate.
The Report: Where Most Engagements Lose Their Value
The penetration test report is the deliverable that has to work for multiple audiences at once. The security team needs technical detail. The development team needs actionable remediation guidance. The executive team or board needs a clear picture of business risk. The compliance team needs documentation that satisfies an auditor.
A professional report covers all of these. Each finding is documented with a consistent structure: a clear description of the vulnerability, the evidence of its existence, the steps taken to reproduce it, the potential business impact if exploited, a severity rating with justification, and specific remediation guidance that a developer can implement without further research.
The report also includes an executive summary that communicates overall risk posture in plain language, a summary of testing scope and methodology, and a findings breakdown by severity.
What most vendors leave out is actionability. Reports that list CVE numbers without explaining the specific instance of the vulnerability in the target system, or that provide generic remediation advice (update the library, apply the patch) without identifying exactly where and how, require the development team to do significant work before they can act. That additional work introduces delay and increases the chance that remediation is incomplete.
The other thing vendors frequently leave out is a risk narrative. A report that lists twenty findings of various severities without explaining how they relate to each other, whether any of them can be chained, and what the overall security posture looks like, misses the most important piece of context a security leader needs to make decisions.
Retesting: Closing the Loop on Remediation
A penetration test that ends with the delivery of the report is a test that ends at the most important moment. Remediation is where the security value is actually realised, and retesting is how you know the remediation worked.
Professional engagements include a retesting phase after the development team has addressed the identified findings. The retest confirms that fixes are effective and complete. It verifies that new issues were not introduced during the remediation process. And it produces documentation that a finding identified on a specific date was confirmed as resolved on a subsequent date, which is exactly what SOC 2, ISO 27001, and PCI-DSS auditors need to see.
What most vendors leave out is either retesting entirely, or they charge separately for it without disclosing that upfront. Buyers should ask explicitly whether retesting is included in the engagement scope before signing anything. Capture The Bug builds retesting into its engagement model because a finding without a verified fix is an incomplete result. The full structure of how that process works across different engagement types is available at our services page.
The Difference Between a Professional Engagement and a Compliance Checkbox
There is a version of penetration testing that exists primarily to generate a document that can be filed in an audit folder. It is priced to be affordable, scoped to be achievable, and reported in a way that satisfies the minimum requirement of whatever framework is asking for it. It is not useless. But it is not the same thing as a security engagement.
The companies that get the most value from penetration testing are the ones that treat it as an operational security practice rather than a compliance obligation. They start with a realistic scope. They engage a team that conducts meaningful reconnaissance and manual testing. They receive a report that their development team can act on. They retest their fixes. And they use the documented history of that process as evidence of a functioning security programme.
That is what a professional penetration test looks like. It is also what Capture The Bug is built to deliver, for SaaS companies and enterprises across Australia, New Zealand, and the United States, at every stage of their security programme.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
What should be included in a professional penetration test report?
A professional report includes an executive summary written for non-technical stakeholders, a methodology section explaining what was tested and how, individual findings each documented with a description, reproduction steps, exploitation evidence, business impact, severity rating, and specific remediation guidance. It should also include a risk narrative that contextualises the findings collectively, not just as a list.
How long does a professional penetration test take?
Duration depends on scope. A focused web application engagement typically runs between five and ten business days of active testing. A broader engagement covering APIs, network infrastructure, and multiple applications takes longer. The reconnaissance phase and retesting phase add time beyond the core testing window. Any engagement quoted at under three days for a meaningful application should be evaluated carefully.
What is the difference between a vulnerability assessment and a penetration test?
A vulnerability assessment identifies potential weaknesses, typically using known-vulnerability checks against a defined surface. A penetration test goes further by actively attempting to exploit identified weaknesses, chain vulnerabilities together, and demonstrate real-world business impact. For compliance purposes, both serve different functions. A penetration test is a more rigorous and more evidentially valuable exercise.
Why does manual testing matter in a penetration test?
Known-vulnerability checks find issues that match a pre-existing signature or pattern. Manual testing, conducted by a skilled tester who understands the application, finds logic flaws, business-specific vulnerabilities, and configuration issues that have no known signature because they are unique to that system. Many of the most impactful vulnerabilities found in professional engagements are ones that only manual testing would identify.
Should retesting be included in a penetration test engagement?
Yes. A penetration test that does not include retesting leaves the engagement incomplete at its most important point. Retesting verifies that identified vulnerabilities were actually fixed and that fixes did not introduce new issues. It also produces the remediation documentation that compliance frameworks require. Buyers should confirm before signing whether retesting is included or whether it is billed separately.
