Penetration Testing: Australian Compliance Requirements in 2026

When someone asks whether penetration testing is mandatory in Australia, the answer is rarely a simple yes or no.

Different organisations answer to different rules. A bank, government agency, SaaS provider, and retail business may all face very different expectations, even when they use similar technology.

That distinction matters more as the cost of cybercrime rises. ASD reported that Australian businesses lost an average of AUD 80,850 per cybercrime report in FY 2024 to 2025, 50%  more than the previous year.

This is where confusion around penetration testing in Australia often begins. Some organisations need formal security testing under regulatory or contractual obligations. Others may need it because of their systems, risk exposure, or assurance requirements. A vulnerability scan will not always satisfy the same purpose.

The real question is not simply whether you should test. It is what applies to your organisation in 2026.

Is Penetration Testing Mandatory for Australian Businesses?

Penetration testing is mandatory for some Australian organisations, but not for every business. Government systems covered by ISM 2118, accredited Digital ID providers, PCI DSS environments, and certain ST4S suppliers can face explicit testing requirements. By comparison, apra cps 234 penetration testing requirements focus on systematic control testing rather than one annual test for every entity. 

Other frameworks may recommend or support testing without universally mandating it. Contracts, tenders, insurance policies, procurement rules, or certification programs can also make testing compulsory.

Australian Compliance Frameworks That Affect Penetration Testing

Australian frameworks take different approaches to security testing. Some contain an explicit penetration testing requirement, while others focus on risk based assurance, control testing, or supporting evidence. This table gives you a quick comparison before we look at each framework in more detail.

Need a Pen Test?

Talk directly with senior security experts. Book a quick call or grab a quote today.

Get a Quote →

APRA CPS 234: Information Security

CPS 234 applies to APRA-regulated institutions, including banks, insurers and superannuation entities. It requires a systematic program for testing information security controls. Testing scope and frequency should reflect changing threats, asset sensitivity, incident consequences, external exposure and material changes.

Penetration testing may be used where suitable, alongside other assurance methods. For third-party managed assets, entities must assess whether provider testing is adequate, while skilled, functionally independent specialists conduct testing and significant weaknesses are escalated for remediation.

What Should a CPS 234 Penetration Test Cover?

CPS 234 does not prescribe one penetration testing checklist. Scope should reflect the information assets, risks, exposure, and controls being assessed. Depending on the environment, testing may cover:

• Internet-facing systems and internal networks
• Web applications, APIs, cloud infrastructure, and IAM
• Authentication, authorisation, segmentation, and sensitive data flows
• Relevant third-party integrations

Greater depth may be appropriate for critical assets, sensitive information, public exposure, or major architectural changes. Test objectives should also match the control being assured, such as whether unauthorised lateral movement is possible rather than simply listing vulnerabilities.

CPS 234 Penetration Testing Frequency

CPS 234 does not require every APRA-regulated entity to run a penetration test once every 12 months. Testing frequency depends on factors such as threat changes, asset sensitivity, exposure, and system changes. APRA does require the overall testing program to be reviewed at least annually or after a material change.

A penetration testing finding is also not automatically reportable within 72 hours. That timeframe applies to qualifying information security incidents. Material control weaknesses that cannot be remediated promptly have a separate notification period of 10 business days.

CPS 234 Penetration Testing Frequency

CPS 234 does not prescribe one annual penetration test for every APRA-regulated entity. The frequency of security control testing should reflect factors such as changing threats, asset sensitivity, exposure, incident consequences, and material changes. APRA requires the overall testing program to be reviewed at least annually or after a material change.

For reporting, CPS 234 sets 72 hours for qualifying information security incidents. A separate 10-business-day timeframe applies to material information security control weaknesses that the entity expects it cannot remediate promptly.

APRA CPS 230: Operational Risk Management and Penetration Testing

CPS 230 governs operational risk, continuity of critical operations, control effectiveness, and service provider risk. It does not create a standalone penetration testing requirement. APRA instead requires entities to test operational controls at a frequency appropriate to the materiality of the risks involved.

