Authorised Security Testing: Scope, Rules of Engagement and Safe Evidence

A penetration test is not made lawful or safe by good intentions. The people who own or validly control the systems must provide written authorisation for the exact activity, assets, time and conditions. A domain appearing to belong to a client does not prove the client can authorise testing of every hosting provider, SaaS tenant, payment service, network or user behind it.

The first deliverable in a security test is therefore a defensible scope and rules of engagement—not a scanner report.

This article provides general technical information. It is not legal advice or permission to test any system.

Distinguish the type of work

Terms are often used loosely, so state what will actually occur.

• Configuration review: compares selected settings and evidence against an agreed baseline or product guidance.
• Vulnerability scan: uses automated checks to identify potential weaknesses; results require validation and may include false positives and false negatives.
• Security assessment: evaluates selected controls, architecture, processes and evidence against defined objectives.
• Penetration test: attempts controlled exploitation within written rules to demonstrate whether particular attack paths are feasible and what impact could follow.
• Red-team exercise: tests broader detection and response against agreed objectives, usually with more realistic adversary behaviour and specialised safety governance.

A scan is not automatically a penetration test. A penetration test is not proof that no vulnerability remains. An exercise covers only its agreed time, assets, methods and visibility.

ASD's security-assurance guidance similarly distinguishes vulnerability assessments, penetration tests and other assurance activities, and emphasises suitable scope and assessor capability (ASD — Guidelines for security assurance).

Obtain written authorisation from the right parties

Before active testing, identify:

• the legal client entity and authorised representative;
• asset owners and operators;
• hosting, cloud, SaaS, ISP and managed-service providers;
• shared infrastructure and other tenants;
• third-party code, APIs, networks and data;
• internal system owners and change authorities; and
• any employee, customer or member population that could be affected.

Provider terms may prohibit or condition security testing even when a client controls a tenant. Obtain required provider approval and keep the evidence with the engagement record. If ownership or authority cannot be resolved, exclude the asset until it can.

In Australia, the Criminal Code defines when access, modification or impairment is unauthorised and contains computer offences with specific elements and circumstances. A contract and rules of engagement help document permission, but legal effect depends on the facts and law. Seek qualified advice for uncertainty (Federal Register of Legislation — Criminal Code Act 1995, current compilation).

Write exact scope—not “all company systems”

Identify assets using stable, testable descriptions:

• domain and subdomain names;
• IP addresses and ranges;
• cloud account, subscription, project or tenant identifiers;
• application environments and API versions;
• wireless locations and network names;
• source repositories, container registries or mobile builds;
• test accounts, roles and authentication states; and
• explicit exclusions.

Record how dynamic cloud addresses, content-delivery networks, redirects and newly discovered assets will be handled. Discovery of a related hostname does not expand permission. Stop and request a written scope change.

Production and non-production environments require separate treatment. A staging system can contain production data or connect to live services; a production system can be too critical for particular techniques. Confirm the actual dependencies.

Rules of engagement checklist

NIST defines rules of engagement as detailed guidelines and constraints established before a security test, giving the team authority to conduct defined activities without additional permission (NIST — Rules of Engagement definition). A practical document should cover:

Purpose and success criteria

• business objective and threat scenarios;
• type and depth of test;
• deliverables and retest conditions; and
• what would constitute sufficient evidence without increasing harm.

Allowed activity

• approved assets, paths, techniques and tools;
• authenticated and unauthenticated roles;
• source IP addresses and tester identities;
• test windows, time zone, rate and concurrency limits; and
• approved test data and accounts.

Prohibited or separately approved activity

Unless the engagement specifically authorises and controls them, exclude:

• denial-of-service, stress or resource-exhaustion testing;
• destructive payloads, data modification or deletion;
• malware deployment, persistence or actions that survive the test;
• credential stuffing or use of credentials from unrelated breaches;
• phishing, pretexting, physical entry or other social engineering;
• access to real personal, health, financial or secret data beyond minimal proof;
• testing suppliers, staff devices or neighbouring tenants; and
• public disclosure or contact with customers, media or law enforcement.

