A penetration test is an authorised, simulated attack on a system, carried out by a security professional to determine which weaknesses can genuinely be exploited and what an attacker would reach as a result.
The short answer
A penetration test answers a question automated tools cannot: not which vulnerabilities exist, but which ones an attacker can chain together to reach something valuable. A tester works under an agreed scope and written authorisation, exploits what they find, and documents each finding with evidence and reproduction steps. The deliverable is a report a customer or auditor will accept.
On this page
How it differs from other testing
Four activities get confused during procurement. They differ on two axes: how much of the estate is covered, and how closely the exercise resembles a real attacker.
| Approach | What it produces | Best used when |
|---|---|---|
| Vulnerability scanning | Known issues across every asset, with false positives | Continuously, between tests |
| Penetration test | Exploited findings with evidence, ranked by impact | A customer or auditor wants assurance |
| Red team exercise | Proof that detection and response work | A security team already exists |
| Bug bounty | Findings from external researchers, paid per issue | Mature product with a triage process |
A note on sequence
Red team exercises and bug bounty programmes assume someone is available to respond to findings. For a team without a dedicated security hire, a scoped penetration test with a retest delivers considerably more value for the same budget.
Types of penetration test
The type follows what is being attacked. Most startups begin with the first two and add others as the product grows.
| Type | What is tested | Typical trigger |
|---|---|---|
| Web application | Auth, session handling, tenant isolation, injection | First enterprise customer or audit |
| API | Object level authorisation, rate limits, shadow endpoints | Any public or partner API |
| Mobile application | Local storage, cert pinning, secrets in the binary | A mobile client ships |
| External network | Internet-facing services, ports, remote access, TLS | Self-managed infrastructure |
| Internal network | Lateral movement, privilege escalation, segmentation | Regulated or enterprise buyers |
| Cloud configuration | IAM roles, storage permissions, security groups, logging | Multiple cloud accounts |
How a test is executed
Testers work to a published methodology rather than improvising: the OWASP Web Security Testing Guide for application work, NIST SP 800-115 and the Penetration Testing Execution Standard for the wider process. Ask which one a provider follows.
What the report should contain
The report is the product. Request a redacted sample before signing, and check it against these six.
Executive summary
Overall risk position, written for a reader without a technical background.
Scope and method
Assets in scope, methodology followed, and the exact dates of testing.
Evidence per finding
Severity, affected endpoint, and proof that the issue was exploited.
Reproduction steps
Detailed enough for an engineer to reproduce the finding independently.
Named remediation
Specific corrective actions rather than general advice to apply patches.
Retest results
Which findings were closed, and on what date they were verified.
Before you sign
Confirm three things: that the retest is included rather than billed separately, that testers hold recognised credentials such as OSCP or CREST, and that an attestation letter is provided for sharing with customers who should not receive the full report.
Where frameworks require it
| Framework | Status | Where it appears |
|---|---|---|
| PCI DSS v4.0 | Required | Requirement 11.3: internal and external penetration testing at least annually and after significant change. |
| ISO 27001:2022 | Expected | Annex A 8.8 (technical vulnerabilities) and A 8.29 (security testing in development and acceptance). |
| SOC 2 | Expected | Not named in the Trust Services Criteria. Auditors accept a test report and retest as evidence under CC4.1 and CC7.1. |
| Buyer questionnaires | Asked | The date of the most recent test, who performed it, and whether findings were remediated. |
How Osto runs penetration testing
Osto provides expert-led penetration testing inside the platform rather than as a separate consulting engagement. Findings are rated by severity with affected endpoints identified, and remediation and retest reports are produced in the same system.
Because that platform also runs the WAF, CSPM, code security and compliance modules, test evidence already sits where auditors draw from. That is why testing fits inside Osto’s 7-day SOC 2 readiness phase.
Free security assessment
Test what an attacker would reach first
Expert-led penetration testing with remediation and retest reports, alongside continuous scanning across your applications, APIs and cloud.
Get a free security assessment Book a platform walkthroughRetest included · Reports auditors accept · One platform, everything
Frequently asked questions
What is a penetration test?
A penetration test is an authorised simulated attack on a system, performed by a security professional to identify which weaknesses can be exploited and what an attacker would be able to reach. It produces a report of validated findings with evidence, reproduction steps and remediation guidance.
How is a penetration test different from a vulnerability scan?
A vulnerability scan is automated and reports known issues across every asset, including false positives. A penetration test is performed manually, confirms which issues are genuinely exploitable, and identifies flaws in business logic that scanners cannot detect.
How long does a penetration test take?
A single web application generally requires a few days to two weeks including reporting. Larger scopes covering applications, APIs and internal networks can run several weeks. Scheduling with a provider typically adds further lead time.
How often should a penetration test be performed?
At least annually, and after any significant change such as a new payment flow, a new authentication provider or a cloud migration. PCI DSS makes the annual test mandatory; other frameworks treat it as expected practice.
What is the difference between a penetration test and a red team exercise?
A penetration test examines a defined scope for exploitable weaknesses and documents them. A red team exercise pursues a single objective without warning the defending team, and measures whether detection and response function correctly. Red teaming is appropriate once a security function is already in place.