PCI DSS: Card Data Security Explained for IT Companies

The Payment Card Industry Data Security Standard (PCI DSS) is the global security standard for protecting payment card data. It is managed by the PCI Security Standards Council (PCI SSC) and enforced by the card brands through the banks that process card payments. The current version is PCI DSS v4.0.1. If your business accepts card payments, or your systems could affect the security of someone else’s card data, PCI DSS applies to you.

What is PCI DSS?

PCI DSS sets baseline technical and operational requirements to protect account data:

The cardholder data environment (CDE) is the people, processes and technology that store, process or transmit account data, plus anything connected to or able to affect it. Everything in or connected to the CDE is in scope.

History and why it was introduced

PCI DSS was introduced because card fraud and data breaches were rising and merchants faced conflicting requirements from each card brand.

Main objectives (the six goals):

1. Build and maintain a secure network and systems.
2. Protect account data.
3. Maintain a vulnerability management programme.
4. Implement strong access control measures.
5. Regularly monitor and test networks.
6. Maintain an information security policy.

Who needs to comply?

Merchant levels

Levels are set by each card brand, typically based on annual card transactions. Visa’s widely used structure is:

Service providers are commonly Level 1 if they handle more than 300,000 card transactions a year, which requires a ROC by a QSA.

Is PCI DSS mandatory?

PCI DSS is not a law in most countries. It is mandatory by contract: card brands require acquirers to ensure their merchants and service providers comply. Consequences of non-compliance can include:

• fines charged by card brands to acquirers, usually passed on to the merchant;
• higher transaction fees;
• liability for fraud losses and card reissue costs after a breach;
• loss of the ability to accept cards.

Some US states refer to PCI DSS in law; for example, Nevada and Washington reference it in data security statutes.

Key requirements: the 12 requirements

Notable requirements introduced in v4.0

Most of these were “future-dated” and became mandatory on 31 March 2025.

For merchants using SAQ A (fully outsourced payment pages), the PCI SSC revised the SAQ in January 2025: requirements 6.4.3 and 11.6.1 were removed from SAQ A and replaced with an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

The customised approach

Version 4.0 added a customised approach: instead of the defined requirement, you can meet a requirement’s stated objective with your own control, supported by a targeted risk analysis and assessor validation. It suits mature organisations; most smaller businesses use the defined approach.

How to achieve PCI DSS compliance

1. Find out your level and validation requirements from your acquirer or payment provider.
2. Map card data flows: where card data enters, where it goes, and what systems touch it.
3. Reduce scope. Use hosted payment pages, iframes or tokenisation so card data never touches your servers. Segment any remaining CDE.
4. Choose the right SAQ (or prepare for a ROC). Common SAQs: A (fully outsourced e-commerce), A-EP (e-commerce where your site affects the payment page), D (everything else, and all service providers who use an SAQ).
5. Close gaps against the applicable requirements.
6. Run ASV scans quarterly on external IPs where required, and penetration tests where required.
7. Complete the SAQ or ROC and the Attestation of Compliance (AOC).
8. Submit to your acquirer or, for service providers, provide the AOC to customers.
9. Maintain compliance all year: logs, scans, reviews, training, change control.

Documentation and policies

• Card data flow diagrams and network diagrams
• PCI DSS scope document, confirmed at least yearly
• Information security policy and supporting policies for each requirement
• Configuration standards
• Inventory of system components, scripts on payment pages, keys and certificates
• Targeted risk analyses
• Roles and responsibilities, including a responsibility matrix with each service provider
• Access review records
• Vulnerability scan and penetration test reports
• Incident response plan and test records
• Security awareness training records
• SAQ or ROC and Attestation of Compliance

Assessments and validation

Validation is annual. Compliance is expected continuously.

Cost

Benefits

• Ability to accept card payments.
• Reduced risk of card data breaches and fraud liability.
• Trust from customers and payment partners.
• Strong security practices that carry over to other frameworks.

Risks of non-compliance

• Fines and higher fees from acquirers.
• Liability for fraud and card reissue costs after a breach.
• Termination of card acceptance.
• Reputational damage and regulatory exposure for personal data breaches.

Common mistakes

• Storing CVV codes or full track data, which is never allowed after authorisation.
• Assuming a payment provider makes you fully compliant. You still have responsibilities, at least for your website and integration.
• Card data in logs, support tickets or analytics.
• Flat networks that put everything in scope.
• Ignoring payment page scripts (6.4.3 and 11.6.1), the target of web skimming attacks.
• Treating compliance as an annual event.

Challenges for IT companies

• SaaS platforms with embedded payments become service providers with significant obligations.
• Shared responsibility with cloud and payment providers must be documented clearly.
• Third-party scripts such as analytics and chat widgets on checkout pages.
• Continuous deployment with change control and segmentation testing.

Best practices

• Never let card data touch your systems: use hosted fields, iframes or redirects with tokenisation.
• Keep checkout pages free of unnecessary third-party scripts.
• Use your payment provider’s AOC and responsibility matrix.
• Automate log review and configuration monitoring.
• Confirm scope every year and after major changes.

Tools that help

How PCI DSS relates to other frameworks

Real-world examples

• Web skimming. Magecart-style attacks, such as the 2018 British Airways breach, injected malicious scripts into payment pages. Requirements 6.4.3 and 11.6.1 target this attack type.
• Target (2013). Attackers entered through a third-party HVAC vendor’s credentials and stole card data from point-of-sale systems, a case often cited for third-party access and segmentation.
• Illustrative scenario, not a real company: an LMS platform selling courses moves from a self-hosted card form to its payment provider’s hosted fields. It drops from SAQ D to SAQ A, removes unneeded scripts from checkout, and keeps its provider’s AOC on file.

Frequently asked questions

Is PCI DSS a law? Generally no. It is a contractual requirement from card brands, enforced through acquirers. Some US states reference it.

What is the current version? PCI DSS v4.0.1. Version 4.0 was retired on 31 December 2024.

Do I need PCI DSS if I use Stripe, PayPal or Razorpay? Yes, but usually with much smaller scope. Many merchants using fully hosted payment pages or embedded fields qualify for SAQ A.

Can we store CVV numbers? No, not after authorisation, even if encrypted.

What is the difference between an SAQ and a ROC? An SAQ is a self-assessment. A ROC is a detailed report by a QSA, required for Level 1 entities.

How often must we validate? Annually, with quarterly external scans where required.

What happens if we have a breach and aren’t compliant? You may face fines, fraud liability and card reissue costs passed on by your acquirer, plus potential loss of card acceptance.

Next steps

• Ask your acquirer or payment provider which level and SAQ apply to you.
• Map your card data flows and remove card data from your systems where you can.
• Inventory every script on your payment pages.
• Get your payment provider’s Attestation of Compliance and responsibility matrix.