These activities are not prohibited because they are never useful. They require separate authority, specialist controls and a risk decision appropriate to their potential impact.

Safety and communication

• primary and backup contacts on both sides;
• authenticated communication channels;
• health checks and change freezes;
• critical-system owners and provider escalation paths;
• stop conditions and who can invoke them;
• incident-versus-test differentiation; and
• emergency restoration or credential-revocation procedures.

Examples of stop conditions include unexpected access to highly sensitive data, service instability, possible impact to another tenant, evidence of an unrelated active compromise, loss of reliable communication or uncertainty about scope.

Evidence and data handling

• minimum evidence needed to substantiate a finding;
• approved capture methods and prohibited data;
• encrypted storage and transfer;
• role-based access and access logging;
• retention and verified deletion dates;
• treatment of credentials, tokens, keys and screenshots; and
• procedure for reporting accidental access or a high-impact finding.

Do not copy entire databases to prove that one record was accessible. Prefer metadata, a controlled test record, a redacted screenshot, a hash or another minimal artefact when it provides adequate evidence.

Execute progressively and preserve safety

Begin with passive review and low-impact discovery, then move to increasingly active techniques only where the rules allow and previous evidence justifies it.

A typical controlled sequence is:

1. Validate written scope, contacts and target ownership.
2. Record the starting configuration and service health.
3. Map approved attack surfaces and authentication states.
4. Run limited checks at agreed rates.
5. Validate likely findings to reduce false positives.
6. Demonstrate impact using the least harmful sufficient proof.
7. Notify the client immediately when the agreed severity or safety trigger is reached.
8. Remove test accounts, artefacts and changes; confirm restoration.
9. Reconcile and protect evidence.

The OWASP Web Security Testing Guide provides structured test areas for web applications, but it is a methodology reference—not permission, a universal checklist or a substitute for system-specific threat modelling (OWASP Web Security Testing Guide).

Report evidence, uncertainty and business context

Each finding should state:

• affected asset and tested condition;
• evidence collected and time observed;
• prerequisite access or assumptions;
• plausible impact without exaggeration;
• confidence and limitations;
• prioritised remediation options;
• owner and target decision date; and
• retest result when completed.

Separate confirmed findings from unvalidated scanner output. A severity score can support prioritisation, but business exposure, exploit preconditions, existing controls, data sensitivity and operational consequences still require analysis.

Also document what was not tested. A clear limitations section prevents the report from being read as a certification that the environment is free of vulnerabilities.

Retesting closes findings, not risk forever

A retest should reproduce the original condition where safe, verify the intended control and check for obvious regression or workaround paths within scope. Record whether the issue is resolved, partially resolved, accepted, transferred or still open.

The result applies to the tested version and time. New code, configuration, dependencies, identities and threat conditions can change exposure immediately afterward.

Ozlin's current public service boundary

Subject to a signed scope and capability assessment, Ozlin may offer small-business work such as:

• WordPress, server and cloud configuration review;
• scoped vulnerability scanning and validation;
• authenticated web-security checks using agreed test accounts;
• internet-exposure and identity-permission review;
• backup and restore evidence exercises; and
• hardening recommendations with a documented retest.

Ozlin does not offer destructive payloads, denial-of-service, covert persistence, unauthorised testing, surprise social engineering or real-data extraction as routine services. Specialist or higher-risk work requires separate assessment and may be declined or referred.

See Cybersecurity services or contact Ozlin to define a written scope.

Related reading: Cybersecurity fundamentals for business risk.

This article is general information, not legal advice, authorisation, certification or a promise that a test will identify every vulnerability.

AI-assistance disclosure

AI tools assisted with source discovery, outlining and copyediting. A qualified human reviewer must verify every legal statement, scope rule, source, service capability and publication decision before release.

Primary sources checked

• Federal Register of Legislation — Criminal Code Act 1995, current compilation
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• NIST — Rules of Engagement definition
• OWASP — Web Security Testing Guide
• ASD — Guidelines for security assurance

Source access date: 29 August 2026.