A penetration test is a security assessment where a professional attacker tries to break into your systems, with your permission, and then tells you exactly how they did it. That's the whole idea. Everything else, the standards, the tooling, the reports, exists to make that one exercise rigorous and useful.

The reason it works is simple: the only reliable way to know how your application or network stands up to an attacker is to put it in front of one. Reviews and checklists tell you what should be true. A pentest tells you what is true.

Diagram showing the five phases of a penetration test: scope, recon, exploit, report and retest
// the five phases every engagement moves through

What a penetration test actually is

During a pentest, a security specialist spends days or weeks actively attacking an agreed target: a web application, an API, a mobile app, a network, a cloud environment. They probe the same weaknesses a criminal would, but under a signed agreement that defines what may be tested, when, and how far an attack may be taken.

The output is not a compromised system; it's knowledge. Every successful (and instructive unsuccessful) attack is documented: what was tried, what worked, what data or access was reachable, and precisely how to close the gap.

You'll also hear the term VAPT, vulnerability assessment and penetration testing. It simply means pairing broad automated discovery with deep manual attack, which is how any decent pentest is run anyway. If you want the distinction unpacked, we've written about the difference between scanning and pentesting separately.

What happens during a test

Nearly every reputable firm follows the same broad phases, whatever standard they map to (ours are OWASP, PTES and NIST SP 800-115, documented in our methodology):

  1. Scoping. You agree what's in and out of bounds: targets, test accounts, timing windows, emergency contacts. You should receive a fixed quote here, before any testing begins.
  2. Reconnaissance. The tester maps your attack surface: pages, endpoints, parameters, services, roles, and whatever the internet already knows about you.
  3. Exploitation. The real work. The tester attempts to break authentication, escalate privileges, access other users' data, inject code, and chain small weaknesses into big ones. Anything critical should be reported to you the same day it's found.
  4. Reporting. Every confirmed issue is written up with a severity rating, evidence, step-by-step reproduction instructions and a specific fix, plus an executive summary in plain English.
  5. Retesting. After your team fixes the findings, the tester verifies the fixes and reissues the report. At VAPT.COM.AU this is included in every engagement; some firms charge extra, which is worth checking before you sign.

What you get at the end

The report is the product, so it's worth knowing what a good one contains:

  • An executive summary that a non-technical director can read in five minutes and understand the risk position.
  • A findings list rated by severity (usually CVSS scores plus a contextual rating for your environment).
  • Per-finding detail: what the issue is, where it lives, evidence it's real, exact steps to reproduce it, and how to fix it.
  • An attestation letter or summary you can share with customers and auditors without exposing the technical detail.

If a sample report is not offered during the sales process, ask for one. It's the fastest way to judge a provider.

How to spot a rebadged scan

The industry has a quiet problem: some "penetration tests" are an automated scanner run with a new cover page. Scans are useful, but they are not pentests, and they are priced very differently. Warning signs:

  • The quote arrives instantly, with no scoping questions about roles, workflows or environments.
  • The report findings read like tool output: version banners, missing headers, TLS grades, and nothing about your application's logic or access control.
  • No findings have reproduction steps, or every finding is rated by the tool rather than a human.
  • The test finished suspiciously fast for the size of the target.
  • Nobody can get on a call and walk you through what they found.

A genuine test of a real application almost always surfaces at least a few issues no scanner could find: an ID you can increment to see someone else's invoice, a discount that can be applied twice, an admin function that trusts the client. If your report has none of that flavour, ask why.

When you actually need one

Common, sensible triggers:

  • A customer or partner requires evidence of testing before signing (increasingly standard in enterprise procurement).
  • You're pursuing ISO 27001 or SOC 2, or you handle card data under PCI DSS.
  • You're about to launch something significant: a new product, a major feature, a public API.
  • You've never been tested and you're now holding data that would hurt to lose.

Cadence-wise, annual testing plus testing after major changes is the widely accepted baseline. And if budget is the sticking point, scope can flex a lot; see our guide to what a pentest costs in Australia.