5. Decoding PCI DSS: 12 Months of Practical Security & Common Sense

May. Domain 5: Protecting Against the Invisible Plague

The Summary: What are we actually doing?

If Domain 1 was our fence, Domain 2 was our lock, Domain 3 was our vault, and Domain 4 was the armoured messenger, Domain 5 is the castle’s immune system. The walls are up, the gates are guarded, and the messages are sealed — but something has already slipped inside. It arrived in a phishing email opened by the CFO, in a USB drive plugged in by a contractor, in a container image pulled from a public registry by a developer who was in a hurry.

Requirement 5 is fundamentally about ensuring that malicious software — whether it is ransomware, spyware, a rootkit, or a weaponised macro in a spreadsheet — cannot take root in your Cardholder Data Environment. In PCI DSS v4.0.1, the scope of this domain has grown meaningfully beyond ‘install antivirus.’ It now explicitly demands:

• Continuous or periodic detection across all applicable systems, including a documented and recurring evaluation of systems excluded from anti-malware controls.
• Protection for removable electronic media, which remains a surprisingly common attack vector.
• Formal anti-phishing mechanisms — a new, standalone requirement in v4.0 that many organisations are still scrambling to operationalise.
• Audit logs from anti-malware solutions that are retained and available for review, closing the loop with Domain 10.

The objective is not to make your environment impenetrable. That is an illusion. The objective is to ensure that if something malicious enters, you detect it quickly, contain it, and have the evidence to understand what happened.

Three Common Pitfalls (Which We Often Encounter)

1. The “Not Commonly Affected” Loophole (Req 5.2.3)

PCI DSS allows organisations to exclude certain systems from anti-malware controls if those systems are “not commonly affected by malicious software.” Historically, this has covered mainframes, mid-range systems, and certain hardened Unix configurations. The standard does not remove this carve-out in v4.0.1 — but it sharpens the obligation significantly. The exclusion must be documented, justified with specific technical rationale, and re-evaluated on a periodic basis. We regularly encounter organisations that applied this exclusion once, years ago, and never revisited it. Their environment has since grown to include containerised workloads, Kubernetes nodes, and serverless functions — none of which appeared in the original evaluation. The threat landscape has also shifted: Linux-targeting malware and ESXi ransomware families have grown dramatically in prevalence. “Not commonly affected” is not a permanent status; it is a claim you must continuously defend.

2. Anti-Malware Deployed but Not Governed (Reqs 5.3.x)

Having the tool is not the same as operating the control. Req 5.3.5 requires that anti-malware cannot be disabled or altered by users unless explicitly authorised — and any such authorisation must be time-limited and documented. In environments where developers hold local administrator rights (a very common situation), we frequently find that anti-malware is technically installed but users can and do disable it “just for this one deployment.” Req 5.3.4 adds another layer: logs from anti-malware solutions must be retained and available for review. The most common failure is not that logging is disabled, but that the logs are generated locally and never forwarded to the SIEM. Even if the tool is running perfectly, the audit trail does not exist where the assessor expects to find it.

3. Anti-Phishing as an Afterthought (Req 5.4.1)

Requirement 5.4.1 is new in v4.0 and is the single most frequently underestimated item in Domain 5. The requirement implies a defined, operating process: email gateway filtering with anti-phishing rules configured, URL sandboxing or reputation checking, documented phishing simulation testing with results tracked, and user awareness training that specifically addresses phishing at a frequency that reflects your risk. Organisations that have all of these tools deployed but cannot produce evidence of the process operating are in the same position as organisations that have nothing. The assessor will ask to see the phishing simulation results. Have them ready.

The Cloud Reality Check

In AWS, Azure, and GCP, Requirement 5 becomes a question of control equivalence rather than traditional tool deployment. For containerised and serverless workloads, the right question is not “where is the antivirus?” — it is “what is the control that performs the malware-detection function for this workload, and how do I demonstrate it is operating?”

