Every time a customer enters their credit card number on your online store, in your mobile app or at your physical terminal, a chain of security responsibilities is triggered that affects every link in the process: the merchant, the payment gateway, the processor and the bank. If any of those links fails, the cardholder's data is exposed and the consequences range from massive fines to a total loss of customer trust.
The standard that defines how to protect that data at every stage of the process is PCI-DSS (Payment Card Industry Data Security Standard). It is not a recommendation or an optional best practice: it is a contractual requirement imposed by the card brands that, if not met, can result in financial penalties, a ban on accepting card payments and even legal liability in the event of a data breach.
In this article we explain what PCI-DSS is, who it applies to, what the 12 requirements of version 4.0 are, what compliance levels exist, what infrastructure measures you need to implement and how EasyDataHost can help you meet the standard with infrastructure built for it.
What Is PCI-DSS
PCI-DSS is the data security standard for the payment card industry. It was created in 2004 by the PCI Security Standards Council (PCI SSC), an organisation founded jointly by Visa, Mastercard, American Express, Discover and JCB. Its goal is to establish a common framework of security requirements that every entity that stores, processes or transmits cardholder data must meet.
The current version is PCI-DSS v4.0, published in March 2022, which introduces significant changes compared with v3.2.1: a customized approach, mandatory MFA for all access to the cardholder data environment, targeted risk analysis and script integrity monitoring on payment pages. Since 31 March 2025, v4.0 is the only active version and all future requirements must be met according to this version.
PCI-DSS is not a government law but a contractual standard. However, non-compliance has real consequences: card brands impose fines ranging from $5,000 to $100,000 per month, and in the event of a data breach, the merchant may be liable for fraud costs, card reissuance and notification of affected individuals. In many jurisdictions, including the European Union, PCI-DSS non-compliance may also constitute a violation of the GDPR.
Who Does PCI-DSS Apply To
PCI-DSS applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data. This includes:
- store Merchants: any business that accepts card payments, whether online, in-person or over the phone. From a small online shop to a large retail chain.
- account_balance Service providers: companies that process, store or transmit card data on behalf of others. This includes payment processors, gateways, hosting providers, tokenization companies and any third party with access to the cardholder data environment.
- sync_alt Payment processors: entities that handle the authorisation, settlement and clearing of card transactions between the merchant and the card networks.
- dns Infrastructure providers: hosting, cloud and colocation companies that host systems where card data is processed, even if they do not directly access the data.
A common misconception is that if you use an external payment gateway (such as Stripe or Adyen) you no longer need to comply with PCI-DSS. The reality is that you always need some level of compliance. What changes is the scope: by outsourcing card data processing you significantly reduce the number of requirements that apply to you, but you do not eliminate them entirely. At a minimum, you will need to complete a Self-Assessment Questionnaire (SAQ) and maintain basic security measures in your environment.
The 12 PCI-DSS v4.0 Requirements
PCI-DSS v4.0 organises its 12 requirements into 6 control objectives. Each requirement is broken down into detailed sub-requirements with specific testing procedures:
Goal 1: Build and maintain a secure network
- looks_one Requirement 1: Install and maintain network security controls. Firewalls, network segmentation, access rules between zones. Every connection between the cardholder data environment (CDE) and external networks must be controlled and documented.
- looks_two Requirement 2: Apply secure configurations to all system components. Remove default accounts and passwords, disable unnecessary services, harden operating systems and applications.
Goal 2: Protect cardholder data
- looks_3 Requirement 3: Protect stored cardholder data. Encryption at rest, PAN (card number) truncation, minimum retention policies. Never store CVV, PIN or magnetic stripe data.
- looks_4 Requirement 4: Encrypt transmission of cardholder data across open networks. TLS 1.2 minimum (TLS 1.3 recommended), valid certificates, elimination of obsolete protocols like SSL and TLS 1.0/1.1. Read more about data encryption and privacy.
Goal 3: Maintain a vulnerability management programme
- looks_5 Requirement 5: Protect all systems and networks from malicious software. Up-to-date antivirus/antimalware, threat detection, endpoint protection.
- looks_6 Requirement 6: Develop and maintain secure systems and software. Vulnerability patching, secure development (SDLC), code review, web application protection with WAF.
Goal 4: Implement strong access control measures
- filter_7 Requirement 7: Restrict access to cardholder data by business need to know. Principle of least privilege, role-based access control (RBAC).
- filter_8 Requirement 8: Identify users and authenticate access to system components. Individual accounts, mandatory MFA for all CDE access, strong password policies. In v4.0, MFA is required for all administrative access, not just remote access.
- filter_9 Requirement 9: Restrict physical access to cardholder data. Data centre access controls, cameras, visitor logs, secure media destruction.
Goal 5: Regularly monitor and test networks
- format_list_numbered Requirement 10: Log and monitor all access to network resources and cardholder data. Centralised logging, log retention for at least 12 months, periodic log review, real-time alerts.
- format_list_numbered Requirement 11: Regularly test security systems and processes. Quarterly vulnerability scans (ASV), annual penetration tests, file integrity monitoring, detection of unauthorised wireless access points.
Goal 6: Maintain an information security policy
- format_list_numbered Requirement 12: Support information security with organisational policies and programmes. Documented security policy, staff training, incident management, annual risk assessment, service provider management.
Compliance Levels
The card brands classify merchants into four levels based on their annual volume of card transactions. Each level has different validation requirements:
| Level | Annual transactions | Validation required |
|---|---|---|
| Level 1 | > 6 million | Annual audit by a QSA (Qualified Security Assessor) + quarterly ASV scan |
| Level 2 | 1 - 6 million | Annual SAQ (Self-Assessment Questionnaire) + quarterly ASV scan |
| Level 3 | 20,000 - 1 million (e-commerce) | Annual SAQ + quarterly ASV scan |
| Level 4 | < 20,000 (e-commerce) or < 1 million (other) | Annual SAQ + quarterly ASV scan (recommended) |
Any merchant that has suffered a data breach is automatically reclassified to Level 1, regardless of transaction volume. Service providers have their own classification: Level 1 (more than 300,000 annual transactions) and Level 2 (fewer than 300,000).
Key Requirements and How to Meet Them
The following table summarises the requirements with the greatest infrastructure impact and the specific measures to meet them:
| Requirement | Description | Infrastructure measure |
|---|---|---|
| Network segmentation | Isolate the CDE from the rest of the network | Dedicated VLANs, firewalls between zones, microsegmentation |
| Encryption in transit | Protect data on open networks | TLS 1.2+ on all connections, managed certificates, HSTS |
| Encryption at rest | Protect stored data | AES-256, key management with HSM, full volume encryption |
| Tokenization | Replace real data with tokens | Tokenization gateway, PCI scope reduction |
| WAF | Protect web applications | Web Application Firewall with OWASP rules, injection and XSS protection |
| IDS/IPS | Detect and prevent intrusions | Intrusion detection/prevention systems at the CDE perimeter |
| Centralised logging | Record and monitor access | SIEM, 12-month retention, real-time alerts, immutable logs |
Infrastructure for PCI-DSS
Meeting PCI-DSS is not just about policies and procedures: it requires a technical infrastructure that supports the demanded security controls. The fundamental pillars of a PCI-compliant infrastructure are:
- lan Network segmentation: the cardholder data environment (CDE) must be completely isolated from the rest of the network. This reduces the scope of the PCI audit and limits exposure in the event of a breach. It is implemented with dedicated VLANs, stateful firewalls between zones and strict access rules.
- shield Firewalls and WAF: network firewalls to control traffic between the CDE and external networks, and a Web Application Firewall (WAF) to protect payment applications against OWASP Top 10 attacks (SQL injection, XSS, CSRF).
- lock Encryption: TLS 1.2 or higher for all communications traversing public networks. AES-256 encryption for data at rest. Cryptographic key management with HSM or equivalent solutions. More details in our article on data encryption and privacy.
- token Tokenization: replace the real card data with tokens that have no value outside the payment system. Tokenization is the most effective strategy for reducing PCI scope, since systems that only handle tokens fall outside the audit scope.
- monitoring IDS/IPS and logging: intrusion detection and prevention systems at the CDE perimeter, combined with centralised logging with a minimum 12-month retention, real-time alerts and periodic log review.
Key concept:
Network segmentation is the single measure with the greatest impact on PCI-DSS compliance. By isolating the CDE, you drastically reduce the number of systems that fall within the audit scope, which simplifies compliance and reduces costs.
PCI-DSS in the Cloud
Meeting PCI-DSS in cloud environments introduces the concept of shared responsibility. The cloud provider is responsible for the security of the physical infrastructure (data centre, network, hypervisor), while the customer is responsible for the security of their systems, applications and data within the cloud.
For PCI compliance in the cloud to be viable, it is essential to choose a provider that already meets the PCI-DSS infrastructure requirements and can provide an Attestation of Compliance (AOC) or equivalent documentation. This does not exempt the merchant from its responsibility, but it significantly reduces the effort required by inheriting the provider's controls.
The combination of tokenization with a PCI-compliant cloud provider is the most effective strategy for minimising scope. If the real card data never touches your cloud infrastructure (because the payment gateway tokenizes it first), the scope of your PCI audit is reduced to the most basic SAQ.
What Is New in PCI-DSS v4.0
Version 4.0 introduces significant changes compared with v3.2.1. Organisations must adapt to these new requirements:
- tune Customized Approach: allows organisations to meet security objectives through alternative controls, provided they demonstrate that the intent of the requirement is met. This offers greater flexibility for companies with innovative architectures.
- passkey MFA everywhere: multi-factor authentication is now mandatory for all access to the CDE, not just remote access. This includes access from the internal network and administrative access to any component in the environment.
- target Targeted Risk Analysis: replaces the fixed frequency of some controls with a risk analysis that determines the appropriate frequency for each organisation. For example, the frequency of log reviews or vulnerability scans can be adjusted based on risk level.
- code Script integrity on payment pages: a new requirement that mandates monitoring the integrity of all scripts running on browser payment pages. This responds to the increase in Magecart/web skimming attacks that inject malicious scripts into checkout pages.
Common PCI-DSS Compliance Mistakes
These are the mistakes most frequently detected by QSA auditors, which can result in non-compliance or, worse, a data breach:
- dangerous Storing CVV/CVC: sensitive authentication data (CVV, PIN, magnetic stripe data) must never be stored after authorisation, not even encrypted. This is the most serious violation and carries the highest fines.
- dangerous Flat network with no segmentation: having the CDE on the same network as the rest of the company's systems. Without segmentation, the entire network falls within the PCI audit scope and any compromised system can access card data.
- dangerous No logging: failing to record access to the CDE or not retaining logs for long enough. Without logs, it is impossible to detect a breach in time and reconstruct what happened.
- dangerous Outdated TLS: still using TLS 1.0 or 1.1, which have known vulnerabilities. PCI-DSS has required TLS 1.2 as a minimum for years.
- dangerous Shared admin accounts: using a single root or admin account shared among several team members. PCI-DSS requires every person to have their own individual account with MFA.
EasyDataHost for PCI-DSS
EasyDataHost offers infrastructure built to meet the technical requirements of PCI-DSS. Our data centre in Madrid meets the physical security requirements (Requirement 9), and our network, cloud, colocation and managed services infrastructure facilitates compliance with network, encryption, access and monitoring requirements.
- check_circle Network segmentation: dedicated VLANs, managed firewalls and microsegmentation to isolate your CDE.
- check_circle Storage encryption: AES-256 encrypted disks, secure key management.
- check_circle WAF and IDS/IPS: managed perimeter protection against OWASP threats and network attacks.
- check_circle Logging and monitoring: centralised logging with 12+ month retention and real-time alerts.
- check_circle Compliance framework: infrastructure aligned with ISO 27001, ENS Alto and GDPR, facilitating PCI-DSS compliance.
- check_circle Data in Spain: Tier III+ data centre in Madrid, EU data sovereignty. Ideal for the financial sector.
Conclusion
PCI-DSS is not optional for any entity that participates in the card payment ecosystem. Version 4.0 strengthens requirements with universal MFA, targeted risk analysis and script integrity, demanding that organisations adopt a proactive, continuous approach to security rather than a mere checklist reviewed once a year.
- arrow_right PCI-DSS applies to every entity that stores, processes or transmits payment card data.
- arrow_right The 12 requirements cover network, data, vulnerabilities, access, monitoring and policies.
- arrow_right Network segmentation and tokenization are the most effective strategies for reducing scope.
- arrow_right PCI-DSS v4.0 mandates universal MFA, targeted risk analysis and script integrity on payment pages.
- arrow_right EasyDataHost offers PCI-ready infrastructure with segmentation, encryption, WAF and monitoring.
If you need infrastructure built to meet PCI-DSS, contact our team to design the architecture that best fits your compliance requirements.