What is penetration testing?
Penetration testing is an authorised, controlled security assessment in which a tester actively attempts to identify and exploit weaknesses in a system, application, network or organisation, in order to prove what a real attacker could achieve. It goes beyond listing potential issues by safely demonstrating genuine impact within an agreed scope.
The word that separates a penetration test from most other security activity is exploit. A penetration test does not stop at listing potential issues. Where it is safe and authorised to do so, it demonstrates that an issue is real by using it, the same way an attacker would, under a defined scope and rules of engagement so nothing happens that was not agreed in advance.
That authorisation is what makes the activity legal and legitimate rather than an intrusion. Every reputable engagement, automated or human-led, runs under a signed scope document that defines exactly what is in play, what is off-limits, and who to call if something unexpected happens.
Where the definition comes from
The definition above is not vendor opinion. NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, describes penetration testing as security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system or network.
The Penetration Testing Execution Standard sets out the same activity as a defined sequence of phases, and the OWASP Web Security Testing Guide does the equivalent job for web applications with a concrete procedure per test case. The three documents differ on vocabulary but agree on the substance: agree scope first, gather information, find weaknesses, attempt to use them safely, then report in enough detail that a defender can reproduce and fix each issue.
Types of penetration testing
Different parts of an organisation's attack surface need different testing approaches. Most mature security programmes combine several of the following, often called layers or test types.
Whichever layer is in scope, the behaviour being simulated is catalogued in MITRE ATT&CK, a public knowledge base of adversary tactics and techniques. Technique identifiers such as T1190 give testers, defenders and detection engineers a shared vocabulary for what was actually attempted, rather than a vendor-specific label.
External network testing
Tests everything reachable from the public internet: exposed IPs, hostnames, open ports, and misconfigured internet-facing services. This is the classic perimeter test and usually the first layer any organisation runs. In ATT&CK terms it covers Active Scanning (T1595) and Exploit Public-Facing Application (T1190).
Internal network testing
Simulates an attacker (or a compromised device, or a malicious insider) who already has a foothold inside the network. It looks at lateral movement, credential reuse, weak internal segmentation and what a single compromised workstation could reach. The relevant ATT&CK techniques include Valid Accounts (T1078), Network Service Discovery (T1046) and Remote Services (T1021).
Web application testing
Targets the logic and code of a specific web application: injection flaws, broken access control, authentication bypass, session handling, and the rest of the categories in the OWASP Top 10. Individual test cases are usually drawn from the OWASP Web Security Testing Guide, which documents a repeatable procedure per category rather than only a list of names. See the OWASP Top 10 explained.
API testing
Tests REST and GraphQL APIs directly, independent of any front-end client: broken object-level authorisation, excessive data exposure, rate-limiting gaps and the other categories in the OWASP API Security Top 10. APIs need a separate pass because a front-end control, such as a hidden button or a disabled form field, is not a control at all once the underlying call is made directly. See API security best practices.
Cloud testing
Reviews the configuration of cloud accounts (AWS, Azure, GCP) against provider security baselines and the CIS Benchmarks: identity and access management, storage exposure, network configuration and logging. Cloud work leans further towards configuration review than exploitation, because the provider owns the underlying infrastructure and provider terms restrict what may be attacked directly.
Identity and Active Directory testing
Focuses on how identity is managed: password policy strength, stale or over-privileged accounts, Kerberos ticket weaknesses and how a single compromised credential can chain into domain-wide access. Kerberoasting (T1558.003) and Pass the Hash (T1550.002) are the classic examples. See common Active Directory security issues.
The phases of a penetration test
A properly run penetration test is not a single scan. It follows a structured methodology so that scope is agreed before anything happens and findings are prioritised and reported afterwards. The Penetration Testing Execution Standard and NIST SP 800-115 describe broadly the same flow, and the phases below follow that shared structure.
| Phase | What happens |
|---|---|
| 1. Pre-engagement | Scope, rules of engagement, success criteria, legal authorisation and emergency contacts are agreed before any testing starts. |
| 2. Reconnaissance and OSINT | Passive and active recon: subdomain enumeration, exposed services, email addresses and attack-surface mapping. |
| 3. Scanning and enumeration | Port discovery, service detection, CVE scanning and configuration review across web, cloud and, where in scope, Kubernetes. |
| 4. Vulnerability analysis | CVE correlation, false-positive elimination, and prioritisation by CVSS v3.1 severity, exploit availability and business impact. |
| 5. Exploitation and validation | Safe exploitation confirms which findings are actually exploitable and documents the real-world impact, including any privilege escalation or lateral movement. |
| 6. Reporting and remediation | An executive summary, technical detail, evidence and prioritised remediation guidance, with findings mapped to relevant compliance reporting frameworks. |
| 7. Re-verification | A follow-up check confirms fixes actually closed the gap, rather than assuming a patch worked. |
What belongs in the rules of engagement
Phase one is the phase most often rushed, and it is the one that keeps everybody out of trouble. Anything not written down becomes ambiguous at exactly the wrong moment: if a tester reaches a live production database inside an in-scope subnet at 02:00, the document should already say whether to stop, alert or continue.
A workable rules of engagement document is short and specific. The scope block reads much like a firewall rule set:
- In scope: 203.0.113.0/24, app.example.com, api.example.com, one named production cloud account.
- Out of scope: mail.example.com, any third-party SaaS tenant, and any host not listed above.
- Excluded techniques: denial of service, physical intrusion, social engineering of staff.
- Testing window: 20:00 to 06:00 AEST, Monday to Thursday.
- Stop conditions and contacts: a named on-call engineer reachable during the window, plus an agreed signal to pause testing immediately.
Penetration test vs vulnerability scan
These two terms get used interchangeably in casual conversation, but they describe different depths of work, and confusing them is one of the most common buying mistakes in security.
A vulnerability scan is largely automated detection. It checks systems against a database of known signatures and misconfigurations and reports what it finds, without attempting to use any of it. It is fast, cheap to run repeatedly, and useful for broad coverage, but it produces a list of *possible* issues, some of which will be false positives.
A penetration test goes further: it takes findings from a scan (or from manual analysis) and, within an authorised scope, attempts to exploit them to prove real-world impact. That is the difference between 'this port is open and the service looks outdated' and 'this outdated service let us read a config file containing valid credentials, which we then used to access an internal system.' The second statement is evidence. The first is a hypothesis.
Both feed the same prioritisation inputs: severity scored with CVSS v3.1, whether a working exploit is publicly available, and whether the CVE appears in the CISA Known Exploited Vulnerabilities catalogue, which lists flaws with confirmed exploitation in the wild. A medium-severity issue that is being exploited today outranks a high-severity issue that nobody has ever weaponised.
And where red teaming fits
A red team exercise is a third thing again. Where a penetration test aims for coverage of a defined scope, a red team engagement aims at an objective, for example reaching a specific dataset, and deliberately tests whether the defenders notice. Adversary emulation of that kind is normally planned against ATT&CK techniques so the exercise can be replayed and measured against detection coverage.
Red teaming assumes you already run penetration tests. It measures detection and response maturity, and it is a poor substitute for coverage testing if the basics have never been assessed.
Who needs penetration testing
Any organisation with an internet-facing presence, a network of any size, or an obligation to a customer, regulator or cyber insurer benefits from penetration testing. In practice, a few situations make it close to mandatory rather than optional:
- Regulatory or contractual obligation. PCI DSS v4.0 requires organisations that handle cardholder data to run internal and external penetration testing at least every 12 months and after any significant change, and many customer security questionnaires ask for a recent report.
- Prudential and sector regulation. Australian APRA-regulated entities, including banks, insurers and superannuation trustees, must systematically test the effectiveness of their information security controls under CPS 234, with the frequency driven by how fast the threat environment and the estate change.
- Before a major change. New product launches, cloud migrations, mergers and significant architecture changes all introduce fresh attack surface worth validating before go-live.
- Cyber insurance underwriting. Insurers increasingly ask for evidence of regular testing as part of the underwriting process.
- Ongoing risk management. Any organisation storing sensitive data, whether customer records, health information or financial data, has a direct incentive to find its own weaknesses before someone else does.
How often should you test
The traditional answer is annually, often driven by a compliance calendar rather than actual risk. That cadence made more sense when infrastructure changed slowly. Modern environments, especially cloud-hosted ones, change constantly: new services, new code deployments, new cloud resources, and new CVEs disclosed against existing software every week.
Frameworks set a floor, not a target. PCI DSS v4.0 expects testing at least every 12 months plus after significant change; most other regimes ask for testing proportionate to risk rather than on a fixed date. Australian guidance points the same way: the Essential Eight published by the Australian Cyber Security Centre expects internet-facing vulnerabilities to be remediated within days, not months, once a working exploit exists, which is impossible to evidence with a single annual snapshot.
A useful rule of thumb: test at a minimum cadence required by any framework you report against, and add testing around every significant change in between. Organisations with fast release cycles or a large cloud footprint increasingly move to a continuous model that layers scheduled scans and perimeter re-checks between formal engagements, rather than relying on a single annual snapshot. For the detail on that model, read what continuous penetration testing is.
Choosing a penetration testing provider
Not every provider or product operates at the same depth. A few questions help separate genuine testing from a rebranded scan:
- Does it exploit, or only detect? Ask whether findings are validated with safe exploitation, or only flagged from a signature match. Detection without validation carries a meaningful false-positive rate.
- What methodology does it follow? Look for alignment with recognised standards such as PTES, the OWASP Web Security Testing Guide, or NIST SP 800-115, rather than an undocumented process. Read PTES explained and NIST SP 800-115 explained.
- How is scope controlled? A signed rules of engagement document with clear in-scope and out-of-scope boundaries should exist before any testing, automated or manual, begins.
- What evidence do you get? A credible report includes reproduction steps and evidence for each finding, not just a severity label, and maps findings to the compliance frameworks that matter to you.
- Are findings mapped to a public technique catalogue? Mapping each proven finding to an ATT&CK technique lets your detection team check whether that behaviour would have been caught, which turns a test report into a detection backlog.
- Does it cover the layers you actually run? Web, API, cloud, internal network and identity all need different testing techniques. Confirm the provider actually covers your stack rather than assuming one scan type implies the rest.
How PentestOps helps
PentestOps delivers automated, AI-powered discovery, exploitation and remediation across external perimeter, internal networks, web applications, APIs, cloud infrastructure and identity, all under a signed rules of engagement with scope enforcement that automatically stops activity outside authorised assets. Coverage runs to 24+ external recon modules and 18+ internal modules, with scan profiles of Stealth, Balanced or Aggressive controlling intensity.
Every layer follows the same 7-phase methodology described above, and confirmed findings are validated with safe, auditable exploitation rather than left as unverified detections: proof, not guesswork. Findings map to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes, and reports export as PDF, CSV or JSON/API.
Layer pages cover each test type in detail: external network, internal network, web application, API, cloud and Active Directory.
Pricing is asset-wise with scans unlimited within fair use, so you pay for what is in scope, not how often you test. Run a free demo scan to see it in action, or start a trial: all paid plans start with a 7-day free trial, and a card is required to start your trial and is only charged after the trial ends, unless you cancel first.