PCI DSS in Morocco: what merchants and e-commerce sites must do

The short answer: in Morocco, a merchant that accepts bank cards, in store or online, must comply with PCI DSS, currently version 4.0.1. Nobody will ask you for a large-enterprise audit, though: the effort depends mostly on how you take payments. A website that redirects customers to the acquirer’s secure payment page has very little to prove; a website that displays the card form itself, or keeps card numbers, has much more. The first decision is architectural, not a tooling one.

This guide explains who is in scope, how to identify your self-assessment questionnaire (SAQ), what changed with the payment page script requirements, and the action plan we follow. Technical points come from publications by the PCI Security Standards Council (PCI SSC) and the Centre Monétique Interbancaire (CMI). It does not replace your acquirer’s instructions, which remain the reference for your contract.

PCI DSS in two minutes

PCI DSS (Payment Card Industry Data Security Standard) is published by the PCI SSC, the body founded by the major card networks. The standard is organised into twelve principal requirements grouped under six goals: secure network, protection of account data, vulnerability management, access control, monitoring and testing, security policy.

Three things to remember:

• It is not a Moroccan law. It is a contractual obligation: card networks impose it on acquirers, which pass it on to their merchants.
• Only one version is active. Version 4.0 was retired at the end of 2024; 4.0.1 is now the only active version supported by the PCI SSC.
• The “future-dated” requirements have applied since 31 March 2025. They were best practice until then and became mandatory on that date, including those on payment pages and authentication.

Who is in scope in Morocco

Any entity that accepts, processes, stores or transmits card data. In practice:

• Shops and restaurants with a payment terminal.
• E-commerce websites, including those using the CMI gateway.
• Hotels, clinics, schools and firms that take remote payments by payment link or phone.
• Providers that host or maintain those systems, for their part.

CMI, the historic acquirer created by Moroccan banks, describes itself as merchants’ partner since 2004. On its e-commerce page, it strongly advises affiliated online merchants to adopt 3-D Secure, cardholder authentication with a code before authorisation. 3-D Secure reduces fraud but does not replace PCI DSS: it authenticates the customer, it does not protect your website.

Finding your SAQ

Small and mid-sized merchants usually demonstrate compliance with a self-assessment questionnaire, the SAQ, plus an attestation. The PCI SSC publishes several SAQs, each reserved for a type of environment described in its eligibility criteria. Your acquirer tells you which one to complete; here is how to find your way.

How you take payments	Most likely SAQ	Effort
Website redirecting to the acquirer’s payment page, or fully outsourced payment	SAQ A	Low
Website that displays or controls the payment page itself, even if data goes to a provider	SAQ A-EP	High
Standalone payment terminals, no card storage	SAQ B	Low
Terminals connected to the processor over IP	SAQ B-IP	Medium
Manual entry into a provider’s web virtual terminal, on a dedicated computer	SAQ C-VT	Medium
Point-of-sale application connected to the internet	SAQ C	High
Validated point-to-point encryption (P2PE) terminals	SAQ P2PE	Low
Storing card numbers, or any case that fits no other SAQ	SAQ D	Very high

The table gives the strategy: each row higher up removes systems from scope. Moving from a card form embedded in the website to a redirect to the acquirer’s page takes you from SAQ A-EP to SAQ A. It is often the most cost-effective measure of the whole project.

Payment pages: the biggest change

Digital skimming attacks inject a few lines of JavaScript into a merchant website to copy the card numbers customers type in. Two version 4 requirements address this, applicable since 31 March 2025:

• Requirement 6.4.3: every script executed in the browser on the payment page must be inventoried, authorised and integrity-checked, with a written justification of why it is there.
• Requirement 11.6.1: a mechanism must detect and alert on unauthorised changes to the payment page as received by the browser, including its security-relevant HTTP headers.

