Security standards rarely change behaviour on their own. Money does. What made 2007 the year PCI DSS became a real constraint on merchants was not the quality of the standard — version 1.1 had been published in September 2006 and read much like its predecessor — but the moment the card brands attached monthly fines and hard deadlines to it. Payment card compliance stopped being an IT aspiration that year and became a line in the operating budget. For a lot of mid-market merchants, it was the first security spend they had ever been forced to make by someone other than themselves.
Where the Standard Came From
Before PCI DSS there were five competing programmes. Visa ran the Cardholder Information Security Program from 2001, Mastercard ran the Site Data Protection programme, and American Express, Discover and JCB each had their own requirements. Merchants accepting all five were, in principle, being audited against five overlapping rulebooks. The five brands resolved that in September 2006 by founding the PCI Security Standards Council and consolidating their requirements into a single standard. Version 1.1 arrived at the same time, adding the requirement that would irritate developers for the next two years: requirement 6.6, mandating either application code review or a web application firewall in front of public-facing payment applications. The standard itself was, and remains, unglamorous: build and maintain a secure network, protect stored cardholder data, encrypt transmission across public networks, restrict access on a need-to-know basis, monitor and test, maintain a policy. Nothing in it was controversial. The argument was always about who paid, and when.
The Deadlines That Made It Real
Compliance obligations were tiered by transaction volume, and the brands had been staggering their dates for years — Visa's Level 1 deadline fell in June 2004, Mastercard's in June 2005, American Express's in October 2006, with Level 2 merchants following in March 2007. What changed the calculus was enforcement. Visa's compliance acceleration programme, announced at the end of 2006, put monthly financial penalties behind the deadlines for the largest merchants and paired them with a substantial incentive pool for acquirers whose merchants validated early. Fines were levied on acquiring banks, which passed them straight through to the merchant — and the published ranges, from a few thousand to six figures per month, were large enough to get finance directors involved in a conversation they had previously delegated. Then in October 2007, Visa went further and targeted the software itself. A CISP bulletin dated 23 October 2007 set out five mandates phased between January 2008 and July 2010, progressively eliminating payment applications that stored prohibited data. Acquirers were made responsible for ensuring their merchants used compliant applications. The Payment Application Best Practices programme behind those mandates became PA-DSS the following year. The effect was structural. A merchant could no longer be non-compliant quietly, because their software vendor and their bank now had skin in the outcome.
TJX Made the Argument for Them
The timing was not coincidental. In January 2007, TJX disclosed the intrusion that would eventually be reported as more than 45 million card numbers taken over eighteen months. State regulators attributed it in part to weak wireless encryption and the retention of card data the company was contractually forbidden to keep. Every card brand executive arguing internally for tougher enforcement suddenly had a case study. Every merchant arguing that PCI was overreach had lost their best example of a hypothetical risk.
The Flaw Everyone Noticed Immediately
PCI validation is a point-in-time assessment. A merchant demonstrates compliance on the day of assessment, receives a report, and returns to normal operations. Whether controls continue to operate for the remaining 364 days is a separate question, and one the framework originally did little to answer. The Heartland Payment Systems breach, disclosed in January 2009 and affecting well over a hundred million cards, made this concrete: Heartland had been assessed as PCI compliant. So had other breached organizations. The standard measured a snapshot; attackers exploited the film. This is the durable critique of compliance-driven security, and it has nothing to do with PCI specifically. Any framework that rewards evidence production rather than control operation will produce organizations that are excellent at evidence production.
What PCI Looks Like Now
The standard has evolved in the direction of the critique. PCI DSS v4.0 arrived in March 2022 and v4.0.1 in June 2024, and the large set of future-dated requirements became mandatory on 31 March 2025. The substantive changes address exactly the weaknesses visible in 2007:
- Continuous rather than annual thinking — targeted risk analyses that determine control frequency, rather than one universal schedule.
- Multi-factor authentication everywhere into the cardholder data environment, not only for remote administrative access.
- Client-side script controls for payment pages, aimed at the digital skimming attacks that dominate e-commerce fraud.
- A customised approach allowing mature organizations to meet an objective by a different route, provided they can evidence it. The compliance levels and the fine-passthrough mechanism remain broadly unchanged. So does the underlying commercial logic: your acquirer carries the brand's liability, and will move it to you.
Map the flow
Identify where cardholder data is stored, processed or transmitted.
Reduce exposure
Review unnecessary retention and provider-hosted handling options.
Test separation
Verify that the cardholder environment's boundaries hold.
Confirm validation
Agree the applicable questionnaire and application obligations.
Maintain evidence
Keep control operation under review between assessments.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Mid-Market Merchants
- Reduce scope before improving controls. Every system that stores, processes or transmits card data is in scope. Tokenisation, hosted payment pages and redirects remove far more cost than any control investment.
- Do not store what you do not need. Prohibited data retention has been the root cause of an outsized share of merchant breaches since 2005.
- Segment the cardholder environment properly, and test that the segmentation actually holds.
- Treat the self-assessment questionnaire selection seriously. Choosing the wrong SAQ is the most common way merchants end up under-assessed and over-exposed.
- Get the payment application question answered by your provider in writing, including how they handle client-side scripts on payment pages.
- Diarise the annual evidence cycle so it is a maintained control set rather than an eight-week panic before assessment.
Common Questions
Is PCI DSS a legal requirement?
No. It is a contractual obligation flowing from your agreements with the card brands and your acquiring bank. The penalties are commercial — monthly fines, higher transaction costs, and in extreme cases loss of the ability to accept cards.
What changed between PCI DSS 1.1 and 4.0?
The control objectives are recognisably the same. The enforcement model, the treatment of authentication, the handling of e-commerce scripts, and the expectation of continuous rather than annual compliance have all changed substantially.
Does being PCI compliant mean we will not be breached?
No, and the history of certified merchants suffering major breaches proves the point. Compliance sets a floor. It is a minimum standard for handling other people's card data, not a security strategy.
Who pays the fines if we are non-compliant?
The card brands fine the acquiring bank. The acquiring bank's contract with you almost certainly allows it to recover that amount from you, along with any card reissuance and forensic investigation costs.
PCI Readiness Assessment — Outpace helps mid-market merchants cut cardholder data environment scope first and then close the remaining gaps, including the v4.0.1 requirements that became mandatory in March 2025. Most clients find the scope work pays for the whole exercise.