12 Practices to Protect Card Data, and What PCI DSS v4.0.1 Asks for Each

The PCI Security Standards Council's small merchant task force published twelve practices in its Guide to Safe Payments (version 2.0, August 2018). They are written for a business owner, not an assessor, and they predate PCI DSS v4.0.1. This article keeps the Council's twelve and sets each against what v4.0.1 actually requires, with the numbers the standard uses, so the practice can be checked rather than just agreed with.

How many of these requirements apply to a given merchant depends on how it takes payments. A merchant whose card data never touches its own systems validates against a short SAQ; Find my SAQ works out which.

1. Use strong passwords and change default ones

• Where a password is the authentication factor, it must be at least 12 characters (8 only where a system cannot support 12) and contain both letters and numbers (8.3.6). The standard does not require symbols or mixed case.
• A password that is the only factor must change at least every 90 days, unless the account's security posture is analysed dynamically instead (8.3.9).
• Accounts lock after no more than 10 failed attempts, for at least 30 minutes or until the user's identity is confirmed (8.3.4), and a session idle for more than 15 minutes needs re-authentication (8.2.8).
• Vendor default accounts keep a changed password if they are used and are removed or disabled if they are not (2.2.2). That includes terminals, routers and wireless access points.

2. Protect card data and store only what you need

Account data has two parts with different rules:

• Cardholder data (the PAN, cardholder name, expiry date and service code) may be stored if there is a business need. The PAN must be rendered unreadable wherever it is stored, by a keyed hash, truncation, index tokens or strong cryptography (3.5.1); encryption is one option, not the only one.
• Sensitive authentication data (full track data, the card verification code, the PIN and PIN block) must not be kept once authorisation completes, even encrypted (3.3.1). Issuers are the only exception.

Retention and disposal policies must limit how much is kept and for how long, and cover every place account data is stored (3.2.1). The first step is finding those places, including spreadsheets, email and paper order forms.

3. Inspect payment terminals for tampering

9.5.1 requires a list of the point-of-interaction devices that read cards, periodic inspection of them for tampering or substitution, and training for the staff who use them. 9.5.1.2 covers the inspection itself. The standard does not fix a daily or weekly schedule: how often, and how thoroughly, is set by the entity's targeted risk analysis under 9.5.1.2.1. A device in a public, unattended spot warrants more frequent checks than one behind a counter.

4. Use trusted business partners

Anyone who stores, processes or transmits card data for you, or could affect its security, is a third-party service provider. Requirement 12.8 asks for:

• a list of them and what each provides (12.8.1), and a written agreement in which each acknowledges its responsibility for the account data it handles (12.8.2);
• due diligence before engaging one (12.8.3);
• a check of each one's PCI DSS compliance status at least once every 12 months (12.8.4);
• a record of which requirements each manages, which you manage, and which are shared (12.8.5).

Should my service provider be PCI compliant? covers this in more depth.

5. Install patches from your vendors

6.3.3 sets one fixed deadline: patches for vulnerabilities ranked critical must be installed within one month of release. Everything else is patched within a timeframe the entity sets from its own risk ranking under 6.3.1, which also requires watching industry sources for new vulnerabilities. A shorter internal target is fine; a longer one for critical patches is not.

6. Protect in-house access to card data

• Access follows a defined model based on job function and least privilege (7.2.1).
• Every user account and its privileges, including vendor accounts, are reviewed at least once every six months (7.2.4).
• Multi-factor authentication is required for all non-console access into the cardholder data environment (8.4.2) and for remote access from outside the network that could reach it (8.4.3).

7. Don't give hackers easy access to your systems

This is hardening. Configuration standards must cover every system component and follow industry-accepted hardening standards or vendor recommendations (2.2.1), and only necessary services, protocols and functions may be enabled (2.2.4). The Council's guide singles out remote access software left running on payment systems, a common route into small merchants.

8. Use anti-virus software

The standard's term is anti-malware. A solution must be deployed on every system component except those a periodic evaluation finds not at risk (5.2.1), kept current by automatic updates (5.3.1), and run periodic and real-time scans or continuous behavioural analysis (5.3.2). The anti-malware entry covers the rest of Requirement 5.

9. Scan for vulnerabilities and fix issues

• Internal scans at least once every three months, authenticated (11.3.1.2), with high-risk and critical findings resolved and rescanned (11.3.1).
• External scans at least once every three months by an Approved Scanning Vendor, until the scan passes (11.3.2).

Both are also required after a significant change. A merchant that has no internet-facing systems of its own should check its SAQ for which scans apply.

10. Use secure payment terminals and solutions

• Terminals approved under the Council's PTS programme are designed to resist tampering.
• A listed point-to-point encryption (P2PE) solution encrypts card data in the terminal, so the merchant's systems never see it in the clear and the merchant may be eligible for the much shorter SAQ P2PE.
• EMV chip cuts counterfeit fraud but does not reduce PCI DSS scope.
• Payment software is now validated under the Council's Software Security Framework. PA-DSS, which the guide mentions, was retired in October 2022.

11. Protect your business from the internet

Network security controls sit between trusted and untrusted networks (1.4.1), and traffic into the cardholder data environment is limited to what is necessary, with everything else denied (1.3.1). Public-facing web applications need an automated solution that detects and prevents web-based attacks (6.4.2). Segmentation decides how much of the network all this applies to; see Using network segmentation to reduce PCI DSS scope.

12. Make your data useless to criminals

Data a criminal cannot read is worth little to them. For stored PAN, that means one of the methods in 3.5.1. For PAN sent over open, public networks, 4.2.1 requires strong cryptography, which the Council defines by effective key strength (at least 112 bits) rather than by naming an algorithm. Where encryption is used, the keys need managing: 3.6.1 restricts and separates them, and 3.7.4 requires each key type to have a defined cryptoperiod and a process for changing it. Tokenization replaces the PAN with a value that is useless without the vault. Masking is different: it limits what a screen or receipt shows (3.4.1) and does nothing for what is stored.

Where to go next

The PCI DSS v4.0.1 overview links every requirement, and each control page lists what an assessor will examine. For staff who take payments at a counter or by phone, Front Office Payment Security covers these habits in seven modules.