Case Study: PCI DSS QSA Consultancy

Case Study: PCI DSS QSA Consultancy

PCI DSS compliance can be difficult to navigate when card payments are accepted through several channels and parts of the payment journey pass through customer-controlled systems. Before an organisation can select a Self-Assessment Questionnaire (SAQ), they need a defensible understanding of how payment account data travels through their systems, which systems can affect their security, and what evidence its acquirer expects.

This case study outlines a PCI DSS Qualified Security Assessor (QSA) consultancy engagement delivered by ProCheckUp for a mid-sized UK business-to-business customer. The engagement moved the customer from uncertainty about its PCI DSS scope to a defined evidence pathway and identified an architectural change that could materially reduce their future compliance burden.

Overview

The customer approached ProCheckUp after a payment processor requested attestation of annual PCI compliance and a separate internal request was made for evidence that could support secure payment processing on the customer’s website.

The customer accepted tens of thousands of card payments each year through three routes: telephone-assisted payments, a separate payment terminal and an online payment journey. The online and assisted-payment processes included customer-controlled forms, OCR-assisted handling, an e-commerce integration and remote home access by authorised staff before payment information was passed to third-party services for processing.

The immediate objective was to establish the correct PCI DSS scope, clarify the customer’s external validation obligations, identify the most defensible SAQ route and define the work required before any attestation of compliance could be made.

Discovery showed that the central question was not simply whether the customer accepted card payments. It was where payment account data travelled and which customer-managed systems participated in that journey.

Engagement at a glance

• - Three payment channels assessed as one connected payment estate
• - Customer-controlled forms, OCR-assisted processing and an e-commerce interface mapped
• - Remote staff access and temporary data persistence considered within scope
• - Merchant validation instructions sent by the acquirer for formal confirmation
• - Broad SAQ D for Merchants identified as the preliminary route for the existing architecture
• - Payment processor-hosted payment capture recommended as the strategic scope-reduction option

Challenge

The customer’s payment environment was more complex than a simple outsourced-payment model. Three separate channels operated alongside customer-managed interfaces and integrations, creating several points at which payment data could be entered, processed, transmitted, temporarily retained or accessed.

The payment processor’s request did not state the customer’s formal merchant validation level, reporting route, deadline or applicable evidence requirements. Without written instructions from the acquirer or other entity receiving the compliance evidence, the customer could not safely infer which SAQ or scanning obligations applied.

The customer also did not have an authoritative data-flow diagram. This made it difficult to demonstrate:

• - Which data elements entered each payment channel
• - Which systems stored, processed or transmitted payment account data
• - Which systems could affect the security of the payment process
• - Which staff and remote endpoints could access payment-related interfaces
• - How long information persisted and how deletion was verified
• - Where responsibility transferred to each third-party provider

The customer initially described its model as processing cardholder data without storing it. The discovery exercise identified that some information could persist temporarily within customer-controlled workflows and that an authorisation reference was retained in the customer relationship management system. These details required field-by-field classification and evidence rather than a general assumption that no storage occurred.

The combination of customer-controlled capture, multiple integrations, remote access and incomplete scoping evidence made a short-form SAQ difficult to justify. The architecture appeared more consistent with a broad SAQ D for Merchants assessment unless and until the payment journey was simplified and the relevant eligibility criteria could be demonstrated.

Requirements

The QSA consultancy engagement was structured to give the customer a defensible basis for its next compliance decision. The agreed requirements were to:

• - Map the telephone, terminal and online payment channels from data entry to third-party processing
• - Identify every customer-controlled form, interface, application, endpoint and integration involved in the payment journey
• - Determine which payment account data elements were stored, processed, transmitted or temporarily retained
• - Clarify the effect of remote staff access on the cardholder data environment and supporting controls
• - Direct the customer to obtain formal validation and submission instructions from its acquirer
• - Review the customer’s previously completed PCI questionnaire against the architecture established during discovery
• - Assess preliminary SAQ eligibility without treating questionnaire selection as a substitute for scoping
• - Evaluate whether provider-hosted payment redirection could reduce direct customer contact with card data
• - Recommend the evidence needed for future assessment, including an accurate payment account data-flow diagram

The final output also needed to distinguish consultancy guidance from formal attestation. The engagement was intended to define the pathway to compliance; it did not, by itself, certify or attest the customer as PCI DSS compliant.

Solution

ProCheckUp applied a QSA-led discovery and scoping methodology that treated the payment process as a system to be understood rather than a questionnaire to be completed against assumptions.

The engagement followed four stages:

• 1. Discover: structured workshops mapped payment channels, interfaces, users, remote access, third parties, hand-off points and retention assumptions.
• 2. Classify: each relevant component was assessed for whether it stored, processed, transmitted, could affect or could provide access to payment account data.
• 3. Decide: the architecture was compared with SAQ eligibility criteria while formal merchant validation instructions were referred to the acquirer or compliance-requesting entity.
• 4. Simplify: a provider-hosted redirect, secure payment link or equivalent offsite capture model was proposed to remove direct account-data capture from customer-managed forms and integrations.

