Know what an attacker could actually achieve in your environment. Not what a scanner flags as theoretically possible.
Penetration testing is an engineer-delivered attempt to exploit vulnerabilities in a defined target, using techniques that mirror real-world attackers. The output is evidence of what could actually be reached, not a list of theoretical weaknesses from an automated scan.
Start with the quick answersWhat a penetration test is, and what it is not; external, internal, web application, cloud and phishing scope types; how testing scope should be defined for the question being asked; reporting designed for remediation, insurance and audit use; Essential Eight alignment and what pen testing does and does not certify; and where pen testing fits inside broader cyber security work. This page is most relevant for Australian organisations approaching a cyber insurance renewal that asks for independent testing evidence, responding to a major incident elsewhere in the sector, or preparing to validate an Essential Eight maturity position. Penetration testing is most useful when the organisation knows what it needs to validate — for many buyers, the first question is not simply whether to run a test, but what should be tested, what evidence is needed, and whether testing is the right first step.
What it is, how it differs from a scan, and when organisations commission one.
- What is a penetration test? — A scoped, authorised attempt by a security engineer to exploit vulnerabilities in a defined target, using techniques that mirror real-world attackers. The output is a report of what an attacker could actually achieve in the specific environment being tested, including proof-of-concept evidence and a prioritised remediation plan.
- How is it different from a vulnerability scan? — A vulnerability scan uses automated tooling against a signature database. It is fast, broad and identifies known weaknesses. A penetration test goes further: an engineer attempts to exploit identified weaknesses to determine whether they represent a real, exploitable path in the specific environment. Many scan findings are unexploitable in practice. Many exploitable paths are invisible to scanners entirely.
- When does an organisation typically commission one? — Before cyber insurance renewal where the questionnaire asks for independent testing evidence. After a sector incident where leadership wants to know whether the same outcome is possible internally. When validating Essential Eight Maturity Level 2 or above. Before or after major infrastructure changes. When responding to a client or procurement process that requires evidence of independent testing.
A scanner tells you what might be exploitable. A penetration test tells you what actually is.
The distinction matters commercially. Insurance questionnaires, Essential Eight maturity claims and major customer due diligence are increasingly asking for evidence of independent testing, not for a list of vulnerability scanner outputs. The reason is straightforward: scanner output is noisy and does not validate exploitability in a specific environment.
A vulnerability flagged as critical by severity score may be behind a compensating control, on an isolated network segment, or on a system that does not expose the vulnerable function. The scan rates it by theoretical severity; the pen test rates it by what actually happens when exploitation is attempted.
Chained vulnerabilities, business logic flaws in custom applications, misconfigurations that only become exploitable when combined, and privilege escalation paths through legitimate functionality. Automated scanners do not model these; an engineer does.
Insurance underwriters, Essential Eight assessors and customer security reviewers ask for specific evidence: external attack surface exposure, privileged access misuse paths, and validation that controls work against realistic attack techniques. Pen test reporting is structured to answer those questions; scanner output requires substantial translation to do the same.
An engineer working from an attacker perspective finds what attackers would find, with the same constraints an attacker operates under — limited information, time pressure, evasion requirements. That perspective is the difference between a compliance artefact and an actionable security finding.
Asserting Essential Eight maturity or insurance-ready controls without evidence of testing is a position that does not usually survive scrutiny. Reviewers are increasingly asking for the report, not the assertion.
What a penetration test covers, scoped to what needs to be known.
Most engagements combine two or three of the scope types below. The scope types are defined in the scoping conversation, based on the specific objectives of the test. A renewal-driven engagement typically looks different from an incident-response engagement, which looks different again from an Essential Eight validation engagement.
Public-facing infrastructure assessed from the outside attacker perspective. Covers perimeter devices, remote access services, public services, and any exposed management interfaces. Produces evidence of external attack surface exposure that insurers and auditors commonly ask about.
Tested from a position of assumed compromise, typically a phished user account. Models the attacker who is already inside the network, reflecting the current threat model where most breaches begin with credential compromise rather than perimeter breach.
Custom-built and configured applications tested against OWASP top-ten weaknesses and application-specific business logic flaws. Covers authentication, session management, access control, input validation and data exposure in the specific application context.
AWS, Azure or Microsoft 365 tenant configuration reviewed for exploitable misconfiguration: excessive privileges, public resources that should not be public, weak identity configuration and gaps in the configured security controls. Tests what an attacker with tenant-level access could actually do.
Controlled phishing campaigns that measure user response, technical control response and incident detection capability. Not a compliance tick-box; a realistic simulation that produces data on how the organisation actually responds to the most common initial access vector.
A more targeted variant of internal testing. The engineer starts from a specific assumed position — compromised workstation, compromised vendor account, compromised service principal — and tests what escalation and lateral movement is possible from that starting point.
A useful test starts with the right scope and ends with findings the organisation can act on.
Penetration testing is a structured engagement, not an open-ended exploration. The phases below are standard across the industry; the value comes from the rigour with which each is run, not from a proprietary variant of the methodology.
Target systems identified, scope types agreed, rules of engagement documented (what is in scope, what is out of scope, what stop conditions apply), testing window confirmed, authorisations signed off. This is the phase where specific objectives are translated into testable actions, and it is the phase that determines whether the engagement output will answer the question actually being asked.
Testing is performed within the agreed scope and rules of engagement, following a structured methodology — reconnaissance, enumeration, vulnerability identification, exploitation attempts, post-exploitation where in scope, lateral movement testing where in scope. Safety thresholds are applied throughout. Communication with the organisation is maintained during execution, especially where unexpected behaviour is detected.
Findings are documented with proof-of-concept evidence, severity rating, business impact context and prioritised remediation guidance. Deliverables include an executive summary written for non-technical readers, a technical report for engineers implementing fixes, a remediation plan sequenced by exploitability and impact, and Essential Eight mapping for each relevant finding. The reporting format is built for use, not for filing.
After remediation work is completed, a retest pass verifies that the fixes work as intended and no regressions have been introduced. The retest report confirms closure of specific findings, documents any residual risk, and produces the dated artefact that insurance and audit processes actually require.
The biggest failure mode of penetration testing is a 90-page PDF that no one acts on.
The report is the product. If it is written for the auditor's filing cabinet rather than for the engineer who has to fix the finding, the engagement produced compliance theatre instead of security value.
The reporting approach reflects this directly. Findings are written with the remediation engineer as the primary audience. Each finding includes what was found, proof-of-concept evidence that the finding is real, the business impact if exploited, and specific guidance on how to remediate. Severity ratings are used to sequence work, not to manufacture urgency.
A live reporting view is available during the engagement: findings are visible as they are identified and validated, so the organisation can begin remediation before the final report is delivered. Critical findings are communicated directly rather than held back for the report draft. The goal is to shorten the time between discovery and closure.
Standard reporting deliverables:
- Executive summary — Non-technical summary of scope, key findings, risk themes and recommended action. Written for leadership audiences; does not assume technical fluency.
- Technical findings report — Each finding with description, proof-of-concept evidence, severity rating, business impact and specific remediation guidance. Written for the engineers implementing fixes.
- Prioritised remediation plan — Findings sequenced by exploitability, business impact and dependency. Designed to be handed to an internal team, an existing provider, or Inlight IT.
- Essential Eight mapping — Each relevant finding mapped to the corresponding Essential Eight mitigation strategy, to inform Essential Eight maturity assessments and reviews.
- Retest confirmation report — Dated record of retest outcomes after remediation. Confirms closure of each finding or documents residual risk. The artefact most commonly requested by insurance questionnaires.
Penetration testing informs Essential Eight claims. It does not certify them.
The distinction matters. Essential Eight maturity is a self-assessment framework with no central certifying body. Penetration testing produces evidence that supports or challenges specific maturity claims; it does not issue a certificate or confer maturity status. Where penetration testing is the natural validation method, findings are mapped to the relevant Essential Eight mitigation strategies:
- Application control — Testing identifies whether application control bypasses are achievable from an attacker position, and whether the controls hold against common evasion techniques.
- Patch applications and operating systems — Testing validates patching currency under attacker conditions, including whether missed patches produce exploitable paths in the specific environment.
- Configure Microsoft Office macro settings — Testing simulates macro-based delivery to validate whether macro restrictions hold in practice against realistic phishing pretexts.
- User application hardening — Testing validates the effectiveness of browser and application hardening against realistic delivery scenarios.
- Restrict administrative privileges — Testing identifies privilege escalation paths and tests whether privileged access is scoped, monitored, and revoked as the framework expects.
- Multi-factor authentication — Testing identifies MFA bypass paths, including session token theft, MFA fatigue, and identity provider misconfiguration that defeats the intent of the control.
- Regular backups — Internal testing explores whether backup systems are reachable and modifiable from a compromised position with escalated privileges, which is the question insurance questionnaires now ask about.
The test report becomes input to the Essential Eight maturity assessment. It does not replace the assessment. The distinction is worth stating explicitly because marketing language in the broader market often conflates the two.
Often part of a broader cyber security review, not run in isolation.
Penetration testing is most useful when the scope is clear and the organisation knows what it needs to validate. Where the broader cyber question is not yet narrow enough — what exposure actually exists, what should be tested first, whether testing is the right first step — the scoping conversation usually runs through a Cyber Security Review.
The review surfaces where the real exposure sits, helps narrow the test scope to the question that actually matters commercially, and connects the testing work to adjacent areas — Microsoft 365 security, identity, business email compromise, payment workflows — that often need attention together.
Where the test scope is already clear (an insurance questionnaire that explicitly asks for external testing evidence, a procurement process with a specific scope requirement, a previous test that needs a follow-on validation), the engagement can be scoped directly.
Where the broader cyber question is what is actually driving the request, the scoping conversation usually surfaces that early. A well-scoped engagement produces evidence that directly answers the commercial or operational question. A scope-by-default engagement produces a generic report that does not.
If you can name the specific question the test needs to answer, the scope is ready. If the honest question is still “what is actually exposed”, the review comes first.
See how a Cyber Security Review works →The Inlight IT view on penetration testing.
The question a penetration test answers is not “do we have vulnerabilities” but “what could an attacker actually achieve from a realistic position, within a realistic time, under realistic constraints.” The two are different questions, and the second is what commercial reviewers have started asking for.
A common pattern: an organisation has run vulnerability scans for years, remediated the criticals, and assumes the security posture is in good order. A penetration test reveals that the scanner-critical work was largely on vulnerabilities that were not exploitable in practice, while the actually exploitable paths — chained misconfigurations, business logic flaws, privilege escalation through legitimate functionality — were invisible to the scanner and therefore untouched. The scan work was not wasted, but it was not sufficient on its own.
Where penetration testing produces the most commercial value is in the scoping conversation. An engagement scoped to answer the specific question behind the request (insurance renewal readiness, post-incident assurance, Essential Eight validation, major change verification) produces a report that directly answers that question. An engagement scoped generically produces a generic report — cheaper to deliver and less useful to receive. The scoping discipline is where engineering-led testing earns its place.
Evidence of what an attacker can actually achieve is the benefit. The willingness to act on findings that may be inconvenient, and the engagement discipline to test what matters rather than what is easy, is the trade-off.
A scanner tells you what might be exploitable. A penetration test tells you what actually is. Reviewers are increasingly asking for the report, not the assertion.
Questions Australian organisations ask about penetration testing — scope, evidence, insurance use and how often.
What is penetration testing?
What is the difference between a penetration test and a vulnerability scan?
What scope types are commonly included in a penetration test?
How often should an organisation perform penetration testing?
Will a penetration test disrupt our production systems?
What does a penetration test report include?
Does penetration testing produce evidence for cyber insurance?
How does penetration testing inform Essential Eight maturity claims?
What is red teaming and how does it differ from a penetration test?
How is a penetration testing engagement scoped?
Engagements that show how penetration testing fits into broader cyber work.
Testing scoped to the question that needed answering, not to a generic external sweep.
Test what an attacker could actually achieve — scoped to the question that matters.
Start with the exposure, then test the part that counts.
Discuss your cyber security position