A useful penetration testing service should give engineering teams validated findings they can fix and compliance teams evidence they can defend. Not a scanner export with severity labels and no explanation of exploitability, business impact, ownership, or retest status.
In buyer terms, penetration testing is a controlled assessment that mimics real-world attack techniques to identify ways security controls could be bypassed and to verify vulnerabilities. Vulnerability scanning helps identify potential weaknesses such as outdated software, missing patches, and misconfigurations, but scanner output is not the same as a validated penetration-test finding. NIST also notes that automated tools can support discovery, while manual examination is generally more accurate when validating vulnerabilities. (NIST SP 800-115)
What a credible penetration testing service should deliver
A credible engagement combines clear scope, authorised testing, automated discovery where useful, manual validation, controlled exploitation where safe, and remediation guidance that engineers can act on.
The service should answer four practical questions:
- What is exploitable? Not every detected issue is reachable, practical, or material in your environment.
- What evidence proves it? Findings should include enough protected evidence to support reproduction and decision-making.
- Why does it matter? Security leaders need business impact, affected assets, and prioritisation.
- What should be done next? Engineers need specific remediation guidance, not generic “patch this” language.
Penetration testing is also different from red teaming. A red-team assessment often emulates threat actors to assess whether people, processes, and technology detect and respond to simulated activity. (CISA) A penetration test is usually narrower, it validates weaknesses in an agreed scope and produces fixable findings.
Which penetration testing service do you need?
Use the table below as a scoping guide, not a universal service catalogue. The right scope depends on what you need to validate, what access you can provide, and what evidence your security or compliance process requires.
| Service type | Best fit | Typical scope | Prerequisites | Deliverables to request | Timeline/cost drivers |
|---|---|---|---|---|---|
| Web application penetration testing | SaaS products, customer portals, admin consoles, internet-facing business applications | Authenticated and unauthenticated testing of application functionality, access control, session handling, input handling, and business logic | Target URLs, test accounts, role definitions, staging or production decision, testing windows, escalation contacts | Confirmed findings with affected endpoints, proof, business impact, remediation guidance, and retest status if agreed | Number of applications, role complexity, business logic depth, production constraints, reporting depth |
| API penetration testing | Public or internal APIs used by web, mobile, partner, or integration workflows | Authentication, authorisation, object-level access, input validation, rate limits, and sensitive data exposure | API documentation, collections or specs where available, tokens or test credentials, sample workflows, environment details | Endpoint-level findings, request/response evidence where appropriate, abuse scenarios, remediation steps | Number of endpoints, auth flows, data model complexity, documentation quality, test account setup |
| External network penetration testing | Internet-facing infrastructure, perimeter exposure, remote access services | Externally reachable IPs, domains, services, and exposed management interfaces | Authorised IP ranges/domains, known exclusions, maintenance windows, escalation contacts | Validated externally exploitable weaknesses, affected assets, exposure paths, remediation priorities | Asset count, service diversity, change windows, restrictions on exploitation |
| Internal network penetration testing | Assessing risk from an internal foothold, office network, VPN, or segmented environment | Internal hosts, services, identity paths, misconfigurations, privilege escalation opportunities within agreed limits | Network access method, test machine or VPN, defined access level, segmentation details, monitoring contacts | Findings tied to internal attack paths, affected systems, evidence, containment or hardening guidance | Network size, segmentation, credentialed vs uncredentialed access, safety controls |
| Cloud penetration testing | Cloud-hosted applications, accounts, workloads, storage, and identity configurations | Cloud identity and access, exposed services, storage access, workload configuration, application attack paths where in scope | Cloud account details, permission model, target services, provider rules, read-only or test roles as agreed | Misconfiguration and exploitability findings, affected cloud resources, remediation guidance, evidence suitable for review | Account complexity, number of services, identity model, production safeguards |
| Mobile application penetration testing | iOS or Android applications handling sensitive workflows or data | Application behaviour, local storage, API communication, authentication/session handling, platform-specific risks | App builds, test accounts, API details, device requirements, backend scope agreement | App and backend findings, reproduction steps, evidence, remediation guidance for mobile and API teams | Platform count, app complexity, backend/API inclusion, build availability |
| Wireless testing | Corporate wireless networks, guest networks, office environments | Wireless configuration, segmentation, authentication, encryption, rogue or misconfigured access points where authorised | Physical location access, SSIDs, testing windows, authorisation boundaries | Network-specific findings, affected SSIDs or devices, segmentation and configuration recommendations | Sites covered, SSID count, physical access constraints, after-hours requirements |
| Social engineering or phishing assessment | Testing human-facing controls, reporting paths, and awareness response | Pre-agreed campaign scenarios, target groups, landing pages or call scripts where authorised | Written authorisation, target list approval, messaging approval, escalation and stop rules | Campaign outcomes, control observations, training or process recommendations | Target count, scenario complexity, approval workflow, legal/HR constraints |
| Compliance-driven penetration testing | Customer assurance, audit preparation, or control validation where technical testing evidence is needed | A technical test scoped to assets, controls, or environments relevant to the assurance request | Control objectives, audit request language, in-scope systems, evidence format expectations | Point-in-time report, scope, methodology, findings, remediation status, and any agreed control mapping | Evidence expectations, retesting needs, scope boundaries, reporting format |
For network testing, external and internal scopes represent different access scenarios. External testing can model an outsider with little target knowledge, while internal testing models an actor already on the internal network with a defined level of access. (NIST SP 800-115) Neither is universally sufficient; choose based on the attack scenario you need to validate.
How the engagement works from scoping to retesting
The quality of a penetration test is often determined before testing starts. That is a bit overstated, though; execution still matters. A planned engagement should document goals, management approval, rules of engagement, authorised activities, and how adverse impacts will be handled. Where production impact is a concern, testing may need to use non-production systems or restricted/off-hours techniques. (NIST SP 800-115)
A practical engagement should move through these steps:
- Discovery and scoping call
Define the business objective, target systems, excluded assets, access model, depth of testing, reporting needs, and whether retesting is required. - Rules of engagement
Agree what testers may do, when they may test, what data they may access, what exploitation is off limits, and who can approve changes during the engagement. - Access and environment preparation
Provide test accounts, allowlisting, VPN access, cloud roles, application builds, API documentation, or other prerequisites depending on the scope. - Testing window and communication plan
Set testing dates, escalation contacts, outage contacts, daily check-in expectations, and stop conditions. - Controlled testing and validation
Testers use tools where useful, but validate findings manually and avoid unnecessary disruption. If a finding could affect availability or sensitive data, escalation should happen before deeper exploitation. - Reporting and debrief
The provider explains confirmed findings, severity, evidence, remediation priorities, and operational implications for engineering and security leadership. - Remediation support
Engineering teams clarify findings, ask implementation questions, and decide remediation sequencing based on severity, exploitability, asset criticality, and release constraints. - Retesting or validation of fixes
Retesting should be explicitly included or separately scoped. When performed, it should update each relevant finding with validation evidence and status.
The rules of engagement matter most when testing production systems, identity platforms, payment flows, sensitive data stores, or shared infrastructure. No provider should imply testing is automatically risk-free.
What your engineering and compliance teams receive
A useful report should work for three audiences at once: leaders deciding priority, engineers fixing the issue, and compliance or GRC teams retaining evidence.
OWASP’s reporting guidance describes a consultancy-style security report as one that communicates business context and key risks to leaders while giving technical teams enough detail to understand, reproduce, and remediate each finding. Useful detail in a finding includes risk, impact, description, remediation steps, and appropriately protected evidence. (OWASP Web Security Testing Guide)
Ask for deliverables that include:
- executive summary and overall risk themes
- agreed scope, exclusions, dates, and methodology
- confirmed findings, not just unvalidated tool output
- severity rating and rationale
- affected assets, URLs, endpoints, hosts, accounts, or resources
- evidence such as screenshots, logs, or redacted request/response examples where appropriate
- business impact in plain language
- technical remediation guidance
- prioritised remediation plan
- retest status or validation outcome, if retesting is included
- evidence format suitable for audit or customer security review, where needed
Technical security testing can help identify vulnerabilities and verify conformance with policy or other requirements, but the resulting report is point-in-time assessment evidence, not a compliance guarantee. (NIST SP 800-115) If a framework-specific mapping is important, confirm exactly what the provider will map, what it will not cover, and how the evidence should be retained.
Hypothetical finding walkthrough
| Report field | Example content |
|---|---|
| Finding | Broken object-level authorisation in customer invoice API |
| Severity | High, based on authenticated access to another customer’s invoice data |
| Affected asset | api.example.com/v1/invoices/{invoice_id} |
| Evidence | Redacted request showing User A successfully retrieving an invoice associated with User B; response body masked to protect sensitive fields |
| Business impact | A valid low-privilege user could access another customer’s billing information, creating confidentiality, customer trust, and compliance evidence concerns |
| Remediation guidance | Enforce server-side ownership checks for every invoice request; do not rely on client-side filtering; add negative authorisation tests for cross-tenant access |
| Engineering owner/actionability | Backend API team; add object ownership validation in invoice service and regression tests in API test suite |
| Compliance usefulness | Supports evidence of issue identification, risk assessment, remediation planning, and validation once fixed |
| Retest status | Pending, fixed, or not remediated — only after an agreed validation pass |
This level of detail lets engineering move directly to implementation planning, while security and compliance teams can show what was tested, what was found, what was done, and what remains open.
What you need to prepare before testing
Preparation reduces delays and prevents ambiguous findings. The exact checklist depends on the scope, but most teams should be ready to confirm:
- target URLs, domains, IP ranges, repositories, applications, cloud accounts, or asset lists
- in-scope and out-of-scope systems
- test accounts, user roles, permissions, and sample workflows
- API documentation, collections, mobile builds, or architecture notes where relevant
- VPN, allowlisting, device, or physical access requirements
- whether testing will occur in staging, production, or both
- business-critical blackout windows
- escalation contacts for security, engineering, infrastructure, and application owners
- data sensitivity constraints and handling expectations
- written authorisation and rules of engagement
- whether retesting is required and how fixes will be validated
Do not assume the provider needs full administrative access. Also do not assume a black-box test is enough. The access model should basically match the risk scenario: unauthenticated attacker, authenticated customer, internal user, compromised workstation, privileged cloud role, or another defined position.
If the engagement may touch production, agree stop conditions before testing begins. For example, a tester who discovers a path that could modify customer data should know whether to stop at proof of access, continue in a test tenant, or escalate for approval.
What affects timing and cost
Exact timing and pricing require scoping because penetration testing is labour-intensive and depends on access, depth, safety constraints, and reporting expectations. Avoid buying solely on asset count or a fixed label such as “web app test” without clarifying what is actually included.
The main scoping factors to discuss are:
- number of applications, APIs, hosts, accounts, environments, or locations
- authenticated versus unauthenticated testing
- number of user roles and permission boundaries
- application workflow and business logic complexity
- internal, external, cloud, mobile, wireless, or hybrid scope
- production-safety restrictions and approved testing windows
- whether exploitation is limited, simulated, or fully validated where safe
- reporting depth and debrief requirements
- retesting or remediation validation
- evidence formatting needed for audit, customer review, or internal risk committees
If you are in scope for PCI DSS, confirm your current penetration-testing obligations against the applicable PCI DSS version and assessment approach. (PCI Security Standards Council) Do not generalise one framework’s requirements to every audit or regulation. Some audits treat it differently.
How to evaluate a penetration testing provider
Before requesting a quote, ask questions that reveal whether the engagement will produce validated, usable outcomes:
- Is the work automated-assisted, manually validated, or mostly scanning?
- What methodology guides the test?
- What experience and credentials do the assigned testers have for this scope?
- What assets, roles, and environments are included or excluded?
- What safety controls protect production systems?
- What are the escalation process and stop conditions?
- How are severity and business impact assigned?
- What evidence appears in each finding?
- Is remediation guidance included?
- Is a debrief included?
- Is retesting included or separately scoped?
- Can the report support audit or customer security review evidence without claiming compliance by itself?
- How will findings be handed to engineering owners for remediation?
A good provider should be able to show a sample report structure, explain how scanner results are validated, define the rules of engagement, and make clear what the final deliverables will and won’t prove.
The next step is a scoped consultation: define the assets, access model, safety constraints, reporting needs, and retest expectations before buying. That’s what turns a penetration test from a generic security activity into actionable remediation work and defensible point-in-time evidence.