A payment platform based in Auckland had been processing card transactions for three years without a significant incident. Their PCI DSS compliance programme was tidy on paper. They ran quarterly external scans through a provider they had used since the beginning, resolved any flagged issues before the report was submitted, and checked the box every ninety days.
Then a Qualified Security Assessor conducting their annual review asked a question that nobody had anticipated. The QSA wanted to know what had happened to the twelve new IP addresses added to the company's external footprint over the previous two quarters. The addresses had been spun up as part of a cloud infrastructure expansion. None of them had ever been included in the ASV scan scope.
The organisation had been technically running quarterly scans as required. But the scans were covering a snapshot of the infrastructure that existed when the programme was first set up, not the infrastructure that existed now. The cardholder data environment had grown without the scanning scope growing with it.
That single oversight held up their compliance certification for two months, triggered a full rescoping exercise, and required three additional scan cycles to close out before the QSA could sign off. The commercial cost, in delayed contracts and engineering time, was significant.
This is not an unusual story. It is one of the most common PCI DSS compliance failures that payment businesses across New Zealand, Australia, and Fiji encounter, and it comes down to a misunderstanding of what ASV scanning actually is and what it is actually for.
What PCI ASV Scanning Actually Is
ASV stands for Approved Scanning Vendor. The Payment Card Industry Security Standards Council maintains a list of organisations approved to conduct external vulnerability scanning against internet-facing systems in scope for PCI DSS. The standard requires that any entity that stores, processes, or transmits cardholder data must run these external scans at least once per quarter and after any significant change to the cardholder data environment.
The scan itself is an external assessment of internet-facing IP addresses and domains within the defined scope. It looks for known vulnerabilities in services, open ports, expired certificates, unpatched systems, and misconfigurations that could be exploited to reach cardholder data. A passing scan result from an approved vendor is a mandatory input into PCI DSS Level 1 and Level 2 compliance reporting.
What ASV scanning is not is a penetration test. The two are separate requirements under PCI DSS and they measure different things. The ASV scan checks the external surface for known exposures. The penetration test, required under Requirement 11.4, actively attempts to exploit those exposures and test whether the defences actually hold. Both are required. They are not interchangeable. Understanding this distinction matters because teams that conflate the two either run scans when they need a test, or run tests when they still have not satisfied the quarterly scan requirement. Either way, the compliance gap remains open.
Why Scope Is the Part That Quietly Fails
The Auckland story above is a scope failure. It is also the most common kind of PCI ASV failure because it does not announce itself. The scans keep running, the reports keep passing, and nothing looks wrong until the next independent review reveals that the infrastructure being scanned is no longer representative of the infrastructure in production.
This happens because external attack surfaces are not static. A SaaS or fintech company in New Zealand or Australia with an active cloud environment can add new services, new domains, new subdomains, new IP ranges, and new third-party integrations on a cycle that moves faster than a quarterly review allows. Each new component that touches or connects to the cardholder data environment is potentially in scope for PCI DSS. Each one that is not included in the ASV scan is a gap.
The practical discipline required is not just running the scan. It is maintaining an accurate and current inventory of every internet-facing component in scope, reviewing that inventory before each scan cycle, and ensuring the vendor scanning scope reflects the actual environment rather than the environment as it was when the programme was originally set up. For businesses growing quickly, this discipline is harder to maintain than it appears. Engineering teams add infrastructure. Third-party integrations expand. Cloud configurations change. Without a process that connects those changes to the compliance programme in real time, the scan scope drifts and the compliance posture drifts with it.
What a Failing Scan Actually Means
A scan that fails is not a compliance crisis. It is a compliance signal that requires a structured response.
When an ASV scan returns failing results, the organisation has ninety days to resolve the vulnerabilities identified and run a passing scan before the quarter closes. The QSA will want to see evidence of both the initial scan, the remediation, and the passing rescan. A failure with no documented remediation or a failure with remediation that is not verified by a subsequent passing scan leaves a gap in the compliance record.
The remediation process matters as much as the finding. A vulnerability that is noted in a scan, patched in the system, but never confirmed by a rescan is technically still an open finding from the QSA's perspective. This is the same principle that applies to penetration testing: the fix needs to be verified, not assumed. For payment businesses in New Zealand, Australia, and Fiji that process card data and rely on their PCI DSS certification to maintain banking relationships and satisfy enterprise customers, a failure to close out scan findings correctly is a compliance failure regardless of whether the underlying vulnerability was actually remediated. Capture The Bug's penetration testing services are built around exactly this verification discipline, ensuring that findings are not just identified but confirmed as closed before the programme moves forward.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
The Relationship Between ASV Scanning and the Broader Compliance Programme
PCI DSS compliance is not a series of independent requirements that can be satisfied separately and filed away. The standard is designed as a connected programme where each element informs the others. ASV scanning sits within that programme alongside internal vulnerability management, penetration testing, log review, access control testing, and documentation.
The quarterly scan is the organisation's external eyes on its own attack surface. It answers the question of what the outside world can see and reach. The annual penetration test answers the question of what an attacker can actually do with what they can reach. Log review and monitoring answer the question of what is happening right now. Together they form a picture of security posture that no single element can provide alone.
The businesses in the ANZ and Pacific region that manage PCI DSS compliance most effectively treat it as a continuous programme rather than a series of quarterly tasks. They maintain their scope inventory between scan cycles, they treat scan failures as operational signals rather than administrative problems, and they connect their external scan programme to their internal testing and remediation tracking so that findings across all elements of the compliance programme are visible in one place. Capture The Bug's penetration testing services are specifically designed to integrate with this kind of continuous compliance programme, giving ANZ and Pacific payment businesses the CREST-certified testing coverage and documentation quality that PCI DSS requires across both the ASV and penetration testing requirements.
What Payment Businesses in ANZ Should Be Doing Now
The most useful immediate action for any payment business in New Zealand, Australia, or Fiji currently managing PCI DSS compliance is to conduct a scope review before the next quarterly scan cycle begins.
That review should ask three questions. First, does the current scan scope include every internet-facing IP address, domain, and subdomain that connects to or supports the cardholder data environment? Second, have any new services, cloud components, or third-party integrations been added since the last scope review? Third, are any recent scan failures documented with both a remediation record and a passing rescan confirmation?
If any of those three questions produces a hesitation, the scope needs attention before the next scan rather than after it.
A conversation with the Capture The Bug team is the right starting point for any organisation that wants an independent view of where their PCI DSS compliance programme has gaps, what those gaps cost in risk and commercial exposure, and what a continuous programme would look like built around their specific environment. Visit Capture The Bug's penetration testing services to start that discussion.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
FAQ
1. What is PCI ASV scanning?
PCI ASV scanning is a quarterly external vulnerability assessment of internet-facing systems in scope for PCI DSS, conducted by a vendor approved by the PCI Security Standards Council. It is a mandatory requirement for businesses that store, process, or transmit cardholder data, and must be run at least once every ninety days and after any significant change to the cardholder data environment.
2. What is the difference between ASV scanning and penetration testing?
ASV scanning checks internet-facing systems for known vulnerabilities from an external perspective. Penetration testing actively attempts to exploit those vulnerabilities to determine whether defences hold. Both are separate requirements under PCI DSS. The ASV scan satisfies Requirement 11.3, while the penetration test satisfies Requirement 11.4. They are not interchangeable.
3. What happens if an ASV scan fails?
A failing scan is not immediately a compliance breach. The organisation has the quarter to remediate identified vulnerabilities and run a passing rescan before the period closes. The QSA will require evidence of the initial scan, documented remediation, and a passing rescan. Failing to close out findings with a verified rescan leaves an open gap in the compliance record.
4. Who needs PCI ASV scanning in New Zealand and Australia?
Any business that stores, processes, or transmits cardholder data is subject to PCI DSS and the ASV scanning requirement, regardless of transaction volume. This includes payment platforms, fintech companies, ecommerce businesses, SaaS platforms with payment integrations, and any organisation that handles card data on behalf of clients.
5. Why is scope maintenance the most common PCI ASV failure?
Most PCI ASV failures occur not because organisations fail to run scans but because the scope of those scans no longer reflects the actual infrastructure. As businesses add cloud services, new domains, subdomains, and third-party integrations, each new component connected to the cardholder data environment should be included in the scan scope. Without regular scope reviews, the scans cover a snapshot of a previous state rather than the current attack surface.
6. Does Capture The Bug serve payment businesses in Fiji and the broader Pacific region?
Yes. Capture The Bug works with payment businesses and fintech companies across New Zealand, Australia, Fiji, and the broader Pacific region, providing CREST-certified penetration testing and compliance documentation aligned to PCI DSS requirements across all target markets.