In January 2025, the PCI SSC removed these two requirements (and the related 12.3.1 risk analysis) from SAQ A, while stating that the requirements themselves remain in the standard. In return, SAQ A has a new eligibility criterion: the merchant must confirm its site is not susceptible to script attacks that could affect its payment system. In other words, even with a redirect to CMI, a WordPress or WooCommerce site that is never updated does not qualify.

What we put in place on a merchant website:

1. An inventory of third-party scripts (analytics, chat, advertising) and removal of those that have no business on checkout pages.
2. A Content-Security-Policy header restricting allowed script sources.
3. Subresource integrity (the integrity attribute) for external scripts that support it.
4. Change monitoring on sensitive pages, with alerts.
5. Updates to the CMS, theme and plugins, as covered in our guide to securing a business WordPress website; recent news is a reminder, see our alert on the WordPress vulnerability CVE-2026-119977.
6. A web application firewall (WAF) in front of the site to filter known attacks.

Other requirements that apply to an SME

Depending on the SAQ, other version 4.0.1 requirements apply. The ones we encounter most often:

Requirement	What it asks	Typical implementation
1.x	Network security controls around payment systems	Firewall and segmentation: terminals and POS on a separate VLAN
3.3	Never keep sensitive authentication data after authorisation	No copy of the security code, on paper or in files
5.x	Protection against malware	Managed antivirus or EDR on in-scope computers
6.3.3	Security patches applied	Documented, followed update policy
8.3.6	Passwords of at least 12 characters	Password policy or password manager
8.4.2	Multi-factor authentication for access into the payment environment	MFA on website and server administration
10.x	Logging and review of events	Centralised logs, alerts
11.3.2	Quarterly external vulnerability scans by an approved scanning vendor (ASV)	Depending on the SAQ, on exposed addresses
12.10	Incident response plan	Written procedure, acquirer contacts

For strong authentication, our MFA rollout guide details the method. For segmentation and firewalls, see the business firewall buying guide for Morocco; we deploy FortiGate as a Fortinet integrator in Morocco.

Mistakes we see at merchants

1. Card numbers received by e-mail or WhatsApp for a booking, then kept in the inbox or on a phone.
2. Paper forms with the security code kept “to charge later”.
3. Payment terminal on the same network as guest WiFi or cameras.
4. Card form embedded in the website with no business reason, which moves you from SAQ A to SAQ A-EP.
5. Shared website administrator account used by the web agency, the intern and the provider, without MFA.
6. No breach procedure: nobody knows whom to notify at the acquirer.

PCI DSS, law 09-08 and the national framework

PCI DSS protects card data. Your customers’ personal data (name, address, phone) also falls under law 09-08 and the CNDP, see our notes on Morocco’s data protection law 09-08. A company already working towards ISO 27001 can reuse much of its policies, asset inventory and risk management: the two frameworks overlap widely without replacing each other.

Six-step action plan

1. Map payment flows: where cards come in (website, terminal, phone, e-mail), where they pass, where they could be copied.
2. Reduce scope: redirect to the acquirer’s page, P2PE terminals or a separate network, tokens instead of card numbers, delete stored cards.
3. Confirm the SAQ with the acquirer, CMI or bank, and get its validation calendar.
4. Close the gaps: updates, MFA, segmentation, payment page scripts, logging.
5. Test: vulnerability scans and, if needed, a penetration test of the website.
6. Maintain: compliance is renewed, and a site changed every week must be monitored continuously.

How we support merchants

ALLSAFE SOLUTIONS is neither a QSA assessor nor an approved scanning vendor (ASV): we do not issue PCI DSS attestations. Our role is to prepare and secure the environment so that your questionnaire is accurate and defensible. We map your flows, reduce scope, secure the merchant website, network and computers, and put MFA, firewalls and monitoring in place. Critical equipment is monitored 24/7, and critical incidents are handled in under 15 minutes.

For the overall approach, see our cybersecurity for businesses in Morocco offering and our guide to choosing a SIEM. Then request your free initial audit: we reply within 24 business hours with a list of gaps and a prioritised action plan.