A penetration test may still provide evidence about controls supporting critical systems, technology resilience, or third-party connections. For information security risk, CPS 230 directs entities to CPS 234, so technical testing should generally be mapped to those security obligations rather than labelled a CPS 230 penetration test. The amended CPS 230 standard took effect on 1 July 2026.

What’s the difference between CPS 230 and CPS 234?

CPS 230 focuses on operational risk, critical operations, business continuity, control effectiveness, and service provider arrangements. CPS 234 deals specifically with information security, including security controls, vulnerabilities, incidents, and testing.

For example, a bank may treat its customer authentication platform as critical to service continuity under CPS 230. Testing whether attackers can compromise that platform relates more directly to CPS 234 security assurance. A weakness may affect obligations under both standards, but the standards serve different purposes and do not prescribe identical testing.

ST4S Penetration Testing Requirements for Australian EdTech Providers

Safer Technologies 4 Schools, or ST4S, assesses the privacy and security of digital products used by schools across Australia and New Zealand. Participation is voluntary, although suppliers may be invited to complete an assessment by a school or education authority during procurement.

For EdTech providers, the assessment is particularly relevant when products handle:

• Student or teacher information
• Login credentials and authentication data
• Class records, communications, or assessment information

ST4S therefore adds a sector-specific assurance layer that general Australian cybersecurity guidance may not address.

What Is ST4S and Who Does It Apply To?

ST4S evaluates digital products and services supplied to schools rather than setting a general security obligation for Australian businesses. It is relevant to providers such as:

• SaaS and learning management platforms
• Classroom and assessment applications
• Communication, identity, and administration systems
• Products incorporating generative AI or other AI functionality

ST4S should also be assessed separately from ISO 27001, the Essential Eight, and government ISM requirements. These frameworks may address similar security controls, but completing one does not automatically satisfy the others.

What Penetration Testing Does ST4S Require?

Under ST4S question T1, suppliers are expected to maintain continuous security monitoring that includes:

• Asset discovery and vulnerability scanning
• Penetration testing after a major change or at least annually
• Vulnerability analysis and mitigation
• Risk-based prioritisation of fixes

External independent testers are recognised as a stronger response option, but outsourcing is not mandatory. If major system changes occur during the year, additional penetration testing may be needed rather than waiting for the next annual cycle.

ST4S Penetration Testing for SaaS and Multi-Tenant EdTech Platforms

Multi-tenant EdTech platforms often serve several schools, teachers, administrators, and students through one shared system. A vulnerability assessment and penetration testing (VAPT) engagement should therefore check whether one tenant or account can reach data or functions assigned to another.

Key scenarios include:

• Tenant isolation: Test access to another school’s records, files, classes, exports, or user data.
• Broken access control: Change identifiers in web requests and APIs to uncover IDOR or broken object-level authorisation.
• Privilege escalation: Check whether students, teachers, or administrators can perform actions reserved for higher roles.
• API authorisation: Test tokens, object permissions, function-level access, mass assignment, and role enforcement.
• Data exposure: Review exports, logs, search results, cached responses, files, and API responses for personal information leakage.
• Administrative functions: Examine role changes, account creation, password resets, bulk exports, support access, and deletion functions.
• Session security: Test expiry, logout invalidation, token replay, refresh tokens, and privilege changes.

These are practical penetration testing scenarios that can support ST4S security assurance. ST4S does not present every OWASP term above as a separate named requirement.

ST4S AI Security Testing Requirements

This includes an AI Module for products that use artificial intelligence in education. The framework separates AI testing into security, privacy, and safety evidence, and specifically recognises jailbreaking and penetration testing as security testing methods.

ST4S treats these areas separately for evidence purposes. Security testing may include jailbreaking and penetration testing, while privacy testing looks at personal information exposure and safety testing examines whether generated content is appropriate for the intended audience.

What Evidence Should an ST4S Penetration Test Provide?

