Failures, incidents and official sources
Penetration test authorisation: Criminal Code Part 10.7 and the letter you need before testing
Why pen testing needs written authorisation under Australia's computer offence laws, who can authorise it, third-party and cloud systems, and what the authorisation letter should contain.
A penetration test is lawful in Australia only when the tester is authorised by someone entitled to give that permission for every system tested. Part 10.7 of the Criminal Code (Commonwealth) makes unauthorised access to, modification of, or impairment of computer data an offence, and section 476.2 defines access as unauthorised if the person "is not entitled to cause" it. States and territories have their own computer offence laws as well. In practice that means a written authorisation naming the systems, dates, methods and contacts, signed by someone with authority over those systems, and separate permission or compliance with published rules for systems owned by others, such as your cloud host, SaaS providers or a landlord's network.
This guide belongs to the failures pillar. For scope and price, see pen-test cost and scope. It is general information, not legal advice.
The legal framework in brief
| Provision | What it covers |
|---|---|
| Criminal Code s 476.2 | Defines unauthorised access, modification or impairment: the person is not entitled to cause it |
| Criminal Code s 477.1 | Unauthorised access, modification or impairment with intent to commit a serious offence |
| Criminal Code s 477.2 and s 477.3 | Unauthorised modification of data to cause impairment; unauthorised impairment of electronic communication |
| Criminal Code s 478.1 | Unauthorised access to, or modification of, restricted data (data protected by an access control system), with a penalty of 2 years imprisonment |
| State and territory laws | Each jurisdiction has its own computer offences, which may also apply |
Section 476.2(2) adds that access is not unauthorised merely because the person has an ulterior purpose. The key question is entitlement, which is why the authorisation document matters so much.
None of this is aimed at legitimate testers, but a test that strays beyond what was authorised (another company's server on the same IP range, a cloud service you do not control, an employee's personal account) can expose the tester and you to legal risk.
Who can authorise a test
- Your own systems: a director or senior manager with authority over the business's IT, usually with the IT owner's agreement.
- Systems hosted for you: check the hosting contract. Your managed IT provider or data centre may need to consent or be notified.
- Public cloud: major cloud providers publish penetration testing policies listing what customers may test on their own resources without prior approval and what is prohibited (for example, denial-of-service testing). Follow the policy for each provider.
- SaaS applications: you generally cannot authorise testing of a SaaS provider's platform. Many providers prohibit it or run their own programs. Test your configuration (for example, sharing settings) instead, or ask the provider.
- Shared networks: in shared offices or co-working spaces, the network may belong to the landlord.
What the authorisation letter should contain
- Names of the business and the testing firm, and the individual testers.
- The exact scope: IP addresses, domains, URLs, applications, user roles, cloud accounts, physical sites.
- Explicit exclusions: systems and techniques not allowed.
- The testing window: dates and times, time zone.
- Methods permitted: for example, credentialed testing, password attacks against test accounts, social engineering (and of which staff).
- Handling of personal information encountered during testing: minimise, protect, delete.
- Stop conditions: what triggers a pause and who to call.
- Contacts: 24-hour contacts on both sides.
- Confirmation that third-party consents have been obtained, or attached.
- Signature of a person with authority, with their role and date.
Keep the letter with the engagement contract. Testers should carry a copy, especially for physical or on-site tests.
Social engineering and staff
Phishing simulations and phone pretexting involve staff. Consider:
- telling staff in general terms that testing happens, without dates;
- not targeting personal accounts or personal social media;
- handling results to improve training, not to punish individuals;
- respecting your workplace policies and any privacy obligations about the information collected.
Common mistakes
| Mistake | Consequence | Prevention |
|---|---|---|
| Scope copied from last year | Old IP addresses now belong to someone else | Re-confirm every IP and domain before the test |
| Verbal "go ahead" from the IT manager | No evidence of entitlement; disputed authority | Written letter signed by an authorised person |
| Testing a SaaS platform | Breach of the provider's terms, possible offence | Test your configuration only, or get the provider's consent |
| No stop process | A fragile system fails and testing continues | Stop conditions and live contacts |
| Results emailed unencrypted | Sensitive findings exposed | Secure delivery agreed in advance |
Frequently asked questions
Does my managed security provider need a separate authorisation to scan my network?
Routine vulnerability scanning by your provider should be covered in its contract scope. A penetration test that tries to exploit weaknesses should have its own authorisation.
What about bug bounty or "ethical hackers" who contact us?
Someone testing your systems without your permission is not authorised, however good their intentions. If you want outside researchers to report issues, publish a vulnerability disclosure policy that explains how to report and what is allowed.
Can I authorise a test of my supplier's portal that we use?
Not on your own. You would need the supplier's permission.
Do testers need a licence in Australia?
There is no general licence for penetration testers. Some states license security work such as physical security, so check if a test includes physical entry. Ask about testers' experience and insurance.
Sources
- Federal Register of Legislation — Criminal Code Act 1995, Schedule, Part 10.7 (ss 476.2, 477.1–477.3, 478.1)
- ASD's Australian Cyber Security Centre — guidance on vulnerability disclosure and system testing
- Office of the Australian Information Commissioner — handling personal information encountered in testing
