Compliance · Payment security
PCI DSS, from SAQ to ROC.
The card brands' security standard for anyone who stores, processes or transmits cardholder data — twelve requirements, validated every year.
- 12requirements in 6 goals
- v4.0.1current version
- 4merchant levels
Payment Card Industry Data Security Standard v4.0.1
PCI DSS is set by the PCI Security Standards Council on behalf of Visa, Mastercard, American Express, Discover and JCB. It is contractual rather than statutory: your acquirer or payment processor requires it, and the card brands enforce it through them. Any merchant or service provider that touches cardholder data is in scope, however small.
Version 4.0 replaced 3.2.1 in 2024, and its future-dated requirements became mandatory on 31 March 2025 — among them multi-factor authentication for all access into the cardholder-data environment, authenticated vulnerability scans, payment-page script integrity and a targeted risk analysis for how often controls run. Version 4.0.1 is the current text.
Validation depends on volume and role. Level 1 merchants and service providers need an on-site assessment by a Qualified Security Assessor and a Report on Compliance; smaller merchants complete a Self-Assessment Questionnaire. Everyone in scope files an Attestation of Compliance and, where systems face the internet, quarterly scans by an Approved Scanning Vendor.
What the framework demands
The obligations an auditor or supervisor will test, in plain language.
Secure network and systems (Req. 1–2)
Network security controls between the cardholder-data environment and everything else, and no vendor defaults on any system component.
Protect stored account data (Req. 3)
Keep as little as possible; render the PAN unreadable with strong cryptography, tokenisation or truncation; never store sensitive authentication data after authorisation.
Encrypt in transit (Req. 4)
Strong cryptography and trusted certificates for cardholder data over open, public networks, with an inventory of keys and certificates.
Access control and identity (Req. 7–8)
Need-to-know access, unique IDs, and multi-factor authentication for all access into the cardholder-data environment, including administrators and remote users.
Logging, monitoring and testing (Req. 10–11)
Audit logs reviewed daily, time synchronisation, quarterly ASV and internal scans, annual penetration and segmentation testing, and change detection on payment pages.
Vulnerability management (Req. 5–6)
Anti-malware, secure development, timely patching, change control and — new in v4 — integrity monitoring of payment-page scripts.
Physical security (Req. 9)
Controlled facility access, media handling and destruction, and protection of point-of-interaction devices from tampering.
Policies and programme (Req. 12)
An information-security policy, risk assessments, third-party service-provider management, incident response and security awareness — plus the targeted risk analyses v4 uses to set control frequencies.
The cost of getting it wrong
- Monthly non-compliance fines passed on by the acquirer, typically escalating until validated
- Higher interchange fees and the threat of losing the ability to accept cards
- After a breach: forensic investigation costs, card re-issuance charges and brand assessments
- Reputational damage that outlives the incident
From gap to evidence
Assessment, remediation, documentation and audit support — run as one programme.
- 01
Scoping and data-flow mapping
We find every place card data enters, moves and rests, then shrink the cardholder-data environment through segmentation, tokenisation and hosted payment pages.
- 02
Gap assessment against v4.0.1
A requirement-by-requirement review producing a remediation plan with owners and dates, and a decision on SAQ type or ROC.
- 03
Remediation and hardening
Our security team implements the technical controls: segmentation, MFA, logging, encryption, vulnerability management and payment-page integrity monitoring.
- 04
Testing and evidence
ASV scans, internal scans, penetration and segmentation tests, and an evidence repository organised by requirement.
- 05
Assessment support and maintenance
We complete the SAQ with you or support your QSA through the ROC, then run the quarterly and annual cycle so compliance holds between assessments.
Deliverables
- Scope definition and cardholder-data-flow diagrams
- Gap assessment against PCI DSS v4.0.1 with remediation roadmap
- Implemented technical controls and hardening evidence
- Quarterly ASV scan reports and annual penetration-test report
- Completed SAQ and Attestation of Compliance, or QSA-ready ROC evidence
- Policy set covering all twelve requirements
- Ongoing compliance calendar and control monitoring
Questions we hear most
We use a hosted payment page. Are we still in scope?
Yes, but with a much smaller footprint. Outsourcing to a validated provider typically qualifies you for SAQ A or A-EP, which still requires securing the web server, protecting the payment-page scripts and managing the provider relationship.
What changed with PCI DSS v4.0?
A stronger focus on continuous security: MFA everywhere in the cardholder-data environment, authenticated internal scans, payment-page script controls, targeted risk analyses for control frequency, and a customised-approach option for meeting requirements differently. Future-dated items became mandatory on 31 March 2025.
Do we need a QSA?
Level 1 merchants — over six million transactions a year — and most service providers need a QSA-led Report on Compliance. Others self-assess, though many bring in an assessor for assurance. We prepare and support both paths.
How often do we have to validate?
Annually, with quarterly external vulnerability scans by an Approved Scanning Vendor and continuous operation of the controls in between.
Often pursued together
Ready to Transform Your Business?
Let's discuss how our expertise in IT security, development, and DevOps can help you achieve your goals.