What PCI DSS 5.2 asks for and why assessors look hard at it
When a QSA or internal assessor asks for proof that malware protection covers the cardholder data environment (CDE), they are testing whether you can show every system that could carry malware into card data is either protected or formally justified as not at risk. Requirement 5.2 has four sub-requirements. Under 5.2.1, anti-malware must be deployed on all system components except those evaluated as not at risk. Under 5.2.2, that anti-malware must detect and remove, block or contain all known malware types. Under 5.2.3, the components excluded from anti-malware must be evaluated periodically to confirm they are still not at risk. Under 5.2.3.1, the frequency of that evaluation must be set by a targeted risk analysis.
The malware risk is straightforward. A compromised workstation, server or file share inside the CDE can give an attacker a path to stored or transmitted account data, and a single infected system that sits outside anti-malware coverage is an easy place for that compromise to start. Assessors therefore start with the inventory: they compare your list of components not at risk against the systems that actually have no anti-malware deployed. Most gaps appear in the "not at risk" exception. Teams often document it once, for a group of hosts, and never revisit it when operating systems, roles or network paths change. A system that was once isolated may now sync files from a corporate network, and the justification no longer holds.
Requirement 5.2.3.1 became mandatory on 31 March 2025, so it is no longer a future-dated item. The frequency for re-evaluating not-at-risk systems must come from a targeted risk analysis performed under Requirement 12.3.1, and the analysis must record the reasoning behind the chosen interval. Confirm with your QSA which version of the risk analysis they expect to see and whether they want the evaluation results stored alongside it. Start by building one register that lists each not-at-risk component, its justification, its last evaluation date and the interval set by the analysis, then compare that register against your asset inventory before the assessment begins.
Which systems and teams fall under anti-malware scope for 5.2
Requirement 5.2 applies to every system component in the cardholder data environment and in connected systems that could affect it, unless the entity documents a reasoned not-at-risk decision. The cards below show which components usually fall in scope, which teams own them, and which scoping decisions change the anti-malware work.
Servers in the CDE
Application, database and middleware servers that store, process or transmit account data are the core anti-malware population for 5.2. Check that the inventory covers virtual machines and physical hosts alike, and that each one either runs anti-malware or appears on the documented not-at-risk list. Infrastructure or platform teams usually own these hosts, while application owners should confirm which workloads run on them.
Workstations with CDE access
Administrator and operator workstations that reach the CDE or its management consoles are in scope even when they do not hold card data. Users often work from laptops that move between networks, so confirm the anti-malware agent reports in when the device is off the corporate network. End-user computing or desktop support teams typically own the build and enrollment of these devices.
Connected systems that could affect the CDE
Directory servers, jump hosts, backup systems and monitoring tools that connect to the CDE can introduce malware even though they hold no account data. Requirement 5.2 reaches systems that can affect CDE security, so map every connection path during scoping. Network and security operations teams are usually the right owners to confirm which connected systems require protection.
Cloud workloads and containers
Virtual machines, managed container nodes and serverless functions in the payment flow each need a documented decision. Container images and short-lived instances may not accept a conventional agent, so confirm whether protection happens at the host, the image registry or the runtime. Cloud platform teams and DevOps engineers typically own these components, and the answer should be written into the not-at-risk evaluation.
Segmentation boundaries
A segmentation decision that removes a system from the CDE also removes it from the 5.2 population, but only if the segmentation holds under test. Document each boundary, the controls that enforce it and the evidence that supports it. Network security teams and the assessor both need to agree on the boundary before the anti-malware inventory is finalized.
Shared and third-party hosted components
Shared hosting platforms, managed services and third-party hosted components may run in environments the organization does not directly control. Obtain written evidence from the provider showing who maintains anti-malware on each component, and record that responsibility in the scope documentation. Vendor management and procurement teams should ask for this evidence before contracts are signed.
How a QSA tests malware prevention under 5.2
This table compares what a QSA does for each sub-requirement of 5.2, the evidence they ask to see, and where entities usually fall short. Read it as a checklist of what to have ready before an assessment starts, since the not-at-risk list and its review cycle are where most gaps appear.
| Sub-requirement | How the QSA tests it | Evidence usually requested | Common findings |
|---|---|---|---|
| 5.2.1 Anti-malware coverage | Samples in-scope system components and compares them with the asset inventory to confirm anti-malware is deployed or the component is documented as not at risk. | Asset inventory, anti-malware deployment reports or console exports, and the list of exceptions. | Servers or build hosts missing agents, and inventories that do not match what is actually running. |
| 5.2.2 Detection and removal | Confirms the anti-malware solution is configured to detect and remove, block or contain all known malware types, and reviews vendor coverage claims against the configuration. | Product configuration exports, signature or detection engine version details, and vendor documentation for malware coverage. | Default settings accepted without review, and no evidence that detection covers all malware types the entity relies on. |
| 5.2.3 Not-at-risk components | Compares the documented list of components not at risk for malware with components that have no anti-malware deployed. Any component on neither list is a gap. | Documented not-at-risk list with the rationale for each entry, and a current list of components without anti-malware. | Undocumented exclusions, and components with no agent that appear nowhere on the not-at-risk list. |
| 5.2.3.1 Review frequency | Checks that the evaluation frequency for not-at-risk components is set by a targeted risk analysis under 12.3.1, and that the evaluations happened on that schedule. | Targeted risk analysis record, the evaluation frequency it sets, and dated records of each completed evaluation. | A frequency copied from another entity, risk analyses that do not explain the chosen interval, and overdue evaluations. |
How to implement 5.2 from inventory to targeted risk analysis
This sequence takes an organization from an unknown set of systems to a documented anti-malware position, where every component is either protected or formally justified as not at risk, with an evaluation frequency set through a targeted risk analysis. Each step produces an artifact an assessor can test against Requirement 5.2.
Build a complete component inventory
Start by listing every system component in or connected to the cardholder data environment, including servers, workstations, virtual machines, containers, network devices and cloud instances. Asset tooling such as GLPI can hold this list, populated manually or through its native inventory agent, and endpoint telemetry from tools like Wazuh Syscollector can confirm what is actually running. Your team owns this step, and the output is a reconciled inventory with an owner and a location for each component. Confirm the inventory is complete by comparing it against network diagrams and cloud account listings before moving on.
Deploy or confirm anti-malware coverage
For every component that can be affected by malware, confirm that anti-malware is installed, running and reporting to a central console. Where coverage is missing, deploy it or record a planned change under your change process. Your internal operations or endpoint team typically performs this work, and a third party may assist with deployment. The output is a coverage report that maps each in-scope component to its anti-malware agent, with gaps listed as open items with owners.
Verify detection of known malware types
Requirement 5.2.2 asks that anti-malware detect and remove, block or contain all known malware types. Test this with controlled samples or vendor-supplied test methods in a non-production environment, and confirm the vendor's documentation covers the malware categories relevant to your platforms. Ask your anti-malware vendor to state in writing which malware types its product detects and how it responds to each. The output is a test record showing the date, the method, the samples or tests used, and the result for each platform type.
Document each component not at risk with its rationale
Some components may be formally evaluated as not at risk for malware, for example certain systems with no general-purpose function or no exposure to file transfer and execution. For each such component, write a rationale that cites its function, its network position, its patch and access controls, and why malware is not expected to reach it. Your security lead approves each entry. The output is a documented list of not-at-risk components with individual rationales, which assessors will compare with the components that have no anti-malware deployed.
Define the evaluation frequency in the targeted risk analysis
Requirement 5.2.3.1 asks that the frequency of evaluating not-at-risk components be defined in a targeted risk analysis performed under Requirement 12.3.1. Document the threats considered, the components in scope of the analysis, the factors that could change the risk position, and the frequency you chose with its justification. Your risk owner signs off on the analysis. The output is a signed targeted risk analysis that names the evaluation frequency and links to the not-at-risk list.
Schedule and record repeat evaluations
Put the evaluation frequency from the targeted risk analysis onto a recurring calendar, assign a named owner, and define what each evaluation checks, including whether any not-at-risk component has changed function, gained exposure or received anti-malware. Record the result of each evaluation and update the rationale or the risk analysis when conditions change. The output is a dated evaluation log and, where needed, revised entries in the not-at-risk list, which together show the evaluation happens as the analysis said it would.
How the not-at-risk exception works in practice
The not-at-risk exception under Requirement 5.2 is a documented decision, not a default. An entity starts with an inventory of every system component in scope, then records which components it evaluates as not at risk for malware and why. Those components are the only ones allowed to run without anti-malware. The assessor will compare that documented list against the components that actually have no anti-malware deployed, so the list and the real estate must match. Ask your team to confirm that the inventory is generated from a source that reflects reality, such as an asset management record or a native inventory agent, rather than a spreadsheet that was last edited at audit time.
A defensible rationale names the component, the characteristics that make malware unlikely to reach or persist on it, and the compensating facts that support the judgment. For example, a hardened, read-only appliance with no user accounts, no general-purpose software and no inbound file transfer path may be a reasonable candidate. A general-purpose workstation or a server that accepts uploaded files usually is not. (Illustrative only: a payment terminal manufacturer's firmware that cannot execute unsigned code may support an exception, but the entity still has to show how it verified that property.) Record who approved the decision, the date, and the evidence reviewed. Vague reasons such as "low risk" or "not targeted" will not hold up under assessment.
The list must stay current because the exception depends on conditions that change. A new software package, a reconfigured service, a repurposed server or an added file share can turn a not-at-risk component into one that needs protection. The frequency of re-evaluation is not fixed by the standard. Under Requirement 5.2.3.1, the entity sets it through a targeted risk analysis performed under Requirement 12.3.1, and that analysis has to justify the interval it chooses. Confirm with your QSA which change events trigger an earlier review, and keep the risk analysis, the approval record and the last inventory comparison together so the next assessment can trace each decision.
Evidence that passes a 5.2 review and how to keep it current
A 5.2 review comes down to whether your component inventory, your not-at-risk decisions and your detection results agree with each other. Each artifact below feeds the next, so a gap in one shows up quickly in the others.
Component inventory
The assessor starts with the full list of system components in scope and checks every entry against an anti-malware deployment or a documented not-at-risk decision. Keep the inventory tied to your asset management records, so new servers, containers and endpoints appear when they are provisioned. Ask who updates it, how often it reconciles against cloud and directory data, and how decommissioned hosts are removed. A stale inventory is the most common reason a 5.2.1 test fails before anyone looks at a scanner.
Anti-malware deployment reports
Export reports showing which components run the anti-malware agent, the agent version, the signature or definition date, and the last successful scan. Check that the report covers every system in the inventory, not only the ones your console manages. Schedule the export so you hold a dated copy each month, since assessors ask for evidence from the period under review, not the current console state.
Detection test results
Keep records showing that the anti-malware detects and removes, blocks or contains known malware types. Use controlled test files or an approved test method, run them on a sample of each platform type, and record the date, the tester, the result and the remediation ticket for any miss. Repeat the test after each major agent or policy change so the record reflects the configuration in place today.
Documented not-at-risk list with rationale
Maintain a list of components you have evaluated as not at risk for malware, with a written reason for each. The assessor compares this list with the components that have no anti-malware deployed, so any unlisted host without an agent becomes a finding. Record the platform characteristics that support each decision, such as a locked-down appliance or an immutable image, and name the owner who approved it. Review entries when a component's function, network position or software changes.
Targeted risk analysis for re-evaluation
Requirement 5.2.3.1 asks for the frequency of not-at-risk evaluations to be set through a targeted risk analysis under Requirement 12.3.1. Document the threats considered, the systems affected, the factors that drove the chosen frequency, and the approver. Revisit the analysis when the threat landscape or your architecture changes, and confirm the stated frequency is the one your team actually follows.
Dated re-evaluation records
Each scheduled evaluation of a not-at-risk component should produce a dated record: who performed it, what was checked, whether the component still qualifies and any change made. Store these with the inventory and the risk analysis so one review can trace a component from its exemption to its latest check. Missing or undated records for a period under review are usually treated as the evaluation not having happened.
What meeting 5.2 costs in money and effort
This table breaks down the money and effort behind Requirement 5.2, separating one-time work from recurring work and naming who is paid for each part. Read it as a checklist of cost lines to request in a quote, since no supplied figures set specific amounts. The main takeaway is that licensing is only one line, and exception handling and recurring risk analysis often drive effort more than tool price.
| Cost component | One-time or recurring | Who is paid or who does the work | What drives it up or down |
|---|---|---|---|
| Anti-malware licensing | Recurring, usually per endpoint or per year | Commercial vendor or open-source support provider | Fleet size and number of endpoint types; self-hosted open-source engines can remove per-seat license lines but still need operations time |
| Deployment and configuration engineering | One-time, with periodic rework | Internal engineers or an implementation partner under a written scope | Number of operating system builds, container images and cloud workloads that need coverage |
| Exception engineering for components not at risk | One-time per component, then recurring review | Internal security team, documented under Requirement 12.3.1 analysis | Number of systems excluded from anti-malware; each exclusion needs a documented rationale and evaluation |
| Targeted risk analysis for 5.2.3.1 frequency | Recurring, at the interval the entity sets | Internal risk or compliance staff, or an external consultant | Scope complexity, number of component classes, and how often the threat landscape changes for each class |
| Inventory upkeep | Recurring | Asset owners and platform engineers | Rate of change in hosts and software; automated inventory collection reduces manual reconciliation |
| Assessor sampling during validation | Recurring, at each assessment cycle | Qualified Security Assessor or the entity's assessor under its validation method | Number of components in scope and the quality of the evidence package prepared in advance |
| Optional external review | Optional, one-time or periodic | Independent consultant; the assessor cannot design the controls it later tests | Gaps found in internal readiness checks and the complexity of exception and risk documentation |
| Ongoing monitoring of malware evidence | Recurring | Security operations staff | Alert volume, log retention settings and the number of platforms that must report to one console |
Who owns 5.2 and what an implementation partner can take on
Your organization owns Requirement 5.2 in full. The entity decides which system components are at risk for malware, which anti-malware mechanisms apply to them, how the known-malware detection and removal behaves, and how often components deemed not at risk are re-evaluated. Those decisions must be documented and approved by people accountable for the cardholder data environment. A partner can draft the material, but it cannot make the call on your behalf.
- Component risk decisions: Decide which systems are not at risk for malware and record the reasoning for each.
- Targeted risk analysis: Own the analysis that sets the re-evaluation frequency for 5.2.3.1, performed under Requirement 12.3.1.
- Anti-malware choices: Select and approve the products, configurations and operating model for components that run them.
- Exception handling: Approve any deviation and track it to closure.
- Sign-off and review: Keep named owners accountable for the evidence and its periodic review.
Before the assessment, confirm that each decision has a named approver, a date and a link to the supporting evidence.
An implementation partner can prepare the systems and records that let your team make and prove these decisions. In practice this usually means building the inventory of system components, deploying or configuring inventory and monitoring tooling, collecting evidence on a schedule and drafting documentation for your review. Because a partner sets up the environment, it is not the party that judges whether the environment passes. That judgment belongs to your team and, later, to the assessor.
- Inventory tooling: Configure asset inventory so the list of components with and without anti-malware can be compared, as Requirement 5.2.3 testing expects.
- Evidence collection: Set up scheduled queries and exports that show anti-malware presence and state across the fleet.
- Documentation drafts: Prepare the not-at-risk register, procedure drafts and evidence indexes for your approval.
- Remediation support: Carry out agreed fixes when your team has already decided what must change.
- Handover: Train your staff to run and interpret the tooling after the engagement closes.
Confirm in the written scope which deliverables the partner owns, which your team signs, and who maintains the tooling after handover.
A Qualified Security Assessor tests the requirement and issues the Report on Compliance when the assessment is a ROC. The QSA examines the documented decisions, samples the inventory and checks the anti-malware state against your evidence. The QSA reaches its own conclusion, and the report belongs to the QSA, not to your organization or to any consultant. For a self-assessment, the same ownership principle applies to the completed questionnaire and its Attestation of Compliance.
- Testing: Compare the documented not-at-risk list with components lacking anti-malware, which is the expected method for Requirement 5.2.3.
- Sampling: Select components and time periods to confirm the evidence reflects actual operation.
- Reporting: Issue the ROC and document findings in the assessor's own words.
- Independence limits: A firm that designed the controls or ran the remediation should not also certify the same controls without the independence rules applying.
- Certificates: Expect no certificate substitute, since the standard relies on the ROC or the Attestation of Compliance.
Ask the assessor early which artifacts it will sample so your team and any partner collect them in the right form.
Open-source tools that produce inventory and endpoint evidence for 5.2
Requirement 5.2 asks you to show which systems run anti-malware, which are formally judged not at risk, and how that judgment is rechecked. The tools below do not replace an anti-malware product. They produce the inventory, endpoint state and fleet-wide query results that let you prove the scope and the periodic checks.
osquery for fleet-wide endpoint queries
osquery exposes running processes, loaded kernel modules, open network connections, browser plugins and file hashes as SQL tables. Its osqueryd daemon schedules those queries across an entire fleet, so you can show what runs on each host at a set interval. For 5.2.3, use it to check whether systems on your not-at-risk list show unexpected processes or modules. Confirm which platforms and tables your fleet needs, and confirm the license: osquery is Apache-2.0 OR GPL-2.0-only, so pick the option your legal team accepts.
Velociraptor hunts across endpoints
Velociraptor collects forensic artifacts defined in VQL from endpoints. A hunt runs one or more artifacts across a group of systems, schedules offline machines to collect when they reconnect, and creates a notebook for analyzing the combined results. Use hunts to test a population of systems at once, such as every host on the not-at-risk list, and keep the notebook as dated evidence. Velociraptor is licensed AGPL-3.0-only, which carries network-use obligations if you modify and host it for others. Have counsel review that before deployment.
GLPI for asset inventory
GLPI's Assets module manages computers, software, network equipment, printers and other devices, entered by hand or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. This inventory is the baseline for 5.2.1 and 5.2.3: every system component needs an entry, and the not-at-risk list needs a matching record. Check that the inventory covers cardholder data environment systems and their owners, and that stale entries are removed. GLPI is licensed GPL-3.0-or-later.
Wazuh Syscollector for installed software
The Wazuh Syscollector module collects hardware, operating system, installed software, open ports, running processes, services and Windows updates from each endpoint and stores them in the Wazuh indexer. Dashboard reports give you a timestamped view of what each host runs, which supports the periodic evaluation in 5.2.3. Confirm whether your environment is covered by the module before relying on it, and note that Wazuh is licensed GPL-2.0-only. Syscollector shows what is installed. It does not by itself prove that anti-malware is active on a host.
Confirming anti-malware coverage
None of these tools is an anti-malware product by itself unless your team confirms that a specific component performs detection or removal. Treat them as evidence sources. Ask whether your anti-malware is deployed on every system outside the not-at-risk list, and whether a query or hunt can show that deployment state. Where it cannot, the gap must be recorded and closed through a separate control. Confirm each claim against your own environment and your assessor's expectations before you describe these tools in a report.
How much work is 5.2 and when should we bring in a partner?
What drives the cost and effort of meeting Requirement 5.2?
The effort depends mostly on how many system components you run, how many of them are in the cardholder data environment, and how much of that estate is already covered by anti-malware and inventory. Requirement 5.2 has two parts: anti-malware on every component, and a documented, risk-based evaluation of any component you say is not at risk. Costs fall into licensing or tooling, deployment and configuration, the one-time evaluation of not-at-risk components, and the recurring work of keeping coverage and evidence current. Ask any provider to price each of these separately so you can see which parts scale with fleet size.
Can our internal team handle Requirement 5.2 without outside help?
Often yes, if you have someone who owns endpoint inventory, can run a targeted risk analysis, and can show assessors current coverage reports. The harder parts are rarely the installation. They are keeping an accurate list of every component, documenting why a system is not at risk, and proving that the evaluation repeats at the frequency you set. If those tasks already sit with a team that can produce them on request, internal ownership is realistic. If inventory is incomplete or the CDE boundary is unclear, bring in help before the assessment window.
What does the work need from our team?
Expect to supply a few named owners and some dedicated time from each of them. You will need someone who maintains the asset inventory, an engineer who can deploy and configure anti-malware and any open-source telemetry, someone who owns the targeted risk analysis under Requirement 12.3.1, and a reviewer who can confirm the not-at-risk list against real systems. Your assessor will ask to see the process running, not only the policy, so plan for access to consoles, sample hosts and historic logs.
How long does preparation take for a small fleet compared with a large one?
Preparation time scales with the number of endpoints, the number of distinct operating systems, and the number of teams that administer them. A small, uniform fleet with a single management plane usually needs less time to inventory and cover than a large, mixed estate spread across data centers, cloud accounts and branch sites. Timing also depends on how much of the not-at-risk analysis must be built from scratch. Ask for a timeline that lists the discovery, deployment, evaluation and evidence phases with the drivers for each, rather than a single duration.
Can our QSA also implement the Requirement 5.2 controls for us?
Generally no. A Qualified Security Assessor evaluates whether your controls meet the standard, and assessor independence is part of how the report is trusted. An assessor who designs or deploys the controls they later test creates a conflict that the assessment process is designed to avoid. Keep implementation with your team or an implementation partner, and confirm with your QSA which tasks they consider acceptable before you engage anyone. Implementation partners prepare systems and evidence; only the assessor issues the Report on Compliance or Attestation of Compliance.
Is Requirement 5.2.3.1 mandatory now, and does it still count as future-dated?
Requirement 5.2.3.1 became mandatory on 31 March 2025, the date when the future-dated requirements of PCI DSS v4.0 took effect. Before that date, the requirements were best practices that could be marked not applicable. Confirm with your acquirer or the payment brand how they apply the requirement to your entity, because the PCI SSC does not enforce compliance itself. Any plan you build should treat the targeted risk analysis for not-at-risk components as an active obligation, not an optional improvement.
Can open-source tools produce the evidence for Requirement 5.2 in a self-hosted setup?
Open-source tools can help with the inventory and visibility side of the requirement, which is where many gaps appear. Wazuh's Syscollector can gather installed software, running processes, services and open ports from each endpoint into a dashboard, and GLPI's Assets module can hold the component inventory against which you compare anti-malware coverage. osquery can run scheduled queries across a fleet, and Velociraptor can run hunts across groups of systems. These tools support evidence but do not replace anti-malware itself, so confirm with your QSA which product and configuration will satisfy the assessor and how the output will be retained.
What should we ask for in a quote for Requirement 5.2 work?
Ask for a written scope that lists the in-scope systems, the anti-malware and inventory platforms, and the exact deliverables. Require separate line items for discovery, deployment, configuration, the targeted risk analysis, documentation, evidence packaging and any post-assessment support. Confirm who owns each deliverable, which items are one-time and which recur, what is excluded, and how changes to scope are priced. Also ask how the provider keeps the work independent of your QSA, and which tasks you will still need to perform yourself.
What this page does not cover
This page covers Requirement 5.2 only, which asks for anti-malware on system components and for a documented, risk-based evaluation of the components that are not at risk. The operation of that anti-malware, including automatic updates, scanning methods, removable media scanning, audit log retention and protection against users disabling it, is covered on the sibling page for 5.3. The policies, procedures and documented roles that govern the whole of Requirement 5 sit on the 5.1 page. Anti-phishing mechanisms for personnel, which are separate from the phishing awareness training in 12.6.3.1, are covered on the 5.4 page. Read those pages alongside this one, because an assessor will test the 5.2 component list against the 5.3 operating evidence and the 5.1 roles.
Responsibility for the requirement stays with your organization. DeployOpen can help plan and implement the inventory and detection tooling this requirement depends on, such as a self-hosted asset inventory and endpoint query or telemetry platform, and can prepare the component lists, risk analysis inputs and collected evidence that show how components were classified. DeployOpen does not decide which components are not at risk on your behalf, does not sign off the targeted risk analysis, and does not issue assessment reports or attestations. Only a Qualified Security Assessor (QSA) completes the Report on Compliance for an organization that must produce one, and the Attestation of Compliance is only valid when the entity and its assessor complete it on the official PCI SSC templates.
Before you start, confirm three things with your QSA and your payment brands: which validation route applies to your organization, whether the 5.2.3.1 frequency decision belongs in your targeted risk analysis under Requirement 12.3.1, and which evidence the assessor will accept for the not-at-risk list. Those answers determine the scope of any implementation work, so put them in writing before a fixed-scope engagement is agreed.