ProCheckUp also reviewed the previously completed PCI questionnaire against the newly mapped architecture. This was important because a prior questionnaire can create false confidence when its answers are based on an incomplete view of the payment flow. Any conflicting or unsupported assumptions needed to be corrected before the customer relied on that document with another stakeholder.

The preliminary QSA view was that the existing architecture most closely aligned with a broad SAQ D for Merchants route because customer-controlled systems participated directly in the payment-data journey and the environment did not clearly meet the eligibility criteria for a narrower SAQ.

This was not presented as an irreversible conclusion. The consultancy instead identified the evidence needed to finalise the position and showed how a redesigned, provider-hosted payment journey could materially change the customer’s future scope.

Standards context: PCI DSS v4.0.1 includes the maintenance of accurate account-data flow diagrams within Requirement 1.2.4 and annual confirmation of PCI DSS scope within Requirement 12.5.2. Merchants should confirm that they meet every eligibility criterion for a particular SAQ and should obtain validation instructions from the entity to which the assessment will be submitted. Further information is available from the PCI Security Standards Council document library.

Findings and Recommendations

The consultancy findings described gaps in scope, architecture and evidence rather than penetration-test vulnerability severities. Each finding shaped the customer’s compliance pathway.

Merchant validation instructions were not formally confirmed

The payment processor had requested annual compliance confirmation but had not provided the customer with a complete statement of its merchant validation level, reporting format, deadlines, SAQ eligibility expectations or any Approved Scanning Vendor (ASV) obligations.

Merchant validation requirements and SAQ eligibility are related but separate questions. Neither should be inferred from a processor email alone.

Recommendation: obtain written instructions from the acquirer or other entity receiving the compliance evidence and retain those instructions within the annual PCI DSS evidence pack.

The payment architecture brought customer-controlled systems into scope

Payment information passed through customer-controlled forms, OCR-assisted handling and an e-commerce interface before being transferred to third-party payment services. The use of third parties did not automatically remove the customer’s systems from scope because those systems captured, relayed or could affect the security of payment data.

Recommendation: treat the complete integrated payment journey as the provisional scope until a QSA-supported redesign and evidence review demonstrate that particular components can be excluded.

Remote payment access expanded the control boundary

Authorised home-based staff accessed a customer-controlled interface involved in payment processing. This brought remote authentication, endpoint security, access restriction, monitoring and support processes into the assessment.

Recommendation: minimise remote access, enforce strong multi-factor authentication, use hardened and managed endpoints, restrict network paths, monitor access and document the business need for each role.

No authoritative account-data flow diagram existed

The customer did not have a current, owner-approved diagram showing account-data entry, processing, transmission, temporary persistence, third-party transfer, remote access and final deletion across all three channels.

Without this record, the customer could not consistently prove which systems were in scope or maintain the scope decision after technical or business change.

Recommendation: create an end-to-end account-data flow diagram and align it with network diagrams, system inventories, user-access records, retention schedules and third-party responsibility documentation.

Retention claims required field-level evidence

The initial statement that payment information was processed but not stored needed reconciliation with temporary persistence in customer-controlled workflows. The authorisation reference retained in the CRM also required classification to confirm exactly what it contained and why it was needed.

Temporary persistence remains relevant to PCI DSS scope. A retained authorisation reference is not automatically equivalent to a primary account number or sensitive authentication data, but its content, purpose and retention must be understood.

Recommendation: inventory every retained field, prevent full card numbers and sensitive authentication data from entering downstream records, set the minimum necessary retention period, and verify that deletion operates as documented.

The previous questionnaire needed reconciliation

The customer had already completed a PCI questionnaire before the detailed payment architecture was established. Its answers therefore needed comparison with the newly mapped environment so that the organisation did not maintain contradictory compliance positions for different stakeholders.

Recommendation: record the assumptions behind each answer, correct unsupported responses and retain a change log linking questionnaire statements to current evidence.

Three payment channels increased recurring assessment burden

The telephone, terminal and online routes each introduced different technologies, users, providers and evidence requirements. Their combined operation increased the number of systems and responsibilities that needed to be understood and maintained.

Recommendation: reduce unnecessary variation where practical, standardise provider responsibilities and use a single evidence model covering all payment channels.

Provider-hosted capture offered the strongest scope-reduction opportunity

A fully hosted redirect, secure payment link or equivalent provider-controlled capture model could prevent customer-managed forms and integrations from receiving payment account data directly.

Reducing the number of systems that touch account data can reduce attack surface, control burden, evidence complexity and the likelihood that future application changes unexpectedly expand scope.

Recommendation: design the target architecture with the payment provider and QSA, validate that customer pages cannot affect the security of the payment capture mechanism beyond the accepted model, and reassess SAQ eligibility after implementation.

