Scoping a Hosted Payment Page Store That Also Keeps PAN
Northwind Outfitters runs a $180 million online store. Last quarter it replaced its self-hosted payment form with a hosted payment page from its acquirer, embedded as an iframe on checkout.northwind.com. The surrounding page is served by Northwind's own Node.js application on AWS - an Application Load Balancer with WAF, 90 EC2 instances in an autoscaling group, and Aurora MySQL - and Northwind's JavaScript sets the iframe height and passes the order total into it. Separately, the call-centre team keeps full PAN plus expiry for 90 days in an S3 bucket so agents can process phone returns, and the analytics team queries a read replica of the orders database in which a database view replaces the PAN column with a fixed string of X characters; the underlying column is unchanged. About 12 million card records sit in Aurora. The QSA has asked for the scope definition and the SAQ the company should use. Marketing argues that the iframe means “the acquirer handles everything”.
1. Which SAQ applies, and what facts drive that choice? Show the reasoning rather than naming a form.
Read the worked answer
Two independent facts decide this, and the second one overrides the first.
The iframe. SAQ A is only available when the merchant's website cannot affect the security of the payment transaction - typically a full redirect, or an iframe so isolated that no merchant script can read or modify the payment form. Here Northwind's own JavaScript runs on the checkout page and passes the order total into the frame. If that script can influence what the consumer sees or what is submitted, the merchant site is in scope and the merchant moves to SAQ A-EP or higher. Even with a genuinely clean iframe, the payment page remains subject to Requirement 6.4.3 (inventory, justification and integrity controls for payment page scripts) and 11.6.1 (change/tamper detection evaluated at least every seven days).
Storage. SAQ A and A-EP both require that the merchant does not store, process or transmit cardholder data. The 90-day S3 bucket holds full PAN. The analytics view is cosmetic: the PAN column still exists underneath, so the replica stores cardholder data. Northwind is therefore ineligible for either short-form SAQ and needs SAQ D or a ROC.
Recommendation: eliminate the S3 PAN store (acquirer token plus last four), make analytics masking irreversible at write time, then re-test short-form eligibility. Until that work is complete, declare the broader SAQ D scope rather than arguing about the iframe.
2. The call-centre S3 bucket: what does it do to scope, and what would you actually recommend given the returns process needs the data?
Read the worked answer
Storing PAN for 90 days is permitted, but it must be justified, limited and protected. Requirement 3.1/3.2.1 requires a documented retention and disposal policy with a business justification and a defined retention period, and the data must be rendered unreadable (3.5.1) and protected in transit (4.2.1) and at rest.
The scoping cost is severe: the bucket, its IAM roles, the call-centre workstations and the network path between them, the KMS keys, the logging and the backup copies all become CDE. That likely converts a small merchant into a full ROC.
A defensible design keeps the business outcome and drops the PAN:
- Replace the stored PAN with the acquirer's token plus last four and expiry month, which is enough for agent-assisted returns and most chargeback work.
- If a short window of full PAN is genuinely unavoidable, cut retention to the minimum the process needs (often 7–14 days), encrypt with a customer-managed key restricted to a single role, restrict bucket access by VPC endpoint and role, enable access logging and Object Lock, and automate deletion with evidence.
- Document the justification and the review date; the assessor will ask why 90 days rather than 14.
Removing this store is also the cheapest route back to a short-form SAQ, so it pays twice.
3. Does the analytics read replica pull the analytics VPC into scope? Explain what would change your answer.
Read the worked answer
It depends entirely on whether the PAN in the replica is recoverable.
If masking is irreversible at write time - the replica receives truncated or one-way tokenised values, and no process or credential can reconstruct the PAN from it - the replica is not storing cardholder data. The replica host and the analytics users are then out of scope for storage, although the masking job, the replication credentials and the key material used for tokenisation remain in scope because they can affect CDE data. The assessor will want to see the transformation logic, a sample of rows, and evidence that the source column cannot be read from the replica.
If masking is a view over an intact column - which is the situation described - the replica stores PAN. The analytics VPC, its subnets, its users and their endpoints, the query tooling and the network path all become connected-to-CDE and in scope, with all the associated requirements (7.2 least privilege and query restrictions, 8.4 MFA, 10.2 logging, 11.3 scanning, 6.3 patching).
What would change my answer: proof that the transform runs before storage and cannot be reversed, plus evidence that no role can select the raw column. A view with a static X string over live PAN is not truncation - truncation must make the original unrecoverable.