ST4S lists EV10 as the latest penetration testing report for the service, with sensitive details removed where necessary. EV11 separately asks for the latest vulnerability assessment report. This confirms that ST4S treats penetration testing and vulnerability assessment as different forms of evidence.

The penetration testing report should clearly show:

• Organisation and service tested
• Testing date and scope
• Applications, URLs, APIs, and environments covered
• Authenticated and unauthenticated coverage
• Testing methodology
• Confirmed vulnerabilities, severity, and impact
• Recommended fixes
• Exclusions and limitations
• Remediation progress
• Retesting results where fixes were checked

Also, ST4S expects submitted documents to contain technical information that is specific to the service being assessed.

ST4S Framework Version and 2026 Considerations

ST4S v2026.1 was published on 21 July 2026 and is currently listed as the latest active framework version. It updated 41 assessment questions across the Full Assessment and AI Module, including changes to authentication-related risk ratings and stronger AI safety requirements.

If your penetration testing report predates the current product version, check whether:

• Major system changes occurred after testing
• New AI features were outside the original scope
• Current APIs and tenant boundaries were assessed
• The report is still suitable for the ST4S assessment being completed

PCI DSS v4.0.1 Penetration Testing Requirements in Australia

PCI DSS is a global payment card security standard rather than Australian legislation. Australian organisations must consider it when their cardholder data environment falls within PCI DSS scope.

Under PCI DSS v4.0.1, penetration testing is covered by Requirement 11.4. Applicable organisations need to address:

• Internal and external penetration testing
• Testing at least once every 12 months
• Additional testing after significant infrastructure or application changes
• A documented testing methodology
• Network and application layer coverage
• Correction of exploitable weaknesses
• Retesting after remediation where appropriate
• Segmentation testing when segmentation is used to reduce PCI DSS scope

Vulnerability scanning is handled separately under Requirement 11.3. A passing scan does not replace the penetration testing required under 11.4.

The exact scope depends on how the organisation processes cardholder data and defines its cardholder data environment.

Essential Eight and Penetration Testing in Australia

The Essential Eight is ASD guidance built around eight priority mitigation strategies for common cyber threats. Penetration testing can provide additional assurance around an organisation’s security, but it is not part of the Essential Eight maturity assessment itself.

If you use Essential Eight compliance services, the assessment should measure implementation against the relevant maturity level rather than replace that work with a penetration test.

Does Essential Eight Require Penetration Testing?

No. The Essential Eight does not prescribe penetration testing or an annual penetration testing schedule, including at Maturity Level 2. ASD does require vulnerability scanning for certain patching controls, but scanning and penetration testing are different activities.

ASD also states that independent certification is not generally required. Independent assessment may still apply where a government policy, regulator, or contract calls for it.

How Penetration Testing Supports Essential Eight

An Essential Eight assessment tells you whether the required controls are implemented. A penetration test can then challenge some of those controls from an attacker’s point of view. For example, it may uncover an exploitable unpatched service, weak session handling that undermines MFA, or a path around privilege restrictions.

It can also test whether application controls and administrative boundaries hold up under attack. The results give you another layer of technical assurance, while the Essential Eight maturity assessment remains a separate exercise.

Essential Eight Maturity Levels and Security Testing

The Essential Eight has four maturity levels, from Zero to Three. They show how well an organisation is prepared to deal with increasingly capable and targeted attackers, rather than assigning a specific security test to each level.

So there is no rule such as:

• Maturity Level 1 means vulnerability scanning
• Maturity Level 2 means penetration testing
• Maturity Level 3 means red teaming

Organisations may still use penetration testing, adversary simulation, or red teaming when they want broader assurance, but those activities do not determine the Essential Eight maturity level.

Australian Government ISM and Penetration Testing

The Australian Signals Directorate publishes the Information Security Manual as a cyber security framework for protecting IT and operational technology systems. In June 2026, ASD added ISM 2118, Revision 0, which introduced a clear testing schedule.

For systems where the control applies, vulnerability assessments and penetration tests must be conducted:

• Before deployment
• Before significant changes are deployed
• At least annually afterwards

