CASE STUDY PCI DSS ASV

Case Study: PCI DSS ASV Scan

Quarterly external vulnerability scanning is an important part of PCI DSS assurance for internet-facing systems that can affect payment account data. A useful ASV engagement must do more than run an automated scanner: it must establish the correct external scope, account for edge services such as content-delivery networks and reverse proxies, validate material results, and confirm remediation through an independent rescan.

This case study outlines an Approved Scanning Vendor (ASV) assessment delivered by ProCheckUp for a security-sensitive UK public-sector organisation. The engagement covered externally accessible payment and online-service assets and progressed from two compliance-impacting findings to a verified passing rescan.

Overview

The customer commissioned ProCheckUp to perform a scheduled external vulnerability scan of public systems supporting an online service and payment journey. Testing was conducted remotely from documented UK source addresses using PCI SSC Approved Scanning Vendor methodology and without authentication.

A third-party edge platform sat in front of the origin infrastructure and performed filtering, proxying and Transport Layer Security (TLS) termination. The assessment therefore needed to determine what an unauthenticated internet user could observe at the public edge, how that behaviour related to the origin service and which configuration owner was responsible for remediation.

The customer also operated within security and data-handling expectations that were stricter than the baseline ASV framework. ProCheckUp treated the PCI scanning requirement and those additional customer controls as related but separate assurance questions.

Engagement at a glance

• - Scheduled unauthenticated scan of agreed internet-facing assets
• - Approved ASV methodology with consultant-led validation
• - Two findings prevented a passing result on the initial scan
• - Three contextual observations were recorded for hardening and scope clarity
• - UK-originating scan traffic and agreed UK handling of reports and artefacts
• - Focused remediation followed by an independently verified passing rescan

Challenge

The engagement combined three assurance challenges: meeting PCI DSS external scanning requirements, interpreting the security controls presented by a third-party edge service, and aligning delivery with the customer’s own supplier-security expectations.

PCI and customer-policy obligations

The ASV framework defines the external scope, approved scanning process, passing criteria and rescan evidence. The customer separately required confidence in where scanning traffic originated, where assessment artefacts were handled and what personnel-access model was acceptable. These controls needed to be documented without incorrectly presenting them as universal PCI DSS requirements.

The edge service changed the visible perimeter

The public endpoint was protected by a content-delivery and reverse-proxy layer that terminated TLS before traffic reached the origin. This was a positive security control, but it also meant that protocol support, filtering behaviour and some externally visible weaknesses were properties of the edge configuration rather than the origin server alone.

Accuracy without operational disruption

Firewalls, intrusion-prevention controls, rate limits, load balancers and proxy services can interfere with vulnerability scanning or create misleading results. ProCheckUp therefore coordinated source-address whitelisting, used a controlled scan profile and manually reviewed material findings while keeping the activity suitable for a live public service.

Testing boundary

The engagement replicated the exposure visible to an unauthenticated user on the public internet. It was not an application penetration test and did not attempt to exploit identified weaknesses.

Included:

• - Approved external vulnerability scanning of agreed public assets
• - Service, protocol, TLS and known-vulnerability detection
• - Review of externally visible CDN and reverse-proxy behaviour
• - Manual validation, compliance interpretation, reporting and rescan

Excluded:

• - Credential attacks, application brute-force or authenticated testing
• - Exploitation, destructive activity or access to customer data
• - Internal infrastructure, private administration interfaces or source-code review
• - Assurance beyond the agreed ASV scope and issued scan evidence

Requirements

The ASV assessment was structured around the following technical and operational requirements:

• - Confirm the public domains and addresses supporting the payment journey and exclude unrelated assets
• - Determine how the CDN, reverse proxy and TLS termination point affected external scope and scan interpretation
• - Conduct scanning using a PCI SSC Approved Scanning Vendor process
• - Whitelist documented ProCheckUp UK source ranges so perimeter controls did not obscure the assessment
• - Perform controlled, unauthenticated external scanning without brute-force testing, exploitation or customer credentials
• - Keep scan traffic, outputs, reports and assessment artefacts within the agreed UK delivery environment
• - Clarify the policy or contractual basis of any personnel-location or vetting expectations
• - Provide a clear compliance determination, remediation priorities and a verification rescan within the agreed service window

