Planned

PCI DSS Compliance & Audit Readiness

Demonstrate security control assessments, evidence collection, compliance mapping, and remediation tracking.

View on GitHubDocumentation · Not configured

Case study introduction

FuturePays is a fictional e-commerce retailer that sells products online. Customers check out on the FuturePays website and are redirected to a third-party hosted payment page, so card details are entered with the payment provider rather than on FuturePays systems.

This case study plans a PCI DSS v4.0.1 assessment for that hosted-payment architecture: mapping the payment flow and trust boundaries, scoping the environment, planning control tests and evidence collection, and documenting hypothetical findings with remediation plans.

Project phases

Phase 1
Payment architecture and trust boundaries
Phase 2
Preliminary PCI DSS scope assessment
Phase 3
Control assessment planning
Phase 4
Audit evidence collection planning
Phase 5
Hypothetical findings and remediation planning

The documentation is complete as a fictional educational demonstration. No real PCI DSS assessment, compliance validation or technical testing has been performed, and FuturePays is not PCI DSS certified or compliant.

01
Assess
Control assessments
02
Collect
Evidence collection
03
Map
Compliance mapping
04
Remediate
Remediation tracking

Planned workflow · Illustrative diagram, not evidence

Payment Data Flow Diagram

FuturePays · fictional e-commerce case study · PCI DSS v4.0.1

In PCI Scope · merchant systemsOut of Scope · segmented corporate systemsProvider systems are external, not exempt from PCI DSS

01 / Payment journey

External customer
Customer
Shops online using a web browser.
Browsing only
Customer opens the store
In PCI Scope · merchant
FuturePays Web Store
The customer clicks checkout and is redirected to the provider.
Checkout request · no card entry
Checkout redirect to third-party page
Provider PCI environment · external
Hosted Payment Page / Payment Service Provider
Cardholder data is entered here, on a page hosted by a third-party payment provider—not FuturePays.
Cardholder data entered here
Secure payment request
Provider PCI environment · external
Payment Gateway / Processor
Receives the payment request and sends it for processing.
Payment processing
Authorization request
External payment network
Card Network / Issuer Response
The card network and issuing bank return approval or decline through the provider.
Approval or decline
Provider relays the payment result
In PCI Scope · assumed merchant boundary
FuturePays Order System
Receives only payment results. Stores order status and transaction result—not full card numbers.
Payment results only · no full card numbers

Illustrative portfolio modelSimplified fictional portfolio diagram—not a real production environment, a validated scope assessment or evidence of compliance. Arrows show the logical sequence; the provider relays the issuer response to FuturePays.

Business Scenario

FuturePays is a fictional online retailer. Customers shop on its web store, then leave the store to pay on a third-party hosted payment page. FuturePays uses the returned result to update the order.

What the Diagram Shows

The six steps follow checkout, card entry, processing and the approval or decline response. Cardholder data is entered at the provider; the order system receives a payment result and transaction reference, not full card numbers.

PCI Scope Notes

For this exercise, the store, order system and systems that can affect their security are treated as in scope. Outsourcing payment entry does not remove merchant PCI obligations. Corporate systems are out of scope only if separation is verified and they cannot affect payment security. Actual scope and the applicable assessment would need validation.

Key Assumptions

Checkout uses a full redirect to a PCI DSS-compliant provider. FuturePays does not receive or store full card numbers or security codes. Provider responses are authenticated, admin access is restricted, logs exclude cardholder data, and corporate systems are isolated. These are proposed assumptions, not implemented controls.

Explore the Deliverables

Each document opens on GitHub in a new tab.

Version 1.0 — DraftPreliminary / Requires Validation

FuturePays — PCI DSS v4.0.1 Scope Assessment

Document Version:: 1.0 — Draft
Assessment Status:: Preliminary / Requires Validation
Project Type:: Fictional educational demonstration
Prepared by:: Jamal Davison

In the print window, choose “Save as PDF” as the destination.

01Business overview

FuturePays is a fictional e-commerce retailer. Customers purchase products through the FuturePays website and are redirected to a third-party hosted payment page to enter their payment information. The fictional FuturePays order system stores order details, a transaction reference, and payment status, not full card numbers.

02System inventory

Scope classification legend

Cardholder Data Environment / Third-party payment processing environment
Connected-to or security-impacting
Potentially out of scope — requires validation
External customer or untrusted environment
Requires further investigation

