Frameworks / Global
PCI DSS
PCI DSS is the payment card industry's security standard for any organisation that stores, processes or transmits cardholder data, enforced not by a regulator but contractually, by the card brands and acquiring banks.
What it requires
PCI DSS v4.0 was published in March 2022 and superseded v3.2.1 on 31 March 2024; v4.0.1 is the current clarifying revision, and the standard's future-dated requirements became mandatory on 31 March 2025. The standard comprises 12 principal requirements grouped under six goals: build and maintain a secure network and systems; protect account data; maintain a vulnerability management programme; implement strong access control measures; regularly monitor and test networks; and maintain an information security policy. Scope is defined by the cardholder data environment (CDE): every system that stores, processes or transmits cardholder data, plus every system that can affect its security. Network segmentation is the primary means of keeping that scope small. Validation depends on merchant or service provider level and channel: a Report on Compliance (ROC) produced by a Qualified Security Assessor for the largest entities, or a Self-Assessment Questionnaire of the appropriate type (A, A-EP, B, C, D and others) for smaller ones, with an Attestation of Compliance in both cases. Testing obligations include quarterly external vulnerability scans by an Approved Scanning Vendor, internal vulnerability scans, annual penetration testing (internal and external) with segmentation testing to confirm the CDE is isolated, and (new in v4) controls for managing and monitoring the scripts loaded on payment pages. v4 also introduced the customised approach, allowing an entity to meet a requirement's objective by an alternative method, provided it performs and documents a targeted risk analysis.
PCI DSS applies to every merchant and service provider that stores, processes or transmits cardholder data, and to anyone who can affect the security of that data, including hosting providers, payment gateways and, under v4, providers of scripts running on payment pages. Obligation flows from contract: your acquiring bank and the card brands require it. Validation effort scales by transaction volume (merchant levels 1-4) and by whether you are a service provider. For Israeli companies the standard bites when payments are taken directly, and it is often dramatically reduced (but never eliminated) by outsourcing payment capture to a compliant provider using a hosted page or iframe.
The controls people actually fail
- Scope is wrong: the cardholder data environment is drawn too narrowly, segmentation is assumed rather than tested, and systems that can reach the CDE are excluded from the assessment.
- Cardholder data is found where it should not be (in application logs, support tickets, screenshots, email attachments, analytics events and database backups) because nobody ever ran a discovery exercise across the estate.
- Quarterly ASV scans are run but the failing findings are never remediated and rescanned, so there is no set of four consecutive passing quarterly scans to present.
- Default credentials and shared administrative accounts persist on network devices and internal systems, and administrative access to the CDE lacks multi-factor authentication.
- Log data is collected but never reviewed, and retention falls short of the required period, so a forensic investigation after an incident has nothing to work with.
- The annual penetration test is performed but segmentation testing is not, leaving the central claim of the whole assessment (that the CDE is isolated) unproven.
- The v4 payment-page script requirements are ignored by companies using a redirect or iframe, on the incorrect assumption that outsourcing payment capture removes all obligation.
What is the current version of PCI DSS?
PCI DSS v4.0.1, a clarifying revision of v4.0 published in June 2024. Version 4.0 replaced v3.2.1, which was retired on 31 March 2024, and the requirements that v4 introduced as "future-dated" (best practices during the transition) became mandatory on 31 March 2025. All assessments today are against v4.x.
Do we still need PCI DSS if we use Stripe or another payment provider?
Yes, but the scope shrinks substantially. Using a compliant third-party provider with a fully hosted payment page or a properly implemented iframe means cardholder data does not enter your systems, and you validate with a much lighter Self-Assessment Questionnaire (SAQ A for fully outsourced e-commerce, SAQ A-EP where your site controls elements of the payment page). You remain responsible for how the payment page is delivered, for the security of the scripts loaded on it under the v4 requirements, for your third-party provider management, and for never letting card data leak into logs, tickets or emails. Outsourcing reduces the obligation; it does not remove it.
How often do you need PCI DSS penetration testing and scanning?
External vulnerability scans must be performed at least quarterly by an Approved Scanning Vendor, and after any significant change, with passing results. Internal vulnerability scans are also required on a defined periodic basis and after significant changes. Penetration testing (internal and external) is required at least annually and after significant infrastructure or application changes. Where segmentation is used to reduce scope, segmentation testing must confirm the isolation of the cardholder data environment at least annually for merchants, and at least every six months for service providers.
What is the difference between a SAQ and a Report on Compliance?
A Self-Assessment Questionnaire is completed by the entity itself, and the type (A, A-EP, B, B-IP, C, C-VT, D, P2PE) depends on how you accept payments: each type contains only the requirements relevant to that acceptance channel. A Report on Compliance is a full assessment conducted by a Qualified Security Assessor (or an approved internal security assessor) and is required for Level 1 merchants and for larger service providers. Both result in an Attestation of Compliance, which is the document your acquirer or customer actually asks to see, but they represent very different levels of independent scrutiny, which is why enterprise customers frequently specify which one they will accept.