A significant change may include a major cloud migration, new authentication design, substantial application redesign, new external APIs, or changed network boundaries. The trigger should reflect a material change to the attack surface or control environment, not every routine release.

ISM vs Essential Eight

The ISM is a broad cyber security framework containing detailed controls for protecting IT and operational technology systems. The Essential Eight is a smaller set of eight prioritised mitigation strategies intended to reduce common cyber threats. 

The Essential Eight does not create the same penetration testing schedule. So you should first identify which ASD framework and controls apply to your system rather than assuming an ISM requirement automatically becomes an Essential Eight requirement.

Digital ID (Accreditation) Rules 2024 and Penetration Testing

The Digital ID (Accreditation) Rules 2024 contain one of the clearest Australian penetration testing requirements. Rules 3.8, 3.9, and 3.10 apply to applicants and accredited entities where the relevant accreditation rules apply.

Testing must cover ingress and egress points, unauthenticated black box testing, and authenticated white box testing. Cloud-hosted environments remain relevant to scope, with separate provisions where the provider does not permit direct testing of its infrastructure.

The assessor must be external to the entity and independent of the design, implementation, operation, or management of the relevant environment. The report must document the testing and findings so they can inform the later security assessment. Penetration testing is generally repeated for each annual reporting period.

SOCI Act and Critical Infrastructure Penetration Testing

The Security of Critical Infrastructure Act 2018 does not require every critical infrastructure organisation to carry out penetration testing. Obligations vary according to the asset, the responsible entity, and whether additional requirements have been applied.

The SOCI framework includes:

• General obligations such as asset registration and cyber incident reporting
• Critical Infrastructure Risk Management Program requirements for applicable assets
• Systems of National Significance, or SoNS
• Enhanced Cyber Security Obligations that may apply to a SoNS

One possible Enhanced Cyber Security Obligation is a vulnerability assessment. Penetration testing may contribute technical evidence to such an assessment by examining external exposure, lateral movement, privileged access, segmentation, identity controls, critical interfaces, and third-party connections.

It should not, however, be described as a standard SOCI penetration testing requirement for every critical infrastructure entity.

2026 SOCI/CIRMP Updates

The CIRMP Rules were amended in June 2026, adding enhanced requirements for specified critical infrastructure asset classes. Among the new provisions are separate hazard categories for credential compromise and lateral movement.

For organisations subject to those enhanced requirements, technical testing can help examine whether attackers could:

• Abuse stolen or compromised credentials
• Escalate privileges after gaining access
• Move between connected systems and critical systems
• Exploit trust relationships between environments
• Misuse remote administrative access
• Reach systems that support critical asset functions

The amendments do not create a nationwide annual penetration testing rule. 

Australian Privacy Act and Penetration Testing

The Australian Privacy Act does not require every APP entity to perform penetration testing. APP 11 instead requires reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification, and disclosure. Since 11 December 2024, APP 11.3 has expressly included technical and organisational measures within those reasonable steps.

What is reasonable depends on the organisation, its resources, the amount and sensitivity of information held, possible harm from a breach, and its information handling environment.

For organisations holding large volumes of sensitive information, penetration testing can help assess whether technical protections resist realistic attacks. Scope may need to extend beyond the public website to APIs, cloud access controls, SaaS integrations, and third-party systems.

Security should also follow the information lifecycle, including collection, storage, access, transfer, retention, and deletion.

ISO/IEC 27001 and Penetration Testing in Australia

ISO/IEC 27001:2022 is the current version of the international information security management standard. ISO lists the 2013 edition as withdrawn. The standard requires organisations to run an ISMS, assess information security risks, and choose controls that match those risks.

Penetration testing can support cyber security auditing australia when technical evidence is needed for areas such as vulnerability management, secure development, change management, or control effectiveness.

The testing schedule should come from factors such as:

• Risk assessment
• Statement of Applicability
• Selected controls and internal policies
• Audit findings
• Customer commitments
• Significant system changes

