PCI DSS compliance: a practical guide

No to the first, yes to the second. Credit card compliance is the everyday name for what the card brands require of anyone handling card data, and PCI DSS is the standard behind it, so the two phrases mean the same thing in practice. It is not law. PCI DSS is enforced through your agreements with your acquirer and the card brands rather than by statute. In practice the distinction rarely helps you: non-compliance can mean fines passed down by your acquirer, higher transaction costs, or losing the ability to accept cards, and after a breach it affects your liability position significantly.

V4.0.1, published in June 2024. It is a clarification of v4.0 rather than a new set of obligations. The important date was 31 March 2025, when the future-dated requirements from v4.0, including 6.4.3 and 11.6.1, became mandatory.

These are the two client-side requirements and the newest part of the standard. 6.4.3 requires you to inventory and authorise every script on your payment pages and assure each one's integrity. 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorised changes to payment page content and HTTP headers, at least every seven days.

Yes, it depends on your merchant level and your acquirer. Level 1 merchants generally need a Report on Compliance from a Qualified Security Assessor. Lower levels can typically self-assess with a Self-Assessment Questionnaire, though an acquirer can require more. Ask your acquirer rather than inferring from transaction volume alone.

It varies enormously with scope, from a few thousand for a small SAQ A merchant to six figures for a Level 1 assessment with remediation. The client-side line item is usually one of the smaller ones. We break it down in PCI compliance cost.

No, though it reduces your scope substantially. Using a compliant provider means card data is handled by systems you do not run. Your own obligations do not disappear, and the client-side requirements are a good example: the page hosting your provider's iframe is still yours and still in scope.

It catches people out. SAQ A is for merchants who have fully outsourced payment handling and whose site cannot affect the payment transaction. SAQ A-EP is for ecommerce merchants who never receive card data but whose website can affect the security of the payment page, which is the case for most sites embedding a payment iframe or redirecting after collecting order details.

Annually as a baseline, with quarterly vulnerability scans by an Approved Scanning Vendor where applicable. Several v4.0 requirements also carry their own frequencies, and 11.6.1 is one: at least once every seven days, or a frequency justified by a targeted risk analysis under 12.3.1.

This is where it gets expensive. A forensic investigation determines compliance status at the time of the breach. Being found non-compliant typically means assessment fees, fines passed through your acquirer, card reissuance costs and a move to a stricter validation level, in addition to the direct costs of the incident.

No. Software produces controls and evidence; compliance is a judgement made across the whole standard by your assessor or by you on an SAQ. Be specific about what any tool covers: a client-side tool covers two requirements out of twelve families, and a GRC platform tracks evidence without producing the technical control itself.