PCI DSS Compliance and Cardholder Data Security

It depends on your merchant or service provider level, which the card brands and your acquiring bank set mainly by annual transaction volume. Most smaller merchants validate with a self-assessment questionnaire, and the SAQ type depends on how card data flows: a merchant that sends customers to a hosted payment page has far fewer questions than one whose own servers touch card numbers. Larger merchants and most service providers need a Report on Compliance completed by a Qualified Security Assessor, and some acquirers ask for QSA involvement even below that threshold. The first job in scoping is therefore to confirm your level in writing with your acquirer rather than guess it. We then pick the correct SAQ type or prepare you for the QSA, because answering the wrong SAQ is one of the most common reasons a submission is sent back.

Keep card data out of your own systems wherever you can. A hosted payment page, an iframe from a compliant payment provider, or tokenisation means your servers never see a card number, so most requirements fall to the provider instead. In India the RBI's card-on-file tokenisation rules already stop merchants storing card data, which removes a large part of the classic storage scope. Where some systems must handle card data, network segmentation separates them from the rest of the environment, but segmentation only reduces scope if it is tested and proven, not assumed. We trace every card data flow end to end, including call centres, logs, backups and support tools where numbers leak unnoticed, then recommend the design that leaves the smallest environment to secure. Less scope means fewer controls to implement, less evidence to produce and a shorter assessment.

Version 4.0 was the largest revision in a decade, and version 4.0.1, published in June 2024, clarified it without adding new requirements. The main changes are broader multi-factor authentication for access into the cardholder data environment, stronger password and authentication rules, a targeted risk analysis for how often certain controls run, protection of payment page scripts against tampering, and automated review of audit logs. It also added a customised approach, letting a mature organisation meet a requirement's objective in its own way if it can prove the result. Version 3.2.1 was retired on 31 March 2024, and the requirements marked as future-dated in version 4.0 became mandatory on 31 March 2025, so every assessment now covers them in full. We check your controls against the current text rather than the version your last assessment used.

Generally, no. Under the RBI's card-on-file tokenisation framework, from 1 October 2022 no entity in the card transaction chain other than the card issuer and the card network may store actual card data, and saved-card experiences must use tokens instead. For most Indian merchants and payment aggregators that removes stored card numbers from scope, which is good for PCI DSS because storage brings some of the heaviest requirements. It does not remove PCI DSS itself. Systems that still receive, process or transmit card data during a transaction remain in scope, and so do the payment pages and scripts that capture it. We confirm where card numbers genuinely still pass through your environment, including legacy tables, exports and logs that pre-date the rules, and make sure any residual data is removed and the remaining flows are protected.

Several kinds, on a fixed rhythm. External vulnerability scans must be run at least once every three months by an Approved Scanning Vendor, and internal vulnerability scans at least quarterly as well, with rescans until high-risk issues are resolved. Penetration testing of the cardholder data environment, internally and externally, is required at least once a year and after any significant change. If segmentation is used to reduce scope, it must be tested too: at least annually for merchants and every six months for service providers. Payment page scripts need change and tamper detection, and critical file changes need monitoring. We schedule this calendar during remediation so evidence builds up across the year, and our own penetration testing team runs the application and network tests, scoped to the requirements they must satisfy rather than to a generic checklist.

For a first validation, usually three to five months, and our phases add up to that. Scoping and card data flow mapping takes one to two weeks, the gap assessment two to three, control remediation six to twelve, evidence collection two to three, and assessment preparation one to two, before a QSA's fieldwork where a Report on Compliance is needed. A merchant with a fully outsourced payment page and a short SAQ can finish in weeks rather than months. What stretches the timeline is almost always remediation: segmentation projects, multi-factor authentication rollouts and logging changes that need engineering time and change windows. The quarterly scanning cycle also matters, because an assessor expects to see passing scans over time rather than a single clean result. We commit to a date after the gap assessment, when the size of the remediation work is known.

We do not publish a figure for PCI DSS, because the spread between engagements is too wide for a range to help you. A merchant validating with a short SAQ behind a hosted payment page needs a fraction of the work a payment service provider preparing for a Report on Compliance does. The quote depends on your merchant or service provider level, the number of systems and locations in the cardholder data environment, how much segmentation and remediation is needed, and whether you need a QSA-led assessment. Several costs sit outside our fee: the QSA's own fee where a Report on Compliance is required, Approved Scanning Vendor scans, any tooling such as logging or file integrity monitoring, and your team's engineering time. We scope first, then give you a fixed price in writing for the work we will do.

A Report on Compliance is completed by a Qualified Security Assessor, an assessor company and individuals qualified by the PCI Security Standards Council, and your acquiring bank or card brand receives it together with an Attestation of Compliance. Self-assessment questionnaires are completed by your own organisation and signed by an officer. Our role sits on both sides of that assessment: we scope the environment, run the gap assessment, help remediate, build the evidence package indexed by requirement, and prepare your control owners for the assessor's interviews. During QSA fieldwork we handle evidence requests and help resolve findings before they reach the report. Keeping preparation and assessment in separate hands is also what the standard's independence expectations point to, and it means the QSA's time is spent confirming controls rather than discovering gaps. We can also help you shortlist QSA companies for your level.