Penetration Testing for Compliance: A Practical SOC 2, PCI DSS and HIPAA Guide

A Sydney-based healthtech company had been working toward SOC 2 Type II for eight months. The policies were written, the controls were documented, the access logs were clean. Then, three weeks before the audit window, their assessor flagged one gap that stopped the process cold.

The company had run a penetration test six months earlier. The report was thorough. The findings had been fixed. The problem was that the test had been conducted by an internal team member, and the SOC 2 assessor needed evidence of independent, third-party security testing. The internal report did not satisfy that requirement.

The company went back to the market, scrambled to engage a CREST-certified provider on short notice, compressed a three-week engagement into ten days under deadline pressure, and delayed their certification by two months.

That delay cost them a six-figure enterprise contract that had been conditional on SOC 2 completion.

This is not a story about a team that ignored security. It is a story about a team that did not understand exactly what compliance frameworks require from penetration testing specifically. That distinction matters more than most leadership teams realise until it is too late.

What SOC 2 Actually Requires From a Penetration Test

SOC 2 is built around the Trust Services Criteria. The security category, which is present in every SOC 2 audit, requires evidence that a company identifies and tests for vulnerabilities on an ongoing basis. Penetration testing sits squarely in this requirement.

What auditors are looking for is not a checkbox. They want evidence of a genuine, independent assessment of the systems in scope, conducted by qualified testers, with documented findings and documented remediation. The independence requirement is the one most teams underestimate. An internal team member conducting the test, or a provider without recognised credentials, typically does not satisfy what a Type II assessor needs.

For ANZ companies specifically, the CREST certification of the testing provider carries significant weight. Assessors and enterprise procurement teams in New Zealand, Australia, and Fiji increasingly expect CREST-certified providers rather than treating any third-party engagement as equivalent.

The other thing SOC 2 auditors evaluate is recency. A penetration test completed fourteen months ago does not demonstrate current security posture. It demonstrates what the posture was over a year ago, before whatever changed in the product, infrastructure, or team since then. Continuous or recurring testing produces the evidence trail that satisfies a Type II audit far more convincingly than a single point-in-time report.

Capture The Bug's penetration testing services are built to produce the documentation format and testing rigour that SOC 2 assessors expect, with CREST certification as the baseline standard.

What PCI DSS Requires and Where Teams Get It Wrong

PCI DSS has one of the most clearly defined penetration testing requirements of any major compliance framework. Requirement 11.4 mandates penetration testing of external-facing systems at least once per year and after any significant change to the cardholder data environment. It also requires segmentation testing if network segmentation is used to reduce the scope of the cardholder data environment.

There are two places where companies regularly get PCI DSS penetration testing wrong.

The first is scope. Many teams test only their web application and consider the requirement satisfied. PCI DSS scope includes the network infrastructure, any system that touches, stores, or transmits cardholder data, and all components connected to those systems. A web application test alone leaves significant gaps in what the standard actually requires.

The second is the segmentation test. If an organisation has implemented network segmentation to isolate the cardholder data environment from the rest of the infrastructure, a penetration test must confirm that the segmentation is effective. This is a specific, technical validation that goes beyond a standard application test and must be documented as a separate finding. Qualified Security Assessors regularly identify this as missing when reviewing PCI DSS compliance programmes. For any SaaS or fintech company in New Zealand, Australia, or Fiji handling payment data, this level of testing specificity is not optional. It is a condition of maintaining PCI DSS compliance, and failing to satisfy it correctly is the kind of gap that surfaces at exactly the wrong moment, usually during a banking partner review or a customer security assessment.

What HIPAA Requires and Why It Is Different

HIPAA does not use the phrase penetration testing. The Security Rule instead requires covered entities and business associates to conduct regular reviews of information system activity, implement procedures to guard against reasonably anticipated threats, and evaluate the effectiveness of security measures on an ongoing basis.

The practical interpretation of these requirements, as confirmed by years of HIPAA enforcement guidance and OCR audit results, is that penetration testing of systems holding or transmitting electronic protected health information is an expected component of a robust security programme.

What makes HIPAA different from SOC 2 and PCI DSS is the enforcement mechanism. HIPAA penalties are tied to breaches and to the absence of reasonable safeguards. An organisation that suffers a breach and cannot demonstrate that it conducted regular independent testing of its PHI-bearing systems faces significantly higher penalties than one that can show an ongoing testing programme. The penetration test is not just a compliance exercise. It is the evidence that demonstrates reasonable safeguards were in place.

For healthcare SaaS companies serving the US market from New Zealand or Australia, this is a material commercial and legal consideration. Enterprise US healthcare customers increasingly require HIPAA-aligned security evidence as part of vendor due diligence, and a CREST-certified penetration test report produced by an independent provider is the documentation that satisfies that requirement.

Why the Report Format Matters as Much as the Test

One thing that rarely gets enough attention in compliance discussions is that what the test finds matters, but how the findings are documented matters almost as much.

A report that lists vulnerabilities without mapping them to the specific controls being tested, without clear severity ratings, without a remediation timeline, and without retesting confirmation of fixes is technically a penetration test report. It is also a report that creates friction with every auditor who reviews it.

The best compliance-grade penetration test reports are structured to answer the questions an auditor will ask before the auditor asks them. They map findings to the specific compliance framework controls. They show the testing methodology clearly enough that an assessor can evaluate whether the scope was appropriate. They document the remediation status of every finding, including confirmation that critical and high-severity vulnerabilities were retested after fixes were applied. Capture The Bug's penetration testing services produce reports structured for exactly this purpose, with documentation designed to travel directly into SOC 2, PCI DSS, and HIPAA audit processes without requiring the team to translate or reformat findings for each framework.

The Commercial Reality Behind the Compliance Requirement

There is a pattern that runs across the ANZ companies that Capture The Bug works with. The compliance requirement that triggers the penetration test is rarely the only reason the test matters commercially.

A New Zealand SaaS company pursuing SOC 2 is usually doing so because an enterprise customer has made it a contract condition, or because a US market entry requires it, or because a funding round includes security diligence. The penetration test is simultaneously a compliance input and a commercial enabler. Getting it wrong delays not just the audit but the deal, the market expansion, or the funding close.

A Fiji-based payment platform under PCI DSS requirements is simultaneously managing its banking partner relationship, its enterprise customer security questionnaires, and its own cyber insurance policy. Each of those stakeholders is asking for overlapping but slightly different security evidence. A well-scoped, well-documented penetration test programme produces the raw material that satisfies all three without running a separate test for each. The companies that get the most commercial value from penetration testing are the ones that treat it as a programme rather than an event. They test before major launches, after significant infrastructure changes, and on a recurring annual cadence that keeps their evidence current regardless of which auditor or customer asks first. Capture The Bug builds its penetration testing services around exactly this programme model, giving ANZ and Pacific teams the testing coverage, the documentation quality, and the CREST-certified authority that compliance and commercial confidence both require.

The One Question Worth Asking Now

Every company managing SOC 2, PCI DSS, or HIPAA requirements should be able to answer one question clearly: if an auditor or enterprise customer asked for your penetration test evidence today, would what you have be sufficient, independent, current, and documented to the standard they expect? If the answer involves any hesitation, a conversation with the Capture The Bug team is the most useful next step. Understanding the specific gap is faster than discovering it under audit pressure.