PCI DSS compliance,explained
PCI DSS is the security standard for any organisation that stores, processes, or transmits payment card data. It sets requirements across network security, data protection, access control, and monitoring. How you validate depends on your card volume: a Self-Assessment Questionnaire for smaller volumes, or an audit by a Qualified Security Assessor for larger ones.
What PCI DSS is
The Payment Card Industry Data Security Standard (PCI DSS) is maintained by the PCI Security Standards Council, which the major card brands founded. The current version is 4.0. It applies to any organisation that handles cardholder data, regardless of size, though what you must do scales with your volume.
It is a contractual standard rather than a law. You are held to it by the card brands and your acquiring bank, and failing to comply can mean fines or losing the ability to process card payments.
What counts as card data
PCI DSS protects two kinds of data. Cardholder data includes the primary account number (PAN) and details such as the cardholder name and expiry. Sensitive authentication data includes the full track data, card verification code, and PIN.
The single most effective way to reduce PCI scope is to handle less of this data: tokenisation and using a compliant payment provider keep raw card data out of your systems entirely.
The requirements at a glance
PCI DSS v4.0 groups its requirements into a set of security goals, including:
- Build and maintain a secure network, with firewalls and no vendor default passwords.
- Protect stored cardholder data and encrypt it in transit.
- Maintain a vulnerability management programme, including anti-malware and secure development.
- Implement strong access control, on a need-to-know basis and with unique IDs.
- Monitor and test networks, with logging and regular testing.
- Maintain an information security policy.
How validation works
Your merchant level, set by annual card transaction volume, decides how you validate. Lower volumes typically complete a Self-Assessment Questionnaire (SAQ), and the SAQ type depends on how you take payments. The highest volume (Level 1) requires a Report on Compliance from a Qualified Security Assessor (QSA).
Many merchants also need quarterly network scans from an Approved Scanning Vendor (ASV). Whichever path applies, the underlying controls must be in place and evidenced; the SAQ or audit just attests to them.
Staying assessment-ready
- 1Confirm your scope and reduce it where you can with tokenisation or a compliant payment provider.
- 2Identify your merchant level and the right SAQ or assessment path.
- 3Maintain the controls continuously, with owners, status, and evidence.
- 4Run the required scans and remediate findings before they age out.
- 5Treat it as a yearly cycle, not a yearly scramble, so evidence is ready when the assessment comes.
Frequently asked questions
What version of PCI DSS is current?
PCI DSS v4.0 is the current version of the standard, having replaced v3.2.1. It introduced more flexibility through a customised approach and added requirements that organisations have been phasing in. Validate against v4.0 unless your acquirer tells you otherwise.
Do I need a QSA, or can I self-assess?
It depends on your merchant level. Most lower-volume merchants can validate with a Self-Assessment Questionnaire, while the highest-volume merchants (Level 1) need a Report on Compliance from a Qualified Security Assessor. Your acquiring bank confirms which applies to you.
How do I reduce my PCI DSS scope?
Handle less card data. Using a compliant payment provider, tokenisation, and hosted payment pages keeps raw card data out of your environment, which shrinks the systems in scope and can move you to a simpler SAQ.
Do this in a fraction of the time
Diligio centralises your approved answers, drafts each response grounded in your sources, and independently verifies it before you review. RFPs, DDQs, and security questionnaires, answered from one knowledge base.
Related guides
What is a DDQ (due-diligence questionnaire)?
Due diligenceDDQ vs RFP: what is the difference?
RFPsRFP vs RFI vs RFQ: what is the difference?
RFPsThe RFP response process: a step-by-step guide
RFPsHow to build an RFP content library
RFPsThe bid/no-bid decision: when to respond to an RFP
Security questionnairesHow to respond to security questionnaires faster
Security questionnairesSIG vs CAIQ vs VSAQ: the security questionnaires explained
Security questionnairesVendor security assessment checklist
ComplianceSOC 2 vs ISO 27001: what is the difference?
ComplianceISO 27001 readiness checklist: how to prepare for certification
ComplianceSOC 2 for startups: a practical guide
ComplianceGDPR compliance for SaaS: a practical guide
ComplianceHIPAA compliance for software vendors
ComplianceThe NIST Cybersecurity Framework, explained
ComplianceISO 42001, the AI management standard, explained
ComplianceISO 27017 and ISO 27018: cloud security and privacy, explained
ComplianceISO 22301 and business continuity, explained
ComplianceDORA, explained
ComplianceCyber Essentials, explained
ComplianceThe CCPA and CPRA, explained
ComplianceNIST 800-53, explained
ComplianceNIST 800-171 and CMMC, explained
ComplianceFedRAMP, explained
ComplianceHITRUST CSF, explained
Financial regulationBSA/AML, explained
Financial regulationThe FATF 40 Recommendations, explained
Financial regulationMiFID II and MAR, explained
Financial regulationConsumer credit and fair lending, explained
Due diligenceThird-party risk management (TPRM): a practical guide
Putting PCI DSS into practice? See Diligio Compliance for PCI DSS.