If you operate an online store and your customers pay by card, you are subject to the PCI DSS security standard. Starting in the spring of 2025, the stricter Version 4.0 will take effect, adding dozens of new requirements. Some of these requirements also apply to small online stores that previously thought they were in the clear. This article explains what the standard requires, who it applies to, and the consequences of non-compliance.
What Is PCI DSS
PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of security rules that defines how payment card data should be handled. It was not created by the EU or the Slovak legislature. It was developed by a council composed of the card companies Visa, Mastercard, American Express, Discover, and JCB.
It is not a law in the traditional sense, but a contractual requirement. By signing a contract with a payment gateway or a bank to accept cards, the merchant commits to complying with PCI DSS. Enforcement is therefore often stricter in practice than with ordinary laws. The bank will not take the e-shop to court, but will increase fees or, in extreme cases, disable the ability to accept cards.
The standard applies to anyone who stores, processes, or transmits card data. It does not depend on the number of orders, but on whether card data passes through the system in question.
Version 4.0 and the Key Deadline
Version 3.2.1, which was previously in effect, has expired. It has been replaced by version 4.0, specifically its updated release 4.0.1. The key date is March 31, 2025. Until then, a transition period was in effect, during which many new requirements were treated only as recommended best practices. As of this date, they are mandatory and are considered a full-fledged requirement in every conformity assessment.
The new version introduced 64 new requirements, of which more than 50 were deferred until March 2025. These are not merely cosmetic changes, but represent the most significant shift in this standard in the last ten years or so.
The main change is in the approach. Security is no longer a one-time item that can simply be checked off once a year during an audit. The standard emphasizes ongoing and continuous protection.
Who Is Affected by the Standard
Merchants are divided into four levels based on the number of transactions per year. E-commerce sites with fewer than twenty thousand card transactions per year typically fall into the lowest, fourth level. A less stringent regime applies to this level. Instead of an audit by an external auditor, an annual self-assessment questionnaire, known as an SAQ, is sufficient.
However, a less stringent regime does not mean no regime at all. The new features in version 4.0 also target small e-shops, specifically two requirements that affect operators with the least technical capacity.
Level classification isn’t just about the number of transactions
A bank or card company may reclassify an e-shop to a higher level regardless of the number of transactions. The reason is usually a previous security incident or the method of payment processing. An operator that has dealt with a data breach in the past should automatically expect stricter requirements and verify its tier classification with its provider.
Two developments that most significantly impact e-shops
Digital skimming attacks, also known as Magecart or formjacking, operate discreetly. The attacker does not breach the server but injects malicious code into the payment page, often via a third-party script running on the site, such as analytics, chat, or an ad pixel. The customer enters their card number, the page functions normally, the order goes through, and the data is quietly leaked to the attacker. The leak can go unnoticed for months.
Version 4.0 addresses this with two requirements.
Managing Scripts on the Payment Page (6.4.3)
The site operator must have an overview of every script running on the page where card details are entered. They must know why the script is there, authorize it, and monitor its integrity—that is, detect any unexpected changes.
Monitoring HTTP Headers and Page Content (11.6.1)
A system is required that alerts you to unauthorized tampering with the payment page. This involves continuously monitoring whether anything unexpected is happening on the sensitive page.
Both requirements are technically challenging. For a small e-shop on a hosted platform, some of these are handled by the platform itself or the payment gateway. However, the responsibility for ensuring they are addressed remains with the operator, not the vendor.
Additional Stricter Requirements
In addition to the two e-commerce updates, version 4.0 has also tightened several general rules applicable to everyone who handles cards.
Multi-factor authentication has been expanded. Previously, it was required only for remote and administrative access; now it is required for any access to environments containing card data, not just for administrators.
Passwords have been extended to a minimum of twelve characters with appropriate complexity. The old eight-character passwords are no longer sufficient.
The scope of the assessment must be defined and documented once a year. This means mapping where card data flows within the system and which systems, individuals, and processes come into contact with it. For service providers, the interval is every six months.
Targeted risk analyses have also been added for multiple controls, along with stricter encryption rules. The specific scope depends on the method of payment processing.
Consequences of Non-Compliance
Fines are imposed by card companies through the bank, typically on a monthly basis, and their amount depends on the severity and duration of the non-compliance. The bank also has the right to increase transaction fees. In extreme cases, it will terminate the contract, and the ability to accept cards will be revoked.
The most serious consequence occurs in the event of a data breach. If an attacker steals customers’ card data and it turns out that the e-shop did not comply with PCI DSS, the operator is liable for damages, for a mandatory forensic audit, and for the costs of issuing new cards to affected customers. Added to this is the loss of customer trust, which has a long-term impact on the e-shop.
Connection to the GDPR
PCI DSS and GDPR overlap. Card data is also personal data. In the event of a breach, this results in two concurrent issues: a violation of the card security standard and a violation of personal data protection, with all associated obligations.
Implementation Process
Determine the Payment Processing Method
This is the foundation and, at the same time, the most effective way to reduce the burden. When redirecting to a payment gateway or using an iframe embedded directly from the provider, card details do not pass through the e-shop’s server but go straight to the gateway. This significantly reduces the scope of your obligations, and often the simplest self-assessment questionnaire is sufficient.
Verify your classification and questionnaire type
You must verify the classification level and the applicable SAQ type directly with the bank or payment gateway. It is their obligation to provide this information.
Take inventory of your scripts
Review everything running on order and payment pages—including analytics, chat tools, tracking pixels, and external widgets. Remove any unnecessary scripts. Every third-party script on a payment page is a potential entry point for an attacker.
Check basic security hygiene
This includes HTTPS across the entire website, multi-factor authentication wherever possible, sufficiently long passwords, and regular updates to both the system and the payment module. It is precisely on these fundamentals that most e-shops fail.
For more complex solutions, seek expert consultation
For higher transaction volumes or more complex technical solutions, it’s worth consulting with a PCI DSS expert. The cost of a consultation is lower than the cost associated with a single incident.