Current and Target Payment Models

Current model

The current architecture combined three payment routes with customer-controlled forms, assisted processing, an e-commerce integration and remote staff access. Although third parties completed the payment processing, customer systems still participated in the payment-data journey.

• - Broader provisional cardholder data environment
• - More systems, users and interfaces requiring evidence
• - Greater retention and deletion complexity
• - Preliminary alignment with SAQ D for Merchants
• - Higher recurring cost of maintaining scope and assurance

Target model

Under the recommended model, cardholders or authorised staff would be directed to a payment page controlled by a PCI-compliant provider. Customer systems would receive only the minimum transaction status or reference needed for business processing.

• - Customer-managed systems no longer capture full payment account data directly
• - Clearer separation of customer and provider responsibilities
• - Reduced opportunity for temporary payment-data persistence
• - Simpler data-flow and evidence requirements
• - SAQ eligibility reassessed against the implemented design

Architecture change does not automatically guarantee a particular SAQ. The implemented solution, all eligibility criteria, the customer’s responsibilities and the acquirer’s validation instructions must still be confirmed.

Prioritised Compliance Roadmap

Immediate actions

• - Obtain formal validation and submission instructions from the acquirer
• - Appoint an accountable owner for the PCI DSS compliance programme
• - Produce and approve an end-to-end account-data flow diagram
• - Identify all systems, users, endpoints, integrations and third parties in the provisional scope
• - Classify every payment-related data element and verify current deletion behaviour
• - Reconcile the previous PCI questionnaire with the discovered architecture

Near-term actions

• - Design a provider-hosted redirect or secure-payment-link model
• - Reduce and tightly control remote access to payment-processing interfaces
• - Document third-party service responsibilities and obtain supporting compliance evidence
• - Remove unnecessary payment data from customer-managed applications and logs
• - Confirm whether ASV scanning is required for the validated environment
• - Determine the correct SAQ route once architecture and acquirer requirements are confirmed

Ongoing assurance

• - Complete the applicable SAQ and Attestation of Compliance through the agreed validation route
• - Maintain current data-flow diagrams, inventories, access records and retention evidence
• - Confirm PCI DSS scope at least annually and after significant change
• - Include payment architecture review within change management and supplier governance
• - Undertake ASV scanning, penetration testing and segmentation testing where required by the validated scope
• - Reassess the environment after implementing the provider-hosted model

Outcome

The engagement replaced an informal assumption of compliance with a structured, evidence-based view of the customer’s payment architecture.

The customer gained a clear understanding of why its existing payment flows could not be assessed solely by reference to a prior questionnaire. It also understood the difference between merchant validation instructions, architectural SAQ eligibility and the evidence required to support either decision.

ProCheckUp established a practical sequence of next steps: obtain formal acquirer instructions, create the missing data-flow and inventory evidence, reconcile retention claims, correct the prior questionnaire and treat the existing environment as broadly scoped until a defensible alternative could be implemented.

The most important strategic outcome was the recommendation to move payment account data capture to a provider-hosted journey. This gave the customer a credible route to reduce direct contact with card data rather than continually adding controls around a broad and integrated environment.

The consultancy did not, by itself, attest the customer as PCI DSS compliant. It defined the evidence and architectural work needed for the customer to complete the appropriate validation accurately and to make any future compliance statement on a defensible basis.

The Core Compliance Lesson

PCI DSS scope is an architectural property. The shortest questionnaire is not selected by preference; it becomes defensible only when the payment design, data flows, responsibilities and evidence satisfy every relevant eligibility criterion.

A third-party processor does not automatically remove customer systems from scope when those systems capture, transmit or influence payment account data.

The correct question is not simply:

“Which PCI DSS questionnaire would we prefer to complete?”

It is:

“Which systems genuinely touch or can affect payment account data, what evidence proves that boundary, and can the architecture be changed so fewer systems need to be trusted?”

How ProCheckUp Helps

ProCheckUp’s PCI DSS QSA consultancy services help organisations understand, reduce and validate their payment-security scope. Support can include:

• - Payment-channel and account-data flow discovery
• - PCI DSS scoping and SAQ eligibility review
• - Gap analysis and prioritised remediation planning
• - Provider-hosted payment and scope-reduction architecture advice
• - Third-party responsibility and evidence review
• - PCI DSS QSA assessment and attestation support
• - PCI DSS ASV scanning
• - Segmentation testing and web application penetration testing
• - Post-remediation verification and ongoing compliance governance

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

Conclusion

This engagement demonstrated why PCI DSS compliance should begin with payment architecture and evidence rather than questionnaire selection.

By mapping every payment channel, confirming external validation instructions, documenting the complete account-data lifecycle and moving card capture to a provider-hosted service, the customer can reduce uncertainty, lower recurring compliance burden and build a more sustainable payment-security programme.

To discuss PCI DSS scope, SAQ eligibility, payment-architecture simplification or formal QSA support, contact ProCheckUp.