Before an adversary finds the way in, we do: under written authorisation, against an agreed scope, with every finding backed by evidence an engineer can reproduce.
Penetration testing is an authorised, time-boxed security assessment that attempts to validate whether vulnerabilities and control gaps can be combined into a reachable attack path. It tests an agreed target under signed rules of engagement and records reproducible evidence at a defined stopping point.
A penetration test is not a vulnerability scan with a nicer cover. It is a time-boxed attempt to reach what matters, using the same classes of technique an attacker would, inside rules you have signed.
No test starts from a website form. Documentary authority, a defined window and signed rules of engagement come first. Destructive testing, social engineering and denial-of-service activity are off the table unless separately and explicitly agreed.
What penetration testing can answer
Reachability
Can an authorised tester move from an exposed entry point to a valued system, action or dataset?
Control failure
Which technical and identity controls fail along the path, and which controls successfully contain it?
Contextual impact
What could the validated path mean for confidentiality, integrity or availability inside the agreed boundary?
Remediation proof
Did the implemented fix close the original path without leaving an equivalent route reachable?
Penetration test, vulnerability scan or security audit?
Penetration test
Actively validates whether an attack path is reachable in an authorised target and captures reproducible evidence.
Vulnerability scan
Produces broad automated signals about known patterns, versions and configurations that still require validation and triage.
Security audit
Examines evidence that controls meet agreed requirements; it does not normally attempt to exploit a path.
These activities answer different questions. The right starting point depends on whether you need breadth, exploitability evidence or control assurance.
Current landscape
A useful penetration test does not maximise activity. It validates the shortest material path, stops at agreed proof, and makes the fix testable.
ASD’s ACSC recorded more than 200 denial of service (DoS) or distributed denial of service (DDoS) incidents in FY2024–25, up more than 280%, and DDoS was almost twice as common against critical infrastructure as against the incident set as a whole. That is why we will not run DoS as part of a standard test unless it is separately and explicitly authorised. A penetration test is a time-boxed sample of the attack surface, not a flood.
The Optus 2022 incident remains the public Australian lesson on access control and internet-exposed application programming interfaces (APIs). The OAIC later commenced Federal Court proceedings alleging Optus did not take reasonable steps to protect the personal information of millions of customers. (ISC)² distinguishes black-box testing (no internal details) from tests that use design knowledge; both still require authorization. Covert security testing, in the (ISC)² sense, is only ever done with management consent.
Medibank’s 2022 intrusion used stolen contractor credentials against a virtual private network (VPN) that did not enforce multi-factor authentication (MFA): an Essential Eight control. A penetration test scoped at assumed-breach or remote access would have been asking whether that path was reachable before a malicious cyber actor did. We do not claim we tested those organisations. We use the public facts to explain why written rules of engagement and MFA on remote and privileged access are not optional.
When this fits
Release or go-live
You need independent validation of a defined target before it handles real users or sensitive data.
Reachability question
A specific attack path or control weakness may be material, but its practical exploitability is unknown.
External requirement
A client, insurer, regulator or procurement panel requires a current, dated penetration test.
Remediation retest
A previous finding was fixed and you need evidence that the original path is no longer reachable.
Decisions and outcomes
Testing is scoped to answer one question precisely: can an attacker reach what matters, and exactly how. Every finding includes the path taken, the evidence captured, and what it would take to close it.
Scope
Typically included
- Written rules of engagement, agreed and signed before any testing begins
- Manual, evidence-based testing against the agreed scope, not an automated scan relabelled
- Findings with reproduction steps, technical severity and business impact
- A retest against remediated findings, where scoped
Not included unless agreed
- Any testing without documented written authority for the exact target and window
- Destructive testing, social engineering or denial-of-service activity, unless separately and explicitly agreed in writing
- A guarantee that no further vulnerabilities exist beyond the tested scope and window
Deliverables
- Signed rules of engagement
- Executive summary for leadership
- Technical findings report with reproduction evidence
- Retest letter confirming remediation, where scoped
Process
Authorise
Written authority and rules of engagement, before any testing.
Scope
Agree exact targets, test types and time window.
Test
Execute against the agreed scope only.
Report and remediate
Findings, remediation guidance, and retest where scoped.
Methods and standards
Testing follows a structured, scope-appropriate methodology: confirm rules of engagement, map the authorised attack surface, validate reachable paths, stop at the agreed proof boundary, document evidence and retest remediation where included. Exact supported test types, for example web application, external infrastructure or assumed-breach, are confirmed during scoping. No test proceeds without signed written authority.
Security and evidence
No public evidence upload
This page never accepts malware, source code or evidence. Secure transfer is agreed only after authorisation and scoping, outside this website.
Limitations
What this engagement cannot promise
A penetration test is a time-boxed, scope-bound sample of what a skilled tester could validate in that window. It cannot guarantee that no other vulnerability exists, predict every attacker, assess targets outside the signed boundary, or prove that later changes will preserve the tested security state.
Common questions
What is included in rules of engagement?
The rules identify the authorised targets, test window, permitted and excluded activities, technical and emergency contacts, evidence handling, stop conditions and the agreed proof boundary. Testing begins only after those rules and authority are documented.
What can be included in a penetration test scope?
A proposed scope may involve an application, API, external infrastructure or an assumed-breach scenario, but exact targets and supported test types are confirmed before engagement. Scope is defined by the decision you need, your authority over the target and operational safety.
How is a penetration test different from a vulnerability scan or an audit?
A scan lists known issues. An audit checks controls against a framework. A penetration test tries to reach a valued asset and shows you the path. Many organisations need more than one of these; they are not substitutes. See security audits if your buyer is asking for control evidence.
Will you test production without warning?
No. Targets, windows and contacts are in the signed rules of engagement. Surprise testing is not something we offer from a public form.
Do you guarantee we will pass our next audit?
No. A test tells you what was reachable in that window. Closing findings, and whether an auditor accepts the evidence, remains your organisation’s work, we retest when scoped.
Case Studies
Current published case studies. Public-source illustrations are labelled clearly and are not presented as client engagements. View all case studies.
Six gift cards and a forged executive
A courier employee bought six $500 prepaid cards after mail that looked like it came from an executive. There was no malware. The missing control sat in the payment process.
More than $150,000 to a supplier who never changed banks
A construction firm paid an invoice twice after a supplier mailbox was taken over. No callback. No funds recovered.
The backup that encrypted itself
Ransomware at an auto parts store encrypted the live files and the backup disk still plugged into the same machine. Years of data went with the old system.
Related
Ready to talk about your situation?
Tell us the high-level scope. No malware, source code or evidence – just enough for us to route you safely.