System	Business Function	Account Data Handling	Connectivity or Security Impact	Preliminary Scope Classification	Reason	Evidence Needed
01 Customer browserCustomer-owned	Customer shops and is redirected to checkout.	Customer enters card data into the provider's hosted page within the browser.	Untrusted endpoint outside merchant control.	External customer or untrusted environment	Customer-owned device; not managed by FuturePays.	None required from merchant; documented in data flow.
02 FuturePays e-commerce web serverMerchant-managed	Hosts the store and initiates the payment redirect.	No card entry assumed; controls the redirect to the payment page.	Compromise could alter the redirect and send customers to a malicious page.	Connected-to or security-impacting	Merchant website controlling payment redirects can have applicable PCI DSS requirements.	Redirect implementation review, page-script inventory, change records.
03 Third-party hosted payment pageThird-party managed	Collects cardholder data on the provider's page.	Stores, processes or transmits cardholder data (provider-managed).	Primary point of card data entry.	Cardholder Data Environment / Third-party payment processing environment	Handles cardholder data; managed in the provider's PCI environment.	Provider Attestation of Compliance (AOC); responsibility matrix.
04 Third-party payment gateway and processorThird-party managed	Processes and authorizes payments.	Processes and transmits cardholder data (provider-managed).	Provider-side payment processing.	Cardholder Data Environment / Third-party payment processing environment	Third-party payment processing environment, not merchant-managed.	Provider AOC; contract and responsibility matrix.
05 FuturePays application serverMerchant-managed	Runs store logic and receives payment results.	Assumed to receive transaction reference and status only.	Connects the web server, provider callbacks and order database.	Connected-to or security-impacting	Connectivity to payment-related systems may affect payment security.	Architecture diagram, integration/callback review, data discovery.
06 FuturePays order databaseMerchant-managed	Stores orders, transaction references and payment status.	Assumed: no full card numbers stored.	Connected to the application server.	Requires further investigation	No-storage assumption must be confirmed by data discovery before classification.	Database schema review, data discovery scan results.
07 Administrator workstationsMerchant-managed	Staff manage the store and payment-related systems.	No card data expected.	Administrative access could change the website or redirect.	Connected-to or security-impacting	Systems with administrative access can impact security of in-scope systems.	Access lists, MFA configuration, endpoint hardening records.
08 Identity and access management systemMerchant-managed	Authenticates and authorizes administrators.	No card data expected.	Controls who can access payment-related systems.	Connected-to or security-impacting	Security services supporting in-scope systems are security-impacting.	Role assignments, MFA policy, access review records.
09 Security logging and monitoringMerchant-managed	Collects and reviews security events.	Logs expected to exclude cardholder data.	Supports detection for in-scope systems.	Connected-to or security-impacting	Security-impacting service; log content must be confirmed.	Log source list, sample log review, retention settings.
10 Corporate office networkMerchant-managed	General office systems and users.	No card data expected.	Unknown until segmentation is tested.	Potentially out of scope — requires validation	Can only be excluded after segmentation is verified.	Firewall rules, segmentation test results, network diagram.

Scroll the table sideways to see all columns.

No system is treated as out of scope simply because it does not store card data.

03Scope assessment rules

Systems that store, process or transmit cardholder data must be evaluated as part of the Cardholder Data Environment (CDE).
Systems that connect to, or could affect the security of, the CDE can also be in scope.
Merchant websites that control the redirect to a payment page may have applicable PCI DSS requirements.
Network segmentation must be verified before any system is excluded based on isolation.
Outsourcing payment processing does not remove all of the merchant's PCI DSS responsibilities.
SAQ eligibility cannot be determined from this diagram alone.

04Trust boundaries

These boundaries correspond to the payment data flow diagram shown above on this page.

External customer environment

The customer's browser and internet connection. Untrusted and outside FuturePays control.

Merchant environment

FuturePays web server, application server, order database, administrator workstations, identity system and security logging. Managed by FuturePays.

Third-party payment environment

The hosted payment page, gateway and processor. Managed by the payment provider, where cardholder data is entered and processed.

Possible corporate network separation

Corporate office systems are assumed to be separated by a firewall. This separation is unverified until segmentation is tested.

05Evidence checklist

Current payment data flow diagramPending Verification
System inventoryPending Verification
Network architecture and connectivityPlanned
Payment redirect implementationPlanned
Firewall and segmentation configurationPlanned
Administrative access permissionsPlanned
Payment provider Attestation of CompliancePlanned
Service provider responsibility matrixPlanned
Confirmation of card data storage and transmissionPlanned
Applicable assessment and SAQ eligibility reviewPlanned

No evidence has been collected. Statuses reflect planned work only.

06Preliminary conclusion

Based on the fictional design assumptions, cardholder data appears to be entered and processed only within the third-party payment provider's environment. The FuturePays web server, application server, administrator workstations, identity system and security logging are proposed as connected-to or security-impacting, because they control the payment redirect or could affect the security of payment-related systems.

Key unknowns remain: whether the order database truly contains no cardholder data, whether the corporate network is effectively segmented, how the redirect is implemented and protected, and how responsibilities are divided with the provider.

Next steps are to collect the evidence listed above, confirm data storage through discovery, test segmentation, obtain the provider's Attestation of Compliance and responsibility matrix, and then review the applicable assessment type and SAQ eligibility.

This is a fictional, preliminary document. Scope has not been validated, no compliance status is claimed, and no SAQ type has been assigned.

01Overview

Demonstrate security control assessments, evidence collection, compliance mapping, and remediation tracking.