ISO 27001 certification does not, by itself, mean an organisation must complete a penetration test every year.

Does ISO 27001 Require Annual Penetration Testing?

No. ISO/IEC 27001:2022 does not require every certified organisation to run a penetration test each year. ISO treats security through a risk-based ISMS rather than one fixed testing calendar.

Annual testing may still be appropriate if your risk assessment or internal policy calls for it. The same can apply when a contract or another framework sets that expectation.

If your own policy requires yearly testing and you do not follow it, that can become an audit issue.

SOC 2 and Penetration Testing for Australian SaaS Companies

SOC 2 is often relevant to Australian SaaS companies selling to enterprise customers, especially when buyers want independent assurance over security controls. It is not Australian legislation, and the Trust Services Criteria do not set one universal annual penetration testing requirement.

A penetration test may still support the controls examined in a SOC 2 engagement. For a SaaS platform, useful areas include:

• Tenant isolation
• Authentication and authorisation
• API security
• Administrative privileges
• Cloud IAM
• Session management
• Exposure of customer data

Many SaaS companies also face a commercial requirement rather than a legal one. Enterprise customers may ask for a recent penetration test during procurement even when SOC 2 itself does not prescribe that schedule.

Which Penetration Test Does Your Australian Compliance Framework Require?

There is rarely a simple rule where one compliance framework equals one specific penetration test. The right scope depends on the systems involved, the controls being assessed, and the attack paths that matter to that environment.

Black box, grey box, and white box describe how much knowledge and access testers receive. They are not separate compliance certifications.

What Should an Australian Compliance Penetration Test Include?

A compliance-focused penetration test should be planned around the requirement you need to satisfy. The test should produce clear evidence of what was assessed, what weaknesses were confirmed, and whether fixes were successfully retested.

1. Scope Definition

Before testing begins, identify the compliance requirement and map the systems covered by it. Depending on the environment, scope may include:

• Domains and IP ranges
• Web applications and APIs
• Cloud accounts
• Mobile applications
• Internal networks
• User roles and test accounts
• Third-party integrations
• Production and nonproduction environments

The scope should also state whether authenticated testing is needed and record any exclusions.

2. Rules of Engagement

Before testing begins, the organisation authorising the work should provide written approval and confirm exactly what the tester is allowed to do. NIST describes rules of engagement as the agreed limits and conditions for a security test.

The document should cover:

• Approved targets and testing dates
• Test accounts and credentials
• Permitted exploitation
• Restricted techniques such as denial of service
• Social engineering permissions where relevant
• Limits on data access or extraction
• Production safety requirements
• Emergency stop procedures
• Technical and business contacts

Third-party systems also need attention. If cloud or externally managed infrastructure is involved, confirm that the organisation has permission to test those resources and follow the provider’s testing rules.

3. Asset Discovery

Asset discovery checks whether the organisation’s inventory matches what is actually reachable. Testers may find overlooked subdomains, hosts, services, APIs, or interfaces that still fall within the approved scope. 

If discovery reveals an asset outside the agreed boundary, it should be documented first. Testing should continue only after scope approval is updated.

4. Vulnerability Identification

Automated tools can quickly flag known weaknesses across the approved environment, but their output should not be treated as final. Manual review helps remove false positives and uncover issues that scanners often miss, especially flaws tied to access control or application logic. 

The review may cover misconfigurations, outdated software, weak authentication, exposed services, insecure API behaviour, session problems, access control flaws, and data exposure. Scanner findings should stay separate from vulnerabilities that testers have manually confirmed.

5. Manual Exploitation

Once a weakness has been identified, the tester needs to find out whether it can actually be exploited. This should be done carefully and only within the agreed testing boundaries.

The goal is to collect enough evidence to prove the issue and help developers fix it. There is no need to access or copy more sensitive information than necessary. Manual exploitation matters because automated scanners can flag possible weaknesses, but they cannot always confirm whether those weaknesses are genuinely usable in an attack.

6. Privilege Escalation

