PCI DSS readiness service
Limaz helps merchants, payment providers, fintechs, and service providers define the cardholder data environment, assess readiness, implement remediation, and prepare evidence for the required validation path.
PCI DSS applies to entities that store, process, or transmit cardholder or sensitive authentication data. It also covers systems that can affect the security of that environment. Readiness work starts with data flows, connected-system boundaries, and segmentation decisions.
Limaz provides readiness, remediation, and evidence support.
The Payment Card Industry Data Security Standard (PCI DSS) protects payment account data. It applies to every entity that stores, processes or transmits cardholder data or sensitive authentication data, and to every entity that can affect the security of that data: merchants, processors, acquirers, issuers and service providers.
PCI DSS v4.0.1 is the only active version. The PCI Security Standards Council (PCI SSC) published v4.0 on 31 March 2022 and retired v3.2.1 on 31 March 2024. It published v4.0.1, a limited revision, in June 2024 and retired v4.0 on 31 December 2024. The 51 future-dated requirements introduced in v4.0 became mandatory on 31 March 2025.
PCI SSC writes the standard. The card brands enforce it. American Express, Discover, JCB International, Mastercard, UnionPay and Visa each run their own compliance programme and decide who must validate, how and how often. Your acquiring bank passes those rules to you.
Account data has two parts. Cardholder data is the primary account number (PAN), cardholder name, expiration date and service code. Sensitive authentication data is full track data, the card verification code, and PINs or PIN blocks. Sensitive authentication data must never be stored after authorisation, even encrypted.
In Saudi Arabia, PCI DSS reaches merchants through their acquirers. Banque Saudi Fransi's published mada point-of-sale merchant agreement, for example, requires merchants to comply with PCI DSS, demonstrate compliance and carry out required remediation. Payment service providers licensed by SAMA also follow SAMA and National Cybersecurity Authority (NCA) cybersecurity requirements, so the PCI DSS programme sits inside a wider control set.
Scope decides cost. Every system component in scope must meet the applicable requirements, so the first job is to find every place account data lives and moves. PCI SSC's scoping guidance tells entities to start from the assumption that everything is in scope until verified otherwise.
The guidance sorts systems into three categories. CDE systems store, process or transmit account data, or sit on the same network segment as systems that do. Connected-to and security-impacting systems, such as authentication servers, jump hosts and logging and patching servers, reach the CDE or affect its security, and they are fully in scope. Out-of-scope systems meet every exclusion test: no account data, no connection to the CDE and no path to affect its security.
Segmentation is how scope shrinks. PCI DSS leaves segmentation optional and strongly recommends it, because isolating the CDE from the rest of the network reduces assessment scope, cost and risk. If you rely on segmentation, prove it: penetration-test the segmentation controls at least once a year as a merchant and every six months as a service provider.
Architecture reduces scope further. Tokenisation, hosted payment pages and iframes from a PCI DSS compliant processor, and validated point-to-point encryption (P2PE) solutions each remove systems from the CDE. Each choice also moves responsibility, so record which party owns which requirement in a responsibility matrix with every third-party service provider.
PCI SSC defines the validation documents. The card brands decide who uses which one. Each brand sets its own merchant and service-provider levels and the validation each level submits, and acquirers pass those rules to their merchants. Your acquirer or the brand confirms your level and your document.
Self-assessment
The entity assesses itself. Merchants use SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC or D, each matching a payment channel and architecture. SAQ D for Service Providers is the only SAQ for service providers. Your acquirer or the brand confirms eligibility.
Assessor-led
A Qualified Security Assessor (QSA) tests every applicable requirement, with sampling, interviews and evidence, and documents the result in the ROC template. The Customized Approach is documented only through a ROC.
Declaration
The formal declaration of the assessment result. It accompanies every SAQ and ROC, goes to the acquirer or brand, and is the evidence customers collect when they monitor a service provider's PCI DSS status every 12 months (12.8.4).
Quarterly evidence
External vulnerability scans by a PCI SSC Approved Scanning Vendor every three months, with passing results. Acquirers check them alongside the SAQ or ROC.
How Limaz runs PCI DSS readiness with payment teams in the Kingdom.
Get your level and required document from your acquirer or the card brands. Merchant or service provider, SAQ or ROC: this fixes the target.
Trace e-commerce, mobile, POS, call centre, refunds, chargebacks and reporting. Find every place PAN and sensitive authentication data appear, including logs and backups.
Delete stored data with no business need, tokenise the rest, segment the CDE and move payment pages to compliant hosted components.
Test each applicable requirement for design, implementation and operating evidence, including every requirement that became mandatory on 31 March 2025.
Close gaps with named owners and dates: MFA, script management, logging, hardening, key management and vulnerability management. Limaz implements the technical fixes alongside the plan.
Map each requirement to its evidence, owner and sampling period, then run a pre-assessment against it.
Complete the SAQ, or support the QSA through the ROC, and issue the AOC.
Run the recurring controls on a calendar: quarterly scans, access and rule reviews, penetration tests, scope confirmation and targeted risk analyses.
Fraud, AML, identity, and transaction decision workflows around payments.
Build payment-software security checks into delivery.
Control workforce, administrator, vendor, and service access.
Prioritize risk and remediation across the payment environment.
PCI DSS v4.0.1 is the only active version. PCI SSC published it in June 2024 as a limited revision of v4.0 that corrects errors and clarifies intent, with no requirements added or deleted. PCI DSS v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024. Every assessment today runs against v4.0.1.
On 31 March 2025. PCI DSS v4.0 introduced 51 future-dated requirements that were best practice until that date. They include MFA for all access into the cardholder data environment, management of payment page scripts, change- and tamper-detection on payment pages, automated phishing protection and targeted risk analyses for activity frequency. The v4.0.1 revision left that date unchanged.
Every entity that stores, processes or transmits cardholder data or sensitive authentication data, and every entity that can affect the security of that data. That covers merchants, processors, acquirers, issuers and service providers such as hosting, cloud and payment gateway providers. The card brands and acquirers decide who must validate compliance and how, through their own compliance programmes.
A Self-Assessment Questionnaire (SAQ) is completed by the entity itself, and each SAQ type fits a specific payment setup. A Report on Compliance (ROC) is a detailed assessment by a Qualified Security Assessor (QSA) against every applicable requirement. Both end with an Attestation of Compliance (AOC). Which one you submit depends on the level your card brands and acquirer assign you.
The card brands. PCI SSC writes the standard and the validation documents, while American Express, Discover, JCB International, Mastercard, UnionPay and Visa each run their own compliance programmes. Each brand defines its merchant and service-provider levels and the validation required at each level. Acquirers apply those rules to their merchants, so your acquiring bank is the first place to confirm your level.
The Customized Approach lets an entity meet a requirement's stated Customized Approach Objective with a different control from the one the standard defines. It is intended for risk-mature entities. Each customized control needs a controls matrix and a targeted risk analysis, and a QSA validates it through a ROC. SAQs cannot document it, and several requirements have no customized objective.
No. PCI DSS leaves segmentation optional, and PCI SSC strongly recommends it because isolating the cardholder data environment reduces assessment scope, cost and risk. Without segmentation, the whole network is in scope. If you use segmentation to reduce scope, penetration testing must confirm it works: at least once a year for merchants and every six months for service providers.
Saudi acquirers write PCI DSS into their merchant agreements. Banque Saudi Fransi's published mada point-of-sale merchant agreement requires merchants to comply with PCI DSS, demonstrate compliance and carry out required remediation. Merchants that also accept international cards fall under the card brands' programmes through their acquirer. Confirm the exact validation path with your acquiring bank.
Tell us which system, control, or requirement you are working on. We’ll come back with a clear next step.
