Home

Services

Offensive Security

Penetration Testing

Penetration Testing

Goal-oriented testing by experienced testers, reported against business impact.

Penetration testing puts your defences in front of a skilled attacker under controlled conditions. We test your networks, applications and cloud environments the way a real adversary would, then report findings against business impact rather than raw CVSS.

Every engagement includes manual exploitation. A scanner tells you what is theoretically vulnerable; a tester tells you what is actually reachable and what it would cost you.

ATT&CK ATT&CK MITRE ATT&CK® A public knowledge base of adversary behaviour. Version 19, released 28 April 2026, catalogues 15 tactics, 222 techniques and 475 sub-techniques for enterprise environments. Full glossary →

CVSS CVSS Common Vulnerability Scoring System A severity score describing how bad a vulnerability would be if exploited. Its own specification treats the base score as a ceiling, not a measure of risk in your environment. Full glossary →

EASM EASM External Attack Surface Management Outside-in discovery and monitoring of everything an organisation exposes to the internet, including assets no inventory has recorded. Full glossary →

Penetration testing scopes

External network

Everything reachable from the internet, including assets you may not know you publish.

Internal network

What an attacker achieves after the first foothold — lateral movement and privilege escalation.

Web applications

Tested against the OWASP Top 10:2025 — Broken Access Control (A01), Security Misconfiguration (A02), the new Software Supply Chain Failures (A03), Injection (A05) and Security Logging and Alerting Failures (A09) — plus the business logic no generic list covers.

Cloud environments

Identity, permission and configuration weaknesses across your cloud accounts.

How an engagement runs

01 Scoping and rules of engagement Targets, timing, escalation contacts and constraints agreed in writing before any testing begins.

02 Reconnaissance and discovery Mapping the real attack surface within scope, including assets outside your inventory.

03 Exploitation Manual, goal-oriented testing — chaining findings to demonstrate genuine impact.

04 Reporting Findings prioritised by business risk, with reproduction steps and remediation guidance.

05 Retest We verify your fixes actually close the finding rather than move it.

Scoped, executed, then proven fixed

A test that ends at the report is half a test. The retest is what turns a finding into a closed issue.

Frequently asked questions

How is penetration testing different from a vulnerability assessment?

A vulnerability assessment identifies and prioritises weaknesses across your infrastructure, broadly and largely through tooling.

A penetration test goes further: a tester manually exploits those weaknesses and chains them together to prove what an attacker could actually achieve.

How often do we need a penetration test?

At least once every 12 months, and again after any significant change.

That is not just good practice — it is the explicit requirement in PCI DSS v4.0.1, whose Requirements 11.4.2 and 11.4.3 mandate internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change. Service providers must test segmentation controls every six months; everyone else annually. The v4.x future-dated requirements became mandatory on 31 March 2025.

Even outside card-handling environments, that cadence is the accepted benchmark. A "significant change" is a major application release, a cloud migration, a new authentication flow, or a new externally reachable service.

What is the difference between a scan, an assessment and a penetration test?

Three different depths.

A vulnerability scan is automated and broad. Tooling compares your environment against known vulnerability data and lists what might be wrong.

A vulnerability assessment adds an analyst. Scan output is triaged, false positives removed, and findings prioritised into an order you can actually work through.

A penetration test adds an adversary. A tester manually exploits weaknesses and chains them together to demonstrate what an attacker could genuinely achieve. PCI DSS treats these as separate requirements for exactly this reason — scanning sits under Requirement 11.3, penetration testing under 11.4 with its own documented methodology.

Most organisations need all three: scanning for cadence, assessment for prioritisation, testing for proof.

What do you look for in a web application test?

We test against the current OWASP Top 10, released as the 2025 edition, plus business logic specific to your application — which no generic list covers.

The 2025 ranking reflects a real shift. Broken Access Control remains number one. Security Misconfiguration rose to second. Software Supply Chain Failures entered as a new A03, and Mishandling of Exceptional Conditions is the other new category. Injection, long the headline risk, has fallen to fifth. Notably, Security Logging and Alerting Failures sits at A09 — meaning the ability to detect an attack is itself assessed as a top-ten application risk.

Will testing disrupt our systems?

Engagements are scoped and scheduled to avoid disruption, with rules of engagement agreed in advance and escalation contacts on standby throughout.

More from Offensive Security

Vulnerability Scanning

Your first line of defence — automated tooling combined with expert analysis, on a cadence that meets Essential Eight.

Vulnerability Assessment

Transforming weaknesses into strengths — a defensible remediation order, not a 400-page scanner dump.

Cyber Attack Simulation

Test and strengthen your defences against realistic, chained adversary behaviour.

Ready to see your attack surface the way an attacker does?

Book a walkthrough with an Australian-based security engineer. No scripted demo, no obligation.

Both forms deliver to info@cyberti.com.au.