If your business accepts payment cards, the Payment Card Industry Data Security Standard applies to you. PCI DSS is set by the PCI Security Standards Council and enforced through the card brands and the banks and payment providers that process your payments. It applies to merchants of every size, from a single online shop to a national retailer.

The standard changed significantly with version 4.0. Version 4.0.1, a limited revision that clarified wording without adding or removing requirements, is now the version to follow, and the requirements that were future-dated in version 4.0 became mandatory on 31 March 2025. Below is what that means for merchants in the Kingdom, and what to do about it.

First question: how do card details reach you? #

Almost everything about your PCI DSS effort depends on one thing: where card data flows. The fewer of your systems that see, store or transmit card data, the smaller your scope and your effort.

  • Fully outsourced online payments. Customers pay on a page hosted by a payment provider, through a redirect or an embedded payment form, and card data never touches your servers.
  • Payment pages on your own website. Your site collects card data and passes it on. Your web servers are then in scope.
  • Card terminals in stores. Point-of-sale terminals connect to a processor; the terminals, their network and how staff handle them matter.
  • Phone and manual orders. Staff take card details by phone or by hand, which brings people, processes and recordings into scope.

Your acquiring bank or payment provider will tell you how you must validate compliance, usually through a Self-Assessment Questionnaire (SAQ) for smaller merchants or a Report on Compliance by a Qualified Security Assessor for larger ones.

What version 4 changed for merchants #

Version 4 introduced new requirements, and the most relevant for merchants include:

  • Payment page scripts. Requirement 6.4.3 asks for every script on the payment page to be authorized, justified and checked for integrity, and requirement 11.6.1 asks for a mechanism that detects unauthorized changes to the payment page. These target "skimming" attacks, where malicious code steals card data in the browser.
  • Multi-factor authentication for all access into the cardholder data environment, not only remote access.
  • Targeted risk analysis for controls where you choose how often to perform them.
  • Automated log review mechanisms in place of manual checks alone.
  • Protection against phishing for staff.
  • Annual scope confirmation, documenting every location and flow of card data.

For merchants who fully outsource an embedded payment form, the Council revised the SAQ A questionnaire in early 2025: requirements 6.4.3 and 11.6.1 were removed from that questionnaire and replaced with an eligibility condition that the merchant's site is not susceptible to attacks from scripts that could affect payment. Implementing those two requirements remains a recognized way to meet the condition. Confirm the current version of your questionnaire with your payment provider before you start.

Practical steps for Saudi merchants #

1. Draw your card data flow #

Sketch how a card payment moves from the customer to the processor, for every channel: online, in store, by phone. Mark every system, person and supplier that touches card data.

2. Shrink the scope #

Use hosted payment pages or embedded forms from your provider, tokenization, and payment terminals that encrypt card data at the point of entry. Remove card data from places it does not need to be, such as email inboxes, spreadsheets and call recordings.

3. Confirm your validation route #

Ask your bank or payment provider which SAQ or assessment applies to you and when it is due. Document the answer.

4. Secure the payment page #

If your website hosts or embeds the payment step, inventory its scripts, remove what is not needed, and put change detection in place. This is where most online card theft happens.

5. Turn on multi-factor authentication #

Apply it to every account with access to systems in scope, including administrators, support staff and third parties.

6. Test #

PCI DSS expects regular vulnerability scanning, including quarterly external scans by an Approved Scanning Vendor for internet-facing systems in scope, and penetration testing at least annually and after significant changes for merchants whose assessment requires it. Where you rely on network segmentation to reduce scope, that segmentation must be tested too.

7. Manage your providers #

List every service provider that can affect card data security, confirm their PCI DSS status each year, and make responsibilities clear in contracts.

8. Keep evidence as you go #

Assessors look for evidence that controls operate over time. Keep records of reviews, scans, tests, training and changes alongside your policies.

How PCI DSS fits with Saudi requirements #

PCI DSS does not replace national requirements; it applies alongside them. Customer data falls under the Personal Data Protection Law, organizations supervised by the Saudi Central Bank also follow the SAMA Cyber Security Framework, and entities within NCA scope follow the applicable NCA controls. Much of the evidence overlaps, so plan your programme once and map it to each requirement.

Learn more about our PCI DSS readiness service and web application penetration testing.

Frequently asked #

Which PCI DSS version applies now?

PCI DSS v4.0.1, a limited revision of v4.0 that clarified wording without adding or removing requirements. The requirements that were future-dated in v4.0 became mandatory on 31 March 2025.

Does PCI DSS apply to small merchants?

Yes. It applies to every merchant that accepts payment cards. Smaller merchants usually validate through a Self-Assessment Questionnaire, and your bank or payment provider tells you which one.

How can a merchant reduce PCI DSS effort?

Keep card data away from your own systems: use hosted payment pages or embedded forms from your provider, tokenization and terminals that encrypt card data at entry, and remove card data from email, spreadsheets and recordings.

Is penetration testing required?

Merchants whose assessment includes requirement 11.4 must perform penetration testing at least annually and after significant changes, plus segmentation testing where segmentation reduces scope.

Official Sources and References #

The documents behind this page, linked at the publisher. Where a Saudi regulation is published in both languages, the Arabic text is the binding version.