No customer certificates, MFA tokens, jump boxes or client-supplied laptops were required because the assessment evaluated the public attack surface visible without authentication.

Solution

ProCheckUp combined approved ASV scanning with consultant-led scoping, validation and interpretation. This turned automated output into a defensible assessment of the customer’s externally exposed payment environment.

The engagement followed four stages:

• 1. Define: confirm the payment-facing assets, edge services, exclusions, source ranges and customer assurance constraints.
• 2. Prepare: coordinate whitelisting and scan windows, document the unauthenticated testing boundary and confirm the agreed UK handling model.
• 3. Scan and validate: assess exposed services, TLS configurations, public components and known vulnerabilities, then manually investigate findings that could affect the result.
• 4. Remediate and rescan: translate failing findings into focused configuration or component changes and repeat the relevant tests from the public internet.

The edge platform presented the encryption configuration and filtering behaviour that an external attacker would encounter. ProCheckUp therefore correlated scanner evidence with service context, vulnerability information and ASV passing criteria rather than treating every scanner observation as equally important.

This approach separated genuine failing conditions from lower-severity hardening notes and positive protocol observations. It gave the customer a short, practical remediation path rather than an undifferentiated list of technical output.

Standards context: PCI DSS v4.0.1 Requirement 11.3.2 requires external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor, with rescans used to confirm that failing vulnerabilities have been resolved. Customer-specific residency, personnel and supplier controls are additional contractual or policy requirements and should be confirmed explicitly. Current PCI DSS and ASV documents are available from the PCI Security Standards Council document library.

Vulnerabilities Identified

The initial scan identified two conditions that prevented a passing result and three contextual observations that remained relevant to perimeter hardening and future scope management.

Legacy TLS accepted at the proxy edge — compliance-impacting

The public endpoint accepted TLS 1.0 and TLS 1.1 because early protocol versions remained enabled on the third-party edge configuration. The same service also supported modern TLS, but the availability of TLS 1.2 or TLS 1.3 did not neutralise the risk created by retaining legacy options.

Recommendation: enforce a minimum TLS version of 1.2 at the externally exposed termination point, remove early protocol and unsuitable cipher options, document the approved edge baseline and verify the change with an external rescan.

Known-vulnerable JavaScript component — compliance-impacting

An outdated third-party JavaScript library was detected on a public-facing page. The ASV evidence did not prove an exploitable application path, but the known-vulnerable version affected the external scan result and demonstrated a gap in public component governance.

Recommendation: update or remove the component, confirm that the deployed production asset has changed, maintain an inventory of client-side dependencies and incorporate vulnerability checks into release management.

TCP timestamp information — low severity, pass with note

TCP timestamps were enabled on target systems. This could assist approximate uptime inference and remote operating-system fingerprinting, but it did not prevent a passing ASV result.

Recommendation: assess whether the feature is operationally required and disable it where the platform supports doing so without creating reliability or support issues.

CDN and reverse-proxy control detected — scope note

The edge service was a positive filtering control, but it also presented the public TLS configuration and could affect payment-facing traffic. Configuration ownership, termination points and responsibility for remediation therefore needed to be explicit.

Recommendation: record the edge service within the external architecture and scan scope, assign a named configuration owner and reassess it after material provider or routing changes.

TLS 1.3 available — positive context

Modern TLS was already supported on the endpoint. This meant that remediation did not require introducing a new secure protocol; it required removing backward-compatible early TLS options.

Recommendation: retain modern protocol support, monitor the minimum-version policy for configuration drift and independently verify the externally visible result after change.

From Initial Failure to Passing Rescan

Initial scan

Legacy TLS support and the known-vulnerable public component prevented a passing ASV result. Lower-severity observations were reported separately so that the customer could prioritise compliance blockers without losing useful hardening context.

Focused remediation

• - Raised the minimum TLS version at the public edge
• - Removed legacy protocol options and reviewed the exposed cipher configuration
• - Updated the outdated JavaScript dependency on the public-facing page
• - Documented the role and ownership of the CDN and reverse-proxy layer

Verification rescan

ProCheckUp repeated the affected external tests and confirmed that both failing conditions had been resolved. The final report provided a passing ASV result suitable for submission through the customer’s agreed PCI DSS evidence process.