Privilege escalation testing looks at what happens after a user gains limited access. The tester checks whether that account can reach information or functions it should not have.

This can include:

• Accessing another user’s resources at the same privilege level
• Moving from a standard account into an administrator role
• Manipulating roles or restricted functions
• Abusing cloud IAM permissions
• Following Active Directory or Entra ID attack paths where relevant

7. Business Logic Testing

Some security flaws only appear when someone uses a feature in a way the application was never designed to handle. A scanner cannot understand every approval process, account rule, transaction limit, or workflow.

A tester may try skipping approval stages, changing another user’s account, abusing password recovery, bypassing transaction limits, or calling APIs in an unexpected order. 

8. Attack Chaining

A low severity issue may look harmless on its own but become serious when combined with another weakness. Testers should therefore look for realistic attack paths rather than assessing every finding in isolation.

Examples include:

• Information disclosure leading to credential discovery and account takeover
• Weak access control leading to privilege escalation and sensitive data export
• An exposed internal service leading to lateral movement and administrator access

9. Risk-Based Reporting

Findings should be ranked using technical severity and actual business impact. A useful report should show the affected asset, vulnerability details, reproduction steps, supporting evidence, likely impact, severity, recommended fix, and any relevant compliance mapping.

If CVSS is used, the score should support the assessment rather than replace business context. 

10. Remediation Validation

Once findings are assigned to the right owners, their status should be tracked clearly. Useful states include:

• Open
• Remediated but not verified
• Risk accepted
• Not applicable
• False positive

A fix is not fully validated simply because a developer says it has been completed. Retesting gives independent confirmation that the weakness is no longer exploitable.

11. Final Retest

Once fixes are in place, the tester should go back to the original finding and try the attack again. The aim is to confirm that the full weakness has been removed, not just the most obvious symptom.

A good retest also checks whether the fix created another security issue. The final report should then update each finding so customers and auditors can clearly see what has been resolved and what risk still remains.

12. Compliance Evidence Package

A penetration test should leave you with enough evidence to show exactly what happened during the assessment. A vulnerability list on its own does not do that.

Keep the key records together, including:

• Final scope
• Rules of engagement
• Testing dates
• Methodology used
• Tester identity and relevant qualifications
• Independence details where required
• Assets tested
• Findings and supporting evidence
• Remediation records
• Retest results
• Accepted risks
• Framework mapping where it is supported

This gives auditors and customers a clear record of what was tested and how the organisation deal with the issues that were found. 

Want a Sample Penetration Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report→

Penetration Testing vs Vulnerability Scanning for Compliance

Vulnerability scanning and penetration testing both have a place in security assurance. The mistake is treating them as the same thing when a framework asks for one specific type of evidence.

How Often Should Australian Organisations Perform Penetration Testing?

There is no single penetration testing schedule for every Australian organisation. The timing comes from the framework that applies to your systems.

• ISM 2118: Before deployment, before significant changes, and at least annually afterwards.
• Digital ID: Each applicable reporting period, which is generally yearly.
• PCI DSS v4.0.1: At least every 12 months and after significant changes. Segmentation controls may also need separate testing.
• ST4S T1: After a major change or at least annually.
• CPS 234: Frequency is based on risk.
• Essential Eight: No universal penetration testing schedule.
• APP 11: No prescribed penetration testing frequency.
• ISO/IEC 27001: Timing follows the organisation’s ISMS and risk decisions.
• SOC 2: Frequency may come from control design, customer commitments, auditor expectations, or risk.
• General SOCI obligations: No universal penetration testing schedule.

Calendar dates are only part of the decision. A new assessment may also be appropriate after a major production release, cloud migration, authentication redesign, significant API launch, major third-party integration, security incident, or material architecture change.

Looking for a penetration testing partner? Check out our expert-curated list of leading penetration testing companies in Australia.

What Evidence Do Auditors Expect From a Penetration Test?

There is no single penetration testing report format that works for every framework. An auditor should be able to see:

• What system was tested
• What was included or excluded
• When the test took place
• Which methodology was used
• Whether testing was authenticated
• Who performed the test
• Whether independence requirements were met
• Which vulnerabilities were confirmed
• Which assets were affected
• What fixes were recommended
• What was remediated and retested
• What risk remains open or accepted

How to Prepare for a Compliance Penetration Test in Australia

Good preparation helps avoid scope disputes and testing delays. It also makes the final evidence more useful for auditors or customers.

Before testing, confirm the following:

• Applicable requirements: Identify whether the test is driven by ISM, CPS 234, ST4S, PCI DSS, Digital ID, ISO 27001, customer assurance, or another obligation.
• Assets in scope: List domains, applications, APIs, IP ranges, cloud accounts, networks, mobile apps, identities, and third party integrations.
• Critical systems: Prioritise environments where compromise could affect sensitive information, regulated processes, customers, or important services.
• Control objectives: Link each system to the security control or risk the test is meant to assess.
• Test accounts: Prepare the user roles needed for authenticated testing, including normal, privileged, tenant specific, and administrative accounts where relevant.
• Third-party permissions: Check cloud provider rules and obtain permission for externally managed infrastructure where needed. Microsoft, for example, requires explicit authorisation for third parties testing Azure resources owned by a customer.
• Testing windows: Decide when production testing is allowed and when higher risk activity can take place.
• Emergency contacts: Name people who can pause or change the test if operational problems appear.
• Architecture information: For grey box or white box testing, share relevant diagrams, API documentation, data flows, authentication details, and trust boundaries.
• Test environment: Confirm that the environment being assessed uses the controls that actually need assurance.
• Rules of engagement: Record what techniques are allowed, what is prohibited, and how evidence should be handled.
• Remediation ownership: Decide who receives findings, who fixes them, and who coordinates retesting.

Complete this work before asking providers for quotations. Cost comparisons are much more useful when every provider is pricing the same approved scope.

How to Choose a Penetration Testing Company in Australia

Start with the requirement you need to satisfy. Accreditations are useful, but they do not tell you whether the proposed test covers your systems properly.

Look for Relevant Accreditations

Company accreditation and tester certification are not the same thing. CREST accredits organisations against standards for services such as penetration testing. Individual professionals can separately hold CREST certifications. 

When searching for CREST-certified penetration testing, check both sides. Confirm whether the provider holds CREST penetration testing accreditation and review the qualifications of the people assigned to your project.

Relevant individual credentials may include CREST Registered Penetration Tester or CREST Certified Tester qualifications. Offensive Security credentials such as OSCP, OSEP, OSWE, OSED, and OSCE3 can also indicate technical capability. The original OSCE has been retired and replaced by the newer OSCE3 pathway. 

Evaluate Manual Testing Capability

Ask what happens after the scanners finish. A capable testing team should be able to manually examine areas such as access control, authentication, privilege escalation, business logic, API workflows, tenant separation, and attack chaining.

Scanner results should also be checked before they reach the final report. Ask the provider to explain what its testers will do manually that automated tools cannot reliably assess.

Check Compliance Mapping Capability

A provider should understand the framework behind your test. That means knowing when penetration testing is explicitly required and when it is only one way to test a broader security control.

Be cautious if a provider claims one penetration test will prove full compliance with CPS 234, ISO 27001, SOC 2, the Privacy Act, or Essential Eight. A technical assessment can provide evidence for those programs without certifying the entire organisation against them.

Ask About Retesting

Find out what happens after vulnerabilities are fixed. Ask whether retesting is included in the quoted price and how long you have to request it.

Also confirm whether every finding can be retested or only selected severity levels. The final documentation should clearly distinguish a fix reported by the development team from one that the tester has checked successfully.

Review Sample Reporting

Ask to see a sample report with sensitive client details removed before choosing a provider. Look for clear evidence that another technical person could understand and reproduce.

Useful reports normally show:

• Affected assets
• Reproduction details
• Evidence from the test
• Business impact
• Severity reasoning
• Technical remediation
• An executive summary
• Retest status

Confirm Tester Independence

