What PCI DSS 5.3 asks anti-malware to do every day
Requirement 5.3 asks that anti-malware stays active, current and protected from users switching it off, with removable media scanned and audit logs kept. If a QSA or internal assessor has flagged 5.3, the practical question is what must run continuously on every in-scope system, and what evidence proves it did. The six sub-requirements (5.3.1 to 5.3.5, plus 5.3.2.1) break that into parts: the engine and signatures must update automatically (5.3.1), periodic scans or continuous behavioral analysis must run (5.3.2 and 5.3.2.1, where scan frequency comes from a targeted risk analysis), removable media must be checked when it is attached (5.3.3), audit logs must be enabled and retained (5.3.4), and anti-malware may be disabled only in documented, authorized, time-limited cases (5.3.5). Confirm the exact wording of each sub-requirement in the current standard, since v4.0.1 is the only active version and 5.3.3 became mandatory on 31 March 2025.
The main risk is silent failure. An agent can stop reporting, fall behind on signatures, or lose its service after a failed upgrade, and nothing visible breaks until an assessor asks for logs covering a specific period. Hosts that are offline for weeks, virtual machines that are cloned from old images, and servers where an engineer stops the agent during troubleshooting and forgets to restart it all produce gaps that look normal on a dashboard. A useful first step is to ask your team for a count of in-scope systems that have not reported an update or scan within your defined window, and to confirm who receives alerts when that count is not zero.
Mixed estates make this harder. Windows, Linux and container hosts often need different agents, and a single console may not cover all of them. Offline hosts need a plan for catching up when they reconnect. For the disabling control in 5.3.5, decide in advance who may approve a temporary exception, how long it may last, and how the approval is recorded, because an undocumented stop during an incident is the finding assessors look for most. Open-source fleet tools such as osquery can query running processes and scheduled checks across hosts, which helps you confirm that the agent is present and running, though you should verify that any tool you choose produces evidence in the form your assessor accepts.
Which systems and scoping decisions change the 5.3 workload
Requirement 5.3 applies to every system that Requirement 5.2 says must carry anti-malware, so the size of the 5.3 job depends on where those systems sit and how they are run. The cards below cover the decisions that most often change how many hosts, media paths and log sources need controls, and what to confirm before the work is estimated.
Cardholder data environment components
Every component inside the cardholder data environment is a candidate for anti-malware, so the first 5.3 task is an accurate inventory of what sits there. Confirm which hosts, virtual machines, containers and jump servers are in the CDE, since each one needs the update, scanning and logging controls described in 5.3. Systems that are missed in the inventory are usually missed in the 5.3 evidence as well, which makes this the most common source of findings.
Connected systems and lateral paths
Systems that are not in the CDE but can reach it, such as corporate workstations, management networks and directory servers, can still affect the security of cardholder data. Whether they are in scope depends on the network controls and the scoping analysis your organization has documented. Ask your QSA which connected systems they expect to see in the anti-malware population, and record the reasoning for the ones you exclude.
Offline and air-gapped hosts
Hosts that cannot reach a vendor update service change how 5.3.1 is met. Updates must be delivered by a controlled internal path, such as a signed update repository or media transfer, and the update process must be documented and logged. Confirm how signature and engine updates reach each isolated host, how often they are applied, and how you show that a host ran a current version during the assessment period.
Linux servers and behavioral analysis
Linux servers often rely on behavioral analysis or file integrity checks instead of traditional on-access scanning, which shifts the evidence from scan reports to analysis logs and alerts. Before relying on this model, confirm with your assessor that the chosen method meets the periodic or continuous analysis wording in 5.3.2. Open-source tooling such as osquery can run scheduled queries across a fleet of hosts to capture process, kernel module and network evidence, but the analysis conclusions still need to be recorded and reviewed.
Scan frequency set by targeted risk analysis
Where 5.3.2.1 applies, the frequency of periodic scans is set by a targeted risk analysis that your organization performs and documents. This means the scan interval is a decision you own, not a fixed value, and it must be justified against the threats and system types in your environment. Ask who approves the analysis, how often it is repeated, and how changes in threat or system profile trigger a new review.
Removable media and shared cloud or containers
Removable media handling under 5.3.3 applies wherever USB devices, optical media or mounted volumes can be attached to in-scope systems, including ones that run in shared cloud or container platforms where the host is managed by someone else. Define which devices and mount points are allowed, confirm that scanning or behavioral analysis triggers on insertion or mount, and identify which party controls the host so responsibilities for evidence are clear. Third-party managed endpoints need the same questions answered in the contract.
How to implement 5.3 in a sequence that produces evidence
This sequence turns Requirement 5.3 into a set of configured, logged and documented controls that an assessor can sample, with each step leaving a specific artifact behind. It starts from the in-scope asset list and ends with a documented process for the rare cases where anti-malware is disabled.
Confirm the in-scope asset inventory from 5.2
Start from the list of system components where anti-malware is deployed, or formally evaluated as not at risk, under Requirement 5.2. Your team reconciles that list against the current asset inventory and the cardholder data environment diagram, so every component that needs 5.3 controls is named. The output is a reconciled inventory with an owner and a deployment status for each component. Confirm that the inventory matches the scope the assessor will accept, since 5.3 controls apply to every component on it.
Select the anti-malware mechanism and scan mode
Choose the anti-malware product and decide, per platform, whether it runs periodic scans, real-time scanning, continuous behavioral analysis, or a combination that Requirement 5.3 accepts. Record the reasoning for each platform, because the assessor will ask why a chosen mode fits the component. The output is a platform-by-platform decision record that names the mode, the product and the owner. Confirm the vendor's documentation shows the mode you need, and do not assume a capability that the product does not state.
Configure automatic updates for signatures and engines
Set the anti-malware engine and signature or detection content to update automatically on every in-scope component, and confirm that updates are pulled from a source your change process controls. Test the update path on a sample of hosts, including disconnected or infrequently connected systems. The output is a configuration baseline exported from the management console or configuration management tool, plus a sample showing the current signature version on several hosts.
Enable removable media scanning
Configure the anti-malware to scan removable electronic media automatically, or to analyze its behavior continuously, when media is inserted, connected or mounted. Test with a controlled test device on a representative sample of endpoints and servers that can accept removable media. The output is a test record showing the event, the scan or behavior result, and the alert or log generated. Keep the test device and procedure in the evidence file.
Enable audit logs and route them to retention
Turn on anti-malware audit logging for every component, and forward those logs to the central log platform so they are retained in line with Requirement 10.5.1. Verify that log entries cover scan activity, detections, updates and configuration changes, and that they cannot be altered by ordinary users. The output is a log sample pulled from the retention store, plus the retention setting and the forwarding configuration that produced it. Confirm the retention period with your Requirement 10 owner rather than assuming it.
Lock configuration against user disablement
Apply policy so that users without authority cannot stop, uninstall or change the anti-malware service, its configuration or its exclusions. Restrict administrative rights to a named group and log any attempt to alter the agent. The output is an exported policy or tamper protection setting, plus a test where a standard user attempts to disable the agent and the attempt is blocked and logged. Record who holds the administrative role.
Define the case-by-case disablement authorization process
Write the procedure for the rare occasions when anti-malware must be disabled, such as a vendor-approved maintenance window or a troubleshooting need. Requirement 5.3.5 expects management to document and authorize each case individually and for a limited time, so the procedure should require a request, a named approver, a start and end time, and a re-enable check. The output is an approved procedure and a sample authorization record. Confirm with your management and change advisory process how approvals are recorded.
Set the targeted risk analysis for scan frequency
Document a targeted risk analysis that sets how often periodic scans run on each component type, using the threat landscape and the component's exposure as inputs. Requirement 5.3.2.1 ties scan frequency to this analysis, so the frequency must be justified rather than copied from a default. The output is a signed risk analysis with the chosen frequencies, the reasons for them, and the date of the next review. Confirm the analysis is repeated when the environment or threats change, and link the scan schedule in the configuration baseline to it.
How a QSA tests Requirement 5.3
This table walks through each Requirement 5.3 sub-requirement and shows how a Qualified Security Assessor typically samples systems, observes configuration, requests evidence and where findings tend to appear. Read it as a preparation checklist: each row is a question the assessor will ask, and the evidence column is what should already exist before the assessment starts.
| Sub-requirement | How the QSA tests it | Evidence requested | Common findings |
|---|---|---|---|
| 5.3.1 Automatic updates | Selects a sample of in-scope systems and checks the anti-malware engine and signature or definition versions against the vendor's current release. Reviews the update mechanism configuration to confirm updates run without manual steps. | Central console export of agent versions and last update timestamps, update policy settings, and update logs for a sample period. | Agents with stale signatures on a subset of hosts, often servers that were excluded from the update policy and never re-added. |
| 5.3.2 Scan modes and frequency | Observes scan configuration on sampled systems to confirm periodic scans or real-time protection is active. Reviews the entity's targeted risk analysis that sets the scan frequency. | Scan schedules, real-time protection settings, the targeted risk analysis for scan frequency, and scan completion reports. | Scan schedules that exist on paper but are disabled on some hosts, or a risk analysis that does not justify the chosen frequency. |
| 5.3.2.1 Scan scope after system changes | Compares scan logs and change records to confirm periodic scans still run after major system changes or on a schedule matching the risk analysis. | Change records linked to scan job history and the scan frequency review. | Scans that stop after an image rebuild or migration and nobody notices until the next assessment. |
| 5.3.3 Removable media | Inserts or mounts test media on sampled systems, or reviews configuration showing automatic scanning or behavioral analysis on connection. Confirms the setting covers all removable media types the entity allows. | Configuration screenshots or exports for removable media handling, and test results showing a scan triggered on connection. | USB scanning enabled on workstations but not on kiosks, point-of-sale terminals or administrator jump hosts. |
| 5.3.4 Audit log enablement and retention | Confirms anti-malware logs are enabled on sampled systems and traces retention settings against the log retention rules used for Requirement 10. | Log configuration, sample log extracts, and the retention settings applied to anti-malware logs in the central store. | Logging disabled on newly provisioned hosts, or logs rotated out after a few days while the retention policy requires longer. |
| 5.3.5 Protection against disablement | Checks whether users can stop or uninstall the agent on sampled endpoints, and reviews tamper protection settings in the management console. Looks for any exception where protection was turned off. | Tamper protection settings, role-based console permissions, and documented, time-limited, management-authorized exceptions with the dates they ended. | Agents that local users can stop, or disablement exceptions with no authorization record or no end date. |
| Sampling and observation | Selects systems across system types, locations and owners, then observes live configuration instead of relying only on a policy document. Expect the sample to include recently changed hosts. | Asset inventory cross-checked against the agent console, so the assessor can see the population the sample came from. | Incomplete inventories, so agents on systems the entity did not know were in scope never get tested. |
Evidence that passes 5.3 and how to keep it current
An assessor testing Requirement 5.3 wants to see that anti-malware stayed active, current and tamper-resistant across the sampled systems over the whole assessment period, not only on the day of the review. The artifacts below connect configuration, live status, removable media handling, logging and exceptions, and each one needs a named owner and a refresh cadence agreed before the assessor arrives.
Configuration exports for update and scan settings
Export the effective anti-malware policy for each platform, showing signature or engine update frequency, scan schedules, real-time or behavioral analysis settings, and the risk-based scan frequency your targeted risk analysis produced. Assessors compare these exports against what your policy says, so a mismatch between the document and the console is a common finding. Refresh the export after every policy change and at least once per quarter, and have the security lead who owns the policy sign each version with its date.
Console and agent status across sampled systems
Produce a status report from the management console or agent fleet showing, for each sampled system, that the agent is installed, running, current on updates and reporting in recently. Assessors usually pick a sample from your system inventory, so reconcile the report against that inventory and explain any system without an agent by pointing to the 5.2 evaluation. Generate the report on the day of sampling and keep the query saved so the same view can be rerun, signed off by the operations manager who ran it.
Removable media scan logs
Keep logs showing that removable electronic media was scanned automatically, or that behavior was analyzed continuously, when media was inserted, connected or mounted. Requirement 5.3.3 has been mandatory since 31 March 2025, so logs from before that date will not satisfy it. Pull a sample of events from several endpoints and confirm each one shows a timestamp, device identifier and scan result. Review the sample monthly with the endpoint team lead.
Audit log samples and retention settings
Requirement 5.3.4 ties anti-malware audit logs to the retention expectations of Requirement 10.5.1, so show both the anti-malware log configuration, confirming logging is enabled, and the central retention setting that holds those logs. Provide sample entries covering alerts, updates and configuration changes. Ask the log platform owner to confirm retention configuration each quarter and to attach a dated screenshot or export to the evidence folder.
Tamper protection settings
Document the settings that stop users and local administrators from disabling, uninstalling or altering the anti-malware agent, including protected modes, uninstall passwords held centrally, and role restrictions in the console. Test the control by attempting a disablement on a non-production device and recording the blocked result. Repeat the test after each agent upgrade, since defaults can change, and have the endpoint security owner sign the test record.
Dated disablement authorizations
Requirement 5.3.5 allows anti-malware to be disabled only when management documents and authorizes the case, for a limited time. Keep a register of every exception with the reason, the affected system, the approving manager, start and end times, and the compensating monitoring used during the gap. Reconcile the register with the console history so no unexplained outage appears in the logs. Review open exceptions weekly and have the CISO or delegate sign the closed register at each quarter end.
How the anti-malware layer and its logs fit together
Requirement 5.3 is a monitoring requirement as much as a deployment requirement. An assessor will not accept anti-malware that is installed on paper but silently stopped on a subset of endpoints, so the design has to show that every in-scope system reports its status and events to a place where someone sees gaps. In practice the chain runs from the endpoint agent, which keeps its definitions current and records scans and blocks, to a central log store, where those events are retained and reviewed. Each link has a failure mode that the assessor will ask about: an agent that stopped, a definition update that never landed, or a log feed that broke quietly.
Retention is where 5.3.4 connects to the wider logging program. The anti-malware audit logs must be enabled and retained in line with Requirement 10.5.1, so the central store, its retention period and its protection from alteration are the same controls an assessor tests under Requirement 10. Confirm with your QSA which retention period and log-protection evidence they expect, and whether your SIEM or log platform is the system of record for anti-malware events. Keep the export or configuration that proves logging is enabled on every endpoint, because a dashboard screenshot alone rarely shows coverage.
Alerting closes the loop. Your team should decide in advance which conditions raise an alert: an agent that has stopped reporting, a host whose definitions are older than your policy allows, a scan that was disabled, or a configuration change that would let a user turn protection off. Under 5.3.5, any authorized temporary disablement should map to a documented decision with a time limit, so the alert should also tell you whether an open exception exists. Test the alerts by stopping the agent on a non-production host and confirming that the event reaches a person within the time your procedure states.
What meeting 5.3 costs in money and effort
This table breaks down what it takes to keep anti-malware running, updated, logged and tamper-resistant under Requirement 5.3, separating one-time setup from recurring work. Read each row for who is paid, what drives the cost up, and what to ask for in a quote. The main takeaway is that open-source tooling removes license spend, but configuration, log retention and evidence upkeep remain real effort that must be budgeted.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Commercial anti-malware licenses | Recurring (annual or per-endpoint) | Number of endpoints and servers in scope, feature tiers such as behavioral analysis, vendor support level | Scope systems tightly, confirm which in-scope components need a commercial agent, and ask for multi-year pricing terms in writing |
| Open-source agent licenses (osquery, Velociraptor) | None for the license itself | Licenses are not the cost; deployment, hosting and skilled staff are | Confirm each license terms fit your distribution model with counsel before rollout |
| Engineering time for configuration baselines | One-time, then recurring on change | Number of operating system images, server roles and removable media policies, and how many exceptions must be handled | Define a small set of standard baselines and reuse them across images and clusters |
| Log storage and retention | Recurring | Volume of anti-malware and audit events, retention period required by Requirement 10.5.1, and whether logs are forwarded to a central store | Filter noisy events at source, set retention to the documented requirement, and ask the provider how storage grows with fleet size |
| Evidence upkeep | Recurring | Frequency of update checks, scan reports, exception approvals under 5.3.5 and the time spent gathering proof for each review | Automate evidence exports and keep exception records in one place with dated approvals |
| External testing or review | Recurring, usually per engagement | Scope of the test, whether the review covers configuration or only sampled results, and the number of environments | Agree scope in writing before work starts and reuse prior baselines and test results |
| Auditor sampling | Recurring, per assessment cycle | Number of endpoints, removable media events and exceptions the assessor samples, and how well logs answer questions | Prepare sample-ready reports showing update status, scan coverage and logged disablement attempts |
| Implementation partner fees | One-time setup plus optional retainer | Fixed scope, number of platforms, integration with existing SIEM and asset inventory | Request a written scope with deliverables and separate setup from ongoing support |
Which self-hosted open-source tools support 5.3 evidence
osquery exposes operating system state as SQL tables, which makes it useful for checking whether anti-malware is running on each host. Its osqueryd daemon can schedule queries to run across an entire fleet, so the same question is asked of every endpoint on a fixed schedule and the results are retained. For 5.3, that supports evidence that anti-malware processes are active, that kernel modules and browser extensions match an approved list, and that file hashes of key binaries are unchanged. The license is Apache-2.0 OR GPL-2.0-only, so you may choose the terms that suit your distribution.
- Running process checks: Scheduled queries against the processes table can show whether the anti-malware agent is running on each host.
- Loaded kernel modules: Queries can list kernel modules so unexpected drivers are visible to the security team.
- File hash snapshots: Hash queries on the anti-malware binaries and configuration files support evidence that protection has not been altered.
- Open network connections: Queries on socket tables can flag hosts reaching unexpected destinations.
- Scheduled fleet results: osqueryd results can be forwarded to a central log store that the assessor can sample.
osquery does not replace an anti-malware engine and does not scan files for malicious content unless your team confirms that capability in your version. Confirm which tables and scheduled query features your deployment uses, and check the retention of results in your log platform.
Velociraptor collects forensic artifacts from endpoints using artifacts defined in VQL, and its hunts collect one or more artifacts across a group of systems. It suits 5.3 evidence work when the assessor asks for proof that a set of endpoints was checked for anti-malware status or for indicators after an event. Hunts can be scheduled for machines that are offline and will collect when they reconnect, and each hunt gets a notebook for analyzing the combined results. The license is AGPL-3.0-only, which carries source-availability obligations for modified network services, so confirm it with your legal team before deployment.
- Artifact collection: Custom artifacts can gather anti-malware service status, version and configuration from each endpoint.
- Hunts across groups: A hunt can target a defined group of systems and record which hosts responded.
- Offline host handling: Collection for machines that were offline is scheduled on reconnection, which helps show coverage across the fleet.
- Hunt notebooks: Each hunt has a notebook where analysts document findings, which can serve as review evidence.
- Collection records: Hunt results and their timestamps can show when each endpoint was checked.
Velociraptor is a collection and investigation tool, not an anti-malware engine. Confirm which artifacts exist in your version, how hunts are logged, and whether results can be exported in a form your assessor accepts.
Nextcloud is a self-hosted file platform, and it matters for 5.3 when files arrive from removable media or user uploads and the team must show that activity is logged. The admin_audit app records additional event information to an audit log, by default in the data directory, or to a path you set with the logfile_audit setting. This supports audit log retention and review, which 5.3.4 ties to the logging requirements in Requirement 10. The license is AGPL-3.0-only, so confirm the terms with your legal team.
- Audit log file: The admin_audit app writes event records to audit.log in the data directory unless you configure another path.
- Custom log path: The logfile_audit setting directs audit events to a location you control, which can be placed on protected storage.
- Event coverage: Confirm which file, sharing and administrative events your version records before you map them to evidence.
- Retention handling: Log rotation and retention must be configured outside the application so records persist for the period your policy sets.
- Integrity protection: Forward or hash the audit file to a separate system so administrators cannot alter it silently.
Nextcloud does not scan uploaded files for malware through the admin_audit app. Any malware scanning must come from a separate, confirmed integration. Verify the logging configuration keys in your installed release and test that events appear in the file.
OpenBao is an open-source secrets management platform under MPL-2.0. Its audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. For 5.3, this is relevant when the anti-malware management console, agent enrollment or policy changes depend on API tokens or secrets, and the assessor asks who changed protection settings and when. The hashing means the log can show that a sensitive value was used without storing it in plain text.
- Request-level logging: Each API request and response is recorded, including errors, which helps trace changes to protection policies.
- Hashed sensitive values: Most sensitive values are hashed with HMAC-SHA256 so the log avoids exposing secrets.
- Audit device configuration: At least one audit device must be enabled, and the configuration must be confirmed in your environment.
- Log protection: Ship the audit log to a store that administrators cannot edit, which supports Requirement 10 expectations.
- Scope limits: The log covers OpenBao API activity only, not the anti-malware agent or the endpoint.
OpenBao does not detect or block malware and is not an anti-malware engine. Confirm which audit device types your version supports, how HMAC hashing applies to each field, and how logs are retained.
Where 5.3 usually fails in assessments
Requirement 5.3 fails less often on the software itself than on the operating evidence around it: which hosts are covered, whether updates arrive, whether logs survive, and who can switch protection off. The cards below pair each common gap with the fix an assessor will expect to see documented and demonstrated.
Agents disabled on servers
Anti-malware is often running on workstations but stopped or unmanaged on servers, especially where a performance tuning change was made and never reversed. Under 5.3.5, any disablement needs documented, management-authorized, time-limited approval. Check the endpoint console for hosts reporting an inactive agent, then compare that list against the exception register. Any host without a matching, current approval is a finding.
Removable media not scanned
Requirement 5.3.3 requires removable electronic media to be scanned automatically, or behavior analyzed continuously, when it is inserted, connected or mounted. Gaps usually sit on a subset of endpoints where a policy group was never applied, or on systems where USB mass storage was re-enabled for a vendor. Test one endpoint per policy group by inserting a known-benign test file and confirming the event appears in the logs.
Audit logs kept too briefly
Requirement 5.3.4 ties anti-malware audit logs to the retention rules in Requirement 10.5.1, so logs that roll over after a few weeks fail the test even when the agent works. Logs stored only on the endpoint are also lost when a machine is reimaged or compromised. Confirm the retention period in the console, confirm that logs are forwarded to a central, access-controlled store, and sample a log from the period you are being assessed on.
Unclear authority for disablement
When a support engineer can stop anti-malware during an incident or a build job, the organization needs a written record of who may approve it, for which hosts, and for how long. Assessors look for the approval, the start and end time, and proof the agent was re-enabled. Tamper protection should block local users from changing the setting, and the console should alert when protection is turned off.
Stale signatures on offline systems
Laptops, kiosks and air-gapped payment systems often fall behind because they miss the update window that the console depends on. Requirement 5.3.1 expects signature and engine updates to happen automatically, so manual pulls must be explained and logged. Report the last update date for every asset, set an alert threshold, and document how offline or isolated hosts receive updates through an approved internal channel.
No evidence for scan frequency
Requirement 5.3.2 lets the entity set scan frequency through a targeted risk analysis, but many organizations never write that analysis down. An assessor will ask why a periodic scan runs weekly and not daily, and the answer must trace to a dated, approved risk assessment that covers the systems in scope. Keep the analysis, the schedule it produced and the scan records together so the link can be shown in one review.
Questions buyers ask about 5.3 cost, effort and audit
How much effort does requirement 5.3 take to run in-house?
Effort depends mostly on how many systems are in scope and how much of the anti-malware stack already runs automatically. Requirement 5.3 has six sub-requirements, so the team must keep the engine and signatures or behavioral rules current, configure scanning for each system type, schedule scan frequency from a documented targeted risk analysis, handle removable media, keep audit logs, and control who can disable the tool. Setup is largely one-time work. Ongoing effort is recurring: reviewing logs, checking update status across the fleet, and documenting every authorized disablement. Ask your team to count the systems in scope and the people who would own each sub-requirement before estimating hours.
Does open source remove the need for paid anti-malware?
Not by itself. Requirement 5.3 is about operating anti-malware, not about which vendor supplies it, so an open-source tool can satisfy the requirement if it actually scans, updates, logs and resists tampering. Open-source platforms such as osquery can run queries across a fleet to surface running processes, kernel modules, network connections and file hashes, which helps with monitoring and investigation. However, osquery is a query and visibility tool, not a signature-based anti-malware engine, so you must confirm which component performs the scanning and the real-time or behavioral analysis your assessor will expect. Licensing cost falls, but engineering and evidence work remain. Ask any vendor or consultant to show how each sub-requirement is met by the specific tools in your environment.
What does a partner do that the QSA does not?
A partner prepares systems and evidence, while the Qualified Security Assessor (QSA) tests them and issues the Report on Compliance. An implementation partner such as DeployOpen can plan the anti-malware configuration, deploy and harden self-hosted tooling inside your own infrastructure, set up audit log retention, document the targeted risk analysis and build the evidence packs that show each sub-requirement. The QSA independently examines that evidence and makes the assessment decision. Your organization owns the controls and signs the Attestation of Compliance. Because the partner should not also judge its own work, ask whether the same firm is planning to assess the environment, and keep those roles separate.
How long does the 5.3 evidence take to prepare?
No fixed duration applies, because the time depends on the drivers below rather than on the requirement itself. The main factors are the number of systems and removable media paths in scope, whether anti-malware and logging already exist and are documented, how many tools feed the audit trail, and how well the scan frequency decision is recorded. Teams with centralized logs and clear ownership usually spend less time gathering proof than teams reconstructing history from scattered consoles. Ask any provider for a written schedule tied to a defined scope, and ask your QSA which evidence samples they will request so the work matches their test procedures.
Is requirement 5.3.3 mandatory now?
Yes. Requirement 5.3.3 became mandatory on 31 March 2025. It requires anti-malware to scan removable electronic media automatically, or to analyze its behavior continuously, when the media is inserted, connected or mounted. Before that date, PCI SSC treated future-dated v4.x requirements as best practices that could be marked not applicable, so any assessment that relies on the earlier status is out of date. Confirm with your QSA or payment brand how removable media is defined in your environment, and check that the chosen control triggers on insertion, connection or mounting rather than only on a scheduled scan.
What must our team provide before an assessment?
Your team must provide the records that show anti-malware is active, current and controlled. Expect to supply the following:
- An inventory of in-scope systems and the anti-malware deployed on each
- Configuration evidence for automatic updates and scan or behavioral analysis settings
- The documented targeted risk analysis that sets scan frequency
- Removable media scanning configuration and sample results
- Audit log settings and retained logs aligned with requirement 10.5.1
- Documented, time-limited and management-authorized records for any disablement
- Named owners for each sub-requirement
Ask your QSA which sample dates and systems they will select, so the team can prepare evidence that reflects normal operation rather than a one-off export.
How DeployOpen prepares 5.3 systems and evidence
DeployOpen plans, implements and documents the anti-malware operation and log pipelines for Requirement 5.3 inside your own cloud accounts, data centers or air-gapped networks, under a fixed written scope agreed before work starts. In practice that means defining which endpoints, servers and removable-media paths are in scope, configuring the anti-malware agents so they update automatically and cannot be disabled or altered by ordinary users, setting scan frequency from the targeted risk analysis your organization documents, and routing anti-malware audit logs into a retained store that meets the retention expectations of Requirement 10.5.1. Where open-source tooling such as osquery is used for fleet-wide query evidence, DeployOpen configures the query schedules and documents what each query shows. Your organization still owns the control, the risk analysis, the authorization process for any case-by-case disablement under 5.3.5, and the decisions about scan frequency.
The evidence an assessor expects is mostly produced by the running system, so DeployOpen prepares it as a set of artifacts: configuration exports, update and scan logs, removable-media scan records, log retention settings, and a dated record of who can change the anti-malware configuration. Ask any partner to show you a sample evidence pack for a single host before the build is finished, and confirm with your QSA which samples they will sample from the environment. DeployOpen does not issue reports, attestations or certifications. The Report on Compliance and the Attestation of Compliance are issued by the Qualified Security Assessor (QSA) or the Self-Assessment Questionnaire is completed by your organization under the rules in the PCI SSC PCI DSS standard page. Ongoing upkeep, such as reviewing updates, tuning scan coverage and refreshing evidence between assessments, is available as an optional retainer once the fixed-scope build is complete.