An independent rescan was important because configuration screenshots or change records show what administrators intended to change; the rescan demonstrates what the public internet actually exposes after remediation.

Operational and Data-Handling Assurance

The PCI DSS ASV requirement and the customer’s additional delivery controls addressed different risks. ProCheckUp documented each one so that the operating model could be justified without assumption.

PCI DSS and ASV assurance covered:

• - Approved vendor status and ASV methodology
• - Agreed external scope and unauthenticated scanning
• - Passing criteria, reporting, remediation and rescan evidence

Additional customer controls covered:

• - Documented UK source addresses for scan traffic
• - Agreed UK handling of scan output, reports and artefacts
• - Clarification of acceptable personnel-access and delivery arrangements
• - Alignment with the customer’s supplier-security and data-handling policy

Rather than infer a universal rule from the customer’s public-sector status, ProCheckUp sought the specific policy or contractual basis for each additional requirement and aligned the delivery model to the control that genuinely applied.

Outcome

The engagement gave the customer a clear and evidence-based view of its external PCI DSS scan status. It also resolved a recurring scoping question around an edge service that protected the origin systems while simultaneously controlling the encryption behaviour presented to the public internet.

The technical team disabled legacy TLS at the relevant edge configuration, updated the outdated JavaScript component and completed a successful rescan. The final result distinguished verified remediation from assumptions and provided suitable evidence for the customer’s compliance-enforcing party.

The assessment also established a repeatable operating model for UK-originating scan traffic, agreed handling of reports and artefacts, and explicit treatment of CDN, reverse-proxy and TLS termination responsibilities.

Important compliance boundary: a passing ASV scan demonstrates that the tested external assets met the ASV passing criteria at the time of scanning. It is one component of PCI DSS validation and does not, by itself, attest the organisation’s complete PCI DSS compliance or prove that the wider application is secure against authenticated, business-logic or internal attacks.

Maintaining a Predictable Quarterly Scan

The successful rescan closed the immediate issue. The following controls reduce the likelihood that the same class of failure will return through platform, application or supplier changes:

• - Record and monitor an approved minimum TLS and cipher baseline at every public termination point
• - Maintain an inventory of public JavaScript and other third-party components
• - Include externally visible edge configuration within change management and supplier governance
• - Reconfirm domains, providers, proxies and termination points after material architecture changes
• - Schedule quarterly scans early enough to allow remediation and rescan before evidence deadlines
• - Use web application penetration testing where authentication, authorisation and business logic require deeper assessment

The Core Assurance Lesson

The public edge is not merely a protective layer. When a content-delivery network or reverse proxy terminates payment-facing traffic, its configuration becomes part of the externally visible security boundary and can determine the ASV result.

A finding does not need to demonstrate active exploitation to prevent a passing scan. Conversely, a passing ASV result does not prove that every application or internal security risk has been removed.

The correct question is not simply:

“Did the scanner finish without interruption?”

It is:

“Did we scan the complete external boundary, correctly interpret what each layer exposed, remediate every failing condition and independently prove the result from the internet?”

How ProCheckUp Helps

ProCheckUp’s PCI DSS ASV service helps organisations define their external scope, obtain accurate quarterly scan evidence and move efficiently from failing findings to verified remediation. Support can include:

• - PCI DSS ASV scanning and quarterly scheduling
• - External scope review and asset reconciliation
• - CDN, reverse-proxy and TLS termination analysis
• - Source-address coordination and scan-readiness checks
• - Manual validation and false-positive investigation
• - Prioritised remediation guidance
• - Verification rescans and final ASV reporting
• - PCI DSS QSA consultancy and wider compliance support
• - Vulnerability assessment and web application penetration testing

Related services include PCI DSS ASV scanning, PCI DSS QSA consultancy, vulnerability assessment and web application penetration testing.

Conclusion

This engagement demonstrated how accurate scope definition, careful interpretation of edge-layer behaviour and prompt verification can turn a failed quarterly scan into defensible passing evidence.

By maintaining secure public TLS baselines, tracking exposed dependencies, documenting edge-service ownership and allowing sufficient time for remediation and rescan, organisations can make quarterly ASV assurance more predictable and reduce the risk of last-minute compliance failure.

To discuss PCI DSS ASV scanning, remediation support or a wider payment-security assessment, contact ProCheckUp.