Do not assume that every framework uses the word independent in the same way.

Under CPS 234, testing must be performed by appropriately skilled and functionally independent specialists. Functional independence is intended to avoid conflicts of interest and does not automatically require an outside consultancy.

Digital ID uses a stricter model. Its penetration testing assessor must be external to the accredited entity and independent of the design, implementation, operation, or management of the relevant environment or accredited services. 

PCI DSS permits qualified internal resources or qualified external providers, but organisational independence of the tester must exist.

Essential Eight does not generally require independent certification. ST4S recognises the use of external independent resources for penetration testing as a stronger response under its T1 criteria, rather than making external testing a legal requirement for every supplier.

Put the independence requirement that applies to your framework into the statement of work before testing begins.

Why Choose Qualysec for Compliance Penetration Testing in Australia?

Qualysec is CREST accredited for Penetration Testing, giving organisations a recognised provider credential when CREST matters during procurement or vendor review.

Our testing covers web applications, APIs, mobile apps, cloud environments, internal and external networks, infrastructure, IoT, and AI red teaming. This allows connected parts of the same environment to be assessed under one engagement instead of splitting them across unrelated tests.

The assessment combines automated discovery with hands-on testing. Testers manually validate findings, examine access controls and business logic, attempt controlled exploitation, and investigate attack paths that scanners may miss.

Reports include evidence and remediation guidance, with retesting available after fixes are made. Qualysec can also scope testing around the technical assurance needed for frameworks such as ISM, CPS 234, PCI DSS, ST4S, ISO 27001, or SOC 2.

Discussing the framework and environment before requesting a quote helps define the right scope, reporting, and retesting needs from the start.

Conclusion

Australian penetration testing requirements depend on the framework, system, and assurance need involved. Some rules call for penetration testing directly, and some leave organisations to decide the right form and frequency of testing based on risk.

The important part is knowing which obligation applies before you commission the test. From there, define the right scope, test the relevant assets, fix confirmed weaknesses, and keep clear evidence of the retest.

If you need help planning a compliance-focused assessment, Qualysec can help scope web, API, mobile, cloud, network, infrastructure, or AI testing around your applicable requirements.

FAQs

Is penetration testing mandatory in Australia?

Not for every organisation. Penetration testing is expressly required in some contexts, including applicable ISM 2118 systems, Digital ID accreditation, PCI DSS environments, and relevant ST4S criteria. Other Australian frameworks rely on broader security assurance or risk-based testing.

How does penetration testing support compliance?

Penetration testing gives you technical evidence showing how security controls perform when tested against realistic attack methods. That evidence can support an audit or assurance program, but a penetration test alone does not prove compliance with an entire framework.

How often do I need a compliance penetration test?

The framework determines the timing. ISM 2118, PCI DSS, and applicable ST4S criteria include annual or change-related triggers. CPS 234 uses risk-based testing frequency, while APP 11 does not prescribe a penetration testing schedule.

Does an automated vulnerability scan count as a compliance penetration test?

Not when the applicable requirement specifically asks for penetration testing. A vulnerability scan mainly identifies possible weaknesses. Penetration testing adds human analysis and controlled exploitation to determine whether those weaknesses can actually be used in an attack.

What happens if a penetration test identifies critical vulnerabilities?

Critical findings should be assessed quickly and prioritised for remediation. After the fix, retesting should confirm that the weakness is closed. Regulatory notification depends on the applicable rules. Under CPS 234, the 72-hour requirement applies to qualifying information security incidents.

Who provides penetration testing services in Australia?

Testing may be performed by qualified internal specialists or an external provider, depending on the framework and its independence rules. Qualysec offers CREST-accredited penetration testing for Australian organisations across applications, APIs, cloud environments, networks, infrastructure, and other systems.

How much does penetration testing cost in Australia?

There is no reliable single price for penetration testing. Cost changes with application size, asset count, user roles, APIs, cloud scope, tester effort, reporting depth, and retesting. A defined scope gives you a more useful quote than a generic market average.