• AWS: Amazon GuardDuty provides threat detection including malware scanning for EC2 instances and S3 objects. Malware Protection for EC2 is a distinct feature that must be explicitly enabled. None of this is on by default. The guest operating system remains your responsibility.
• Azure: Microsoft Defender for Cloud covers anti-malware for VMs, containers, and serverless under its Defender plans — but these plans must be enabled per subscription and per resource type. Multi-subscription enterprises almost always have at least one subscription where coverage has drifted.
• GCP: Security Command Center Premium provides threat detection. Virtual Machine Threat Detection addresses malware scanning for Compute Engine instances. Coverage is opt-in and per-project. Container analysis handles image vulnerabilities as a separate concern.

For IaaS virtual machines across all providers: the cloud provider secures the hypervisor; you secure what runs on it. We regularly encounter legacy VM instances that predate an organisation’s shift to serverless — still running, still in scope, entirely without anti-malware because everyone assumed it was covered by the shared responsibility model.

Assessment Tips & Tricks

• Bring the Exclusion List First: Walk into the opening meeting with your “not commonly affected” system list, dated within the last 12 months, with written technical rationale per system category. This closes Req 5.2.3 in the first thirty minutes and signals to the assessor that you have done your homework.
• Map Anti-Malware Logs to Your SIEM: Before the assessment, verify that your anti-malware tool’s logs are flowing into your centralised log management system. Run a test event and confirm it appears in the SIEM with the correct timestamp. This simultaneously satisfies Req 5.3.4 and Req 10.5.
• Document the Anti-Phishing Process, Not Just the Tool: A one-page process document covering your email filtering controls, phishing simulation frequency and review process, and training follow-up procedure is the evidence that satisfies Req 5.4.1 — not the vendor invoice for your email security platform.
• Lock Down the Kill Switch: Audit your endpoint management platform and confirm that anti-malware cannot be disabled without a time-boxed, approval-gated process. If developers hold local admin rights with no compensating control, resolve this before the assessment. Note that a strict QSA in a v4.0.1 environment will push hard for technical prevention (e.g., tamper protection enabled via cloud console, where local admins still cannot kill the process) rather than just a policy-based compensating control.

Typical Evidence Required

PCI DSS Requirement	Evidence Required	Tryggr’s Comment
5.1.1, 5.1.2	Anti-malware policy, Roles and responsibility definitions for Req 5	Roles are ideally embedded in your ISMS or job descriptions — not a standalone document nobody reads.
5.2.1	Anti-malware solution inventory confirming coverage across all applicable systems	Bring a system inventory alongside the deployment evidence. Coverage gaps are obvious when both lists are on the same screen.
5.2.2	Anti-malware product documentation / configuration showing full protection scope	Confirm it addresses ransomware, spyware, and rootkits — a basic AV that only catches known signatures will not satisfy this.
5.2.3	Exclusion list for systems not requiring anti-malware, with dated periodic evaluation records and written rationale	The most commonly failed evidence item in Req 5. The evaluation must be dated, reasoned, and recurring — not a one-time note from two years ago.
5.3.1	Anti-malware update logs / auto-update configuration	Definitions updated within vendor-recommended intervals. ‘We update when we remember’ is not a control.
5.3.2	Scan schedule configuration and execution evidence, or continuous behavioural analysis config	Show both the configuration and evidence that it ran. A schedule nobody checks is not a control.
5.3.3	Policy / configuration showing anti-malware applied to removable media	USB auto-run disabled plus scan on insert is the minimum. Removable media is the forgotten vector.
5.3.4	Anti-malware audit log samples and SIEM ingestion evidence	Logs generated but never collected are a Req 10 finding waiting to happen. Show the pipeline, not just the local log file.
5.3.5	Evidence that users cannot disable anti-malware without authorisation (e.g. GPO, MDM config, RBAC)	Screenshots of policy enforcement. If local admin rights exist, document the compensating control.
5.4.1	Anti-phishing process document plus operational evidence: email filter config, phishing simulation results, training records	A policy is not enough. Show the tooling config AND the training records AND the simulation testing cadence with results.

Need assistance?

If you need any help while preparing for your assessment or would like to have quick call about PCI DSS, 3DS, PIN Security, P2PE or DORA compliance, please feel free to reach out to us at Trausta. We’re 
always here to ensure a smooth and secure compliance process.

Next Month: Domain 6 – Secure Systems & Software (The Developer’s Nightmare)