5.1 Anti-malware processes and roles: requirements and evidence

What PCI DSS 5.1 asks for and why assessors check it

When a QSA or a Self-Assessment Questionnaire asks how you protect systems from malware, the first thing to produce is not a scan report. It is the written anti-malware policy and the operational procedures behind it, plus a record of who does what. Requirement 5.1 of PCI DSS v4.0.1 is the foundation for everything else in Requirement 5, and assessors test it by reading documents and interviewing the people named in them. Before you start tuning any product, confirm that the documents exist, match how systems are actually run, and are known to the staff who run them.

Sub-requirement 5.1.1 asks that the security policies and operational procedures for Requirement 5 are documented, kept up to date, in use and known to all affected parties. Each of those four words is a separate test. A policy that was written for an earlier tool, or that nobody on the operations team has read, will fail even if the malware controls work. Sub-requirement 5.1.2 asks that roles and responsibilities for Requirement 5 activities are documented, assigned and understood. In practice this means a named owner for the anti-malware platform, someone accountable for reviewing alerts, and a clear answer to who approves exceptions. A RACI matrix is a common way to record this, and assessors will look for the same names in the policy, the RACI and the interview.

Requirement 5.1 is a documentation requirement, but it fails in practice when ownership is vague. Malware that reaches cardholder data environment systems often goes unnoticed because each team assumes another team is watching alerts or updating signatures. To avoid that gap, confirm with your security and infrastructure leads who owns each Requirement 5 activity today, not who owned it when the policy was drafted, and compare that answer with the document. Ask your QSA which evidence they expect to see for each sub-requirement, since expectations on format and depth can vary by assessment.

Which systems, teams and third parties 5.1 applies to

Requirement 5.1 applies to whatever sits inside the assessed scope, so the first decisions are which systems, people and providers fall under it. Each card below is a scoping question that changes who writes the procedures, who runs them and what the policy has to describe.

In-scope system components

Requirement 5.1 applies wherever the anti-malware requirements apply, which means every system component in the cardholder data environment and any system that could affect its security. Start from the current network and data-flow diagrams and the system inventory, not from memory. Check that the policy names the operating system families, servers, workstations and cloud workloads it covers, and that it reaches systems added through change management. An anti-malware policy that omits a server group leaves a gap an assessor will find by comparing the policy with the inventory.

In-scope personnel and access paths

The policy also has to address people who can bring malware into scope, including administrators, developers, support staff and anyone who handles removable media or email attachments that reach payment systems. Confirm which user groups have administrative rights on endpoints, because those rights often allow anti-malware to be disabled. Record how remote access and privileged sessions are handled. Ask whether these roles are named in the procedures and whether personnel understand their obligations.

Internal teams that run anti-malware

Several internal teams usually share anti-malware work: IT operations deploys agents, endpoint administrators manage configurations and exclusions, and the security team reviews alerts and logs. Each team needs a documented role in the roles and responsibilities record, along with a named owner who approves the policy. Confirm where ownership changes between teams, such as after-hours alert handling or exception approval. Gaps usually appear at these handoffs rather than inside any one team.

Third parties that operate controls

A managed security provider, hosting company or outsourced endpoint operator may run anti-malware tooling, monitor alerts or patch systems on the entity's behalf. The entity remains responsible for the requirement, so the contract and responsibility matrix must state who deploys, updates, monitors and reports each control. Ask providers for evidence that they meet the same procedures, and confirm how their staff are named in the roles record. Review these arrangements whenever a provider changes its tooling or service model.

Scope changes that update the policy

A policy that describes last year's environment fails the first time an assessor compares it with reality. New cloud accounts, acquired business units, retired servers and changed providers all alter which systems and roles 5.1 covers. Tie policy review to change management and scope validation so that each scope change prompts a check of the policy, procedures and role assignments. Keep a dated record of these reviews, since the policy must be current and in use.

How an assessor tests 5.1.1 and 5.1.2

This table maps each step of the assessor's test for 5.1.1 and 5.1.2 to the evidence requested, what the assessor checks for, and the findings that most often come up. Read it as a preparation checklist: each row shows what to have ready before the assessment starts.

Test element	What the assessor looks for	Common finding to avoid
Examine the anti-malware policy	A written policy covering protection of systems and networks from malware, with a visible owner, approval and review date	Policy exists but has no owner, approval or review date
Examine operational procedures	Step-by-step procedures for deploying, updating, monitoring and responding to anti-malware alerts	Procedures describe the tool in general terms but not how staff run it day to day
Check currency	Revision history showing the policy and procedures were reviewed on a schedule and updated after tooling or process changes	Documents still reference retired products, old server names or former teams
Examine the RACI or role record	Named individuals or current role titles for each Requirement 5 activity, with accountable and responsible parties identified	Roles name a department or a vacant position, or no one is named for monitoring alerts
Interview responsible personnel	Staff who run anti-malware controls can describe their duties and explain where the procedure lives	Interviewees give different answers about who approves exceptions or who reviews logs
Check awareness of the procedure	Affected staff know the procedure exists, have access to it and have acknowledged or been briefed on it	Staff have never read the procedure, and no record shows it was communicated to them
Confirm the evidence is in use	Records that show the procedure is followed, such as review sign-offs or alert handling tickets	Procedure is current on paper, but no records show it has been executed

Implementing 5.1 step by step

This sequence turns Requirement 5.1 into a documented, approved and communicated set of anti-malware policies, procedures and roles that an assessor can examine and that staff can actually follow. Each step produces a named artifact so the final package is ready for interviews and document review.

Scope the systems that Requirement 5 covers
Start from your current cardholder data environment diagram and asset inventory, and list every system component in scope for anti-malware, including servers, workstations, laptops, and any systems that could affect CDE security. Owners are usually the security lead with input from infrastructure and application teams. The step is done when the list is reviewed by both teams and each entry names an owner, so that the policy you write later covers a known population rather than an assumed one.
Draft the anti-malware policy and procedures
Write the security policy that states why and what anti-malware protects, and the operational procedures that describe how deployment, updates, scanning, log review and exception handling are carried out day to day. The security lead drafts, and technical owners check that each procedure matches how the tools actually run. The output is a versioned policy and a procedure set that together answer the questions an assessor will ask during document examination.
Define roles for each anti-malware activity
Assign named roles for deployment and configuration, ongoing monitoring of alerts, exception and risk acceptance decisions, and the anti-phishing controls that Requirement 5.4 expects. Each role should be a function that can survive staff changes, with a named person or team behind it. The output is a written role description for each function, approved by management, that states the responsibilities and the escalation path when a role holder is unavailable.
Record responsibilities in a RACI matrix
Map each Requirement 5 activity against the roles defined in the previous step, marking who is responsible, accountable, consulted and informed. Include activities such as enabling automatic updates, reviewing scan logs, approving exceptions and running phishing protection. The output is a RACI matrix with exactly one accountable owner per activity, which gives the assessor a single record that shows roles are documented, assigned and understood.
Communicate and collect acknowledgments
Publish the policy, procedures and RACI matrix to everyone named in them, and confirm that each affected person has read and understood the parts that apply to their work. Technical staff who run the tools should receive the procedures directly, while managers receive the policy summary. The output is a distribution record with dates and acknowledgments, which shows the documents are known to all affected parties as the requirement asks.
Verify that the documents match practice
Walk through the procedures with the people who perform them and check that the stated steps, tools, logs and escalation paths exist and work as written. Note any gap between the documents and reality, then correct either the document or the practice. The output is a short verification record listing each procedure, the person interviewed and the result, which prepares your team for the interviews an assessor will hold.
Schedule the policy and role review
Set a review cycle for the policy, procedures and RACI matrix, and assign an owner to run it, with triggers for earlier review such as a change in tooling, a new payment channel or a staff change in a named role. The output is a documented review schedule and a revision history that show the documents are kept up to date, which is the ongoing part of Requirement 5.1.1.

How the policy, procedures and roles fit together

The three documents do different jobs, and an assessor will expect to see all three line up. The anti-malware policy states the intent and the rules: which systems the protection covers, what minimum standard applies, and what must never be turned off without approval. The operational procedures are the steps people follow to make those rules happen, such as how a new server gets its anti-malware agent, how an alert is triaged, or how an exception is raised and closed. The roles record answers who acts at each step, including who owns the policy, who runs the procedures and who reviews the results. If the policy promises a rule that no procedure carries out, or a procedure names a role that nobody has been given, the gap is usually where a finding starts.

Requirement 5.1 covers the anti-malware and anti-phishing processes and the roles that run them. The technical controls themselves sit in the sibling requirements: 5.2 covers deploying protection and the periodic review of systems judged not at risk, 5.3 covers keeping protection active, updated and logged, and 5.4 covers anti-phishing mechanisms. Keep 5.1 focused on the documents and accountability that govern those controls. A practical check is to take one control from 5.2 or 5.3, such as scanning of removable media, and trace it back to the policy clause that requires it, the procedure step that performs it and the named role that owns it. Each link should be traceable without a verbal explanation from the team.

Confirm the mapping against the official self-assessment questionnaire for your entity type before you build the records, because the exact wording and testing expectations vary by questionnaire and assessment route. Ask your assessor how they expect roles to be recorded, since a RACI matrix is a common format but not the only one. Then decide where the documents will live and how they will be kept current. Version history, approval records and clear ownership matter as much as the content, because the assessor will ask whether the documents were in use and known to affected staff, not only whether they exist. Anyone reviewing the documents should also be able to see who changed them and when.

Evidence that passes 5.1 and how to keep it current

An assessor testing 5.1 looks at a small set of documents and then asks people whether they know and use them. The cards below cover each artifact, the version and access controls that show it stays current, and the checks that catch drift between reviews.

The anti-malware policy

This is the written policy that sets the expectations for protecting systems and networks from malware, covering every system type in the scope of Requirement 5. It should name an owner, state an approval date and show who approved it. Check that the policy matches what is actually deployed, because an assessor will compare the text against the anti-malware configuration and the systems list. A policy that describes a product the team retired is a common finding.

Operational procedures with version history

The procedures describe the recurring steps: deploying agents, checking update status, reviewing scan results and handling alerts. Keep each procedure under version control so you can show what changed, when and who made the change. A procedure that has not changed in years can be as much of a concern as one that changes without approval, so record the review date even when nothing was edited.

Roles and responsibilities record

This record assigns each Requirement 5 activity to a named role or team, such as who owns the anti-malware tool, who reviews alerts and who approves exceptions. A RACI matrix is a common format. The assessor will interview these people, so each one should be able to describe their duties without reading from the document. Recheck the record whenever staff move on or responsibilities shift between teams.

Role-based edit rights

Limit who can edit the policy and procedures to the people who own them, and let everyone in scope read them. Restricting edit rights prevents silent changes and gives the change history more weight. In self-hosted wikis, confirm that permissions can be set at the page or book level and that edit rights are reviewed when staff change roles, since an account that outlived its job can still alter a controlled document.

Acknowledgment records

Evidence that affected personnel know the policy is an acknowledgment record for each person, with the policy version they accepted and the date. New joiners and transferred staff need to acknowledge the current version as well. Keep the records in a system that cannot be backdated by the person who signed. Check that every role listed in the responsibilities record appears in the acknowledgment list.

Review logs and change evidence

A review log records each periodic review of the policy and procedures, the reviewer, the outcome and any changes made. Pair it with the page history so the log and the revision record agree. Some organizations also keep fleet query results from osquery or Velociraptor hunts that show anti-malware agents running as documented, which connects the written policy to observed operation. Confirm the review frequency with your assessor and your own risk analysis before setting it.

Keeping policy and roles in self-hosted documentation

Requirement 5.1.1 expects the anti-malware procedures to be kept up to date and in use, so the procedure documents need a visible record of who changed what and when. XWiki, licensed under LGPL-2.1-or-later, suits this job because it keeps every change to a page under version control. Each edit records what changed, when and by whom, so you can compare any two versions and roll back to an earlier one when a procedure is found to be wrong.

Change attribution: Each revision shows the author and timestamp, which gives an assessor a direct trail from a procedure update to the person who approved and made it.
Version comparison: Reviewers can compare the current scanning or update procedure with the version that was in force during the assessment period.
Rollback: A bad edit can be reverted to a known-good revision without losing the history of the mistake.
Structured pages: Separate pages for scanning schedules, alert handling and exception requests make each procedure easy to point to during an interview.
Self-hosting: The wiki runs inside your own infrastructure, so the procedure history stays under your control.

Confirm with your team that the wiki is the system of record for procedures, not a copy, and that access to edit those pages is limited to named owners. Check that the LGPL-2.1-or-later terms fit how you plan to modify or distribute the software.

What meeting 5.1 costs in money and effort

This table breaks down the cost components of meeting Requirement 5.1, showing who is paid for each one, whether it is one-time or recurring, and what drives it up or down. No prices are shown because no researched figures apply, so use the table to build your own internal estimate and the questions to ask providers and your assessor.

Cost component	Who carries the cost	One-time or recurring	What drives it
Writing and approving the anti-malware policy and procedures	Internal security and compliance staff, plus management sign-off	One-time, then revised on change	Number of environments, existing policy maturity, and how many approval layers apply
Designing roles and building the RACI matrix	Internal leadership, with optional outside help for facilitation	One-time, then maintained	Number of teams touching anti-malware, such as endpoint, server, cloud and security operations
Documentation tooling and hosting	Internal platform team or a partner who installs and administers the wiki	Licence spend is often nil for open source, but hosting, backups and admin time recur	Choice of self-hosted platform, hosting location, and whether version history and access controls are configured properly
Staff acknowledgment of the policy	Internal HR or security administration	Recurring, at onboarding and on each policy update	Headcount, contractor volume, and whether acknowledgments are captured in a system of record
Annual policy and role review	Internal policy owner and reviewers	Recurring, at least annually	Frequency of organizational change, staff turnover in named roles, and new system additions
Assessor sampling time	Your team provides evidence and interviews, and the independent QSA or assessor examines it	Recurring, at each assessment cycle	Number of interviews, the volume of documentation requested, and how well evidence is indexed before fieldwork
Outside preparation help	Implementation partner or consultant, under a written fixed scope	Usually one-time readiness work, with optional retainers	Gap between current documents and the standard, and how much drafting you delegate

Where 5.1 usually fails and how to close each gap

Requirement 5.1 fails less often on missing documents than on documents that are stale, unowned or disconnected from how anti-malware actually runs. The cards below cover five gaps an assessor is likely to find when examining policies and interviewing personnel, with a practical fix for each.

Policy written but never reviewed

A policy approved years ago and never revisited often describes tools, scan schedules or escalation paths that no longer exist. Assessors compare the document with current practice during examination. Set a named owner and a review date, then check that each review records what was confirmed, changed and approved. Confirm the review cadence your own risk analysis and the standard's wording support, and keep the last approved version easy to find.

Roles assigned to a team

Writing that anti-malware is the job of "IT operations" leaves no one accountable when an alert is ignored or a scanner stops reporting. Requirement 5.1.2 expects roles and responsibilities to be assigned and understood, which means named individuals or a named backup for each task. Build a RACI matrix that lists who maintains the policy, who reviews scan and alert records, and who approves exceptions, then confirm each person knows their part.

Procedures that do not match the tools

A procedure that says "run the antivirus console weekly" fails when the environment runs endpoint detection on some hosts, containers on others, and no agent on a legacy appliance. Walk each documented step against the tools actually deployed and record the gaps. Open-source query tools such as osquery can confirm which hosts run a process or have a given file, which helps the procedure describe what really happens.

Staff unaware of the documents

Documents that sit in a shared drive nobody opens do not meet the expectation that the policy is in use and known to all affected parties. Assessors commonly interview system administrators, help desk staff and incident responders to see whether they can describe the procedure without reading it. Publish the policy in a location people use, require acknowledgment from those who run controls, and keep a short record of who was briefed and when.

No change history

When a procedure changes without a record of what changed, who approved it and when, an assessor cannot tell whether the current version was in force during the assessment period. Wiki platforms with version control keep the edit trail and let you compare and roll back versions. Store the policy in a system that records authorship and history, and file the approval record alongside each version so the evidence is complete.

Who writes, who implements and who assesses 5.1

Requirement 5.1 asks the entity itself to hold the anti-malware policy, the operational procedures and the roles that run them. Those are management decisions, so the organization must approve them, assign named owners and make sure the people doing the work know what is expected of them. A partner can draft text, but the organization is accountable for whether the policy reflects how its systems actually operate.

Approval and ownership: A named executive or governance body approves the policy, and a named owner keeps it current.
Accurate scope: Staff confirm which system components, including personnel-facing channels, the policy actually covers.
Assigned responsibilities: Individuals or teams are named for each anti-malware and anti-phishing activity, with backups where coverage matters.
Awareness: Affected personnel acknowledge the policy and know where the current version lives.
Review cadence: The organization sets a review trigger, such as system changes or a security incident, and records each review.

Confirm that a named internal owner can explain every statement in the policy without referring to the consultant who drafted it.

Questions teams ask about PCI DSS 5.1

Does a written anti-malware policy alone satisfy PCI DSS 5.1?

No. Requirement 5.1 asks for a policy and operational procedures that are documented, kept up to date, in use and known to everyone they affect. An assessor will check that the document exists, but also that staff follow it and can explain it. A policy that describes scanning and update routines your team does not run will fail the interview and the evidence review. Treat the policy as the start of the work: the procedures should name the tools, schedules and checks that actually happen, and records should show they happened.

How long does it take to write the 5.1 policies and what drives the effort?

The effort depends mostly on how many systems are in scope, how many tools already produce anti-malware evidence, and how many teams own a piece of the process. A single-team environment with one endpoint product and existing security policies is far quicker to document than a multi-cloud estate with servers, containers and staff laptops managed by different groups. Existing policy templates, a current asset inventory and a clear network diagram shorten the work. Ask any provider for a written scope that lists the documents to be produced, the teams to interview and the review cycle before agreeing a timeline.

Can our own team write the 5.1 documentation without a consultant?

Often yes, provided someone on the team understands both the standard and your environment. The work is mainly writing, collecting records and aligning documents with what operations really does. Teams often find the hardest part is agreeing who owns each duty across security, infrastructure and endpoint support. An outside implementation partner can prepare the documents, configure the logging and retention needed to show evidence, and organize records for review. That partner does not validate compliance. The organization owns its policies, and the Qualified Security Assessor or other assessor decides whether the requirement is met.

Who must sign off the roles and responsibilities for anti-malware?

Requirement 5.1.2 asks that roles for Requirement 5 activities be documented, assigned and understood, so the record needs an approving owner with authority over security operations, usually the CISO or head of security. Each named role should be confirmed by the person who holds it, and the teams that run daily tasks such as update checks, scan reviews and alert triage should acknowledge their part. A RACI matrix is a common format. Keep the approval, the date and the list of acknowledgements, because an assessor will interview the named people and compare their answers with the record.

How often should the 5.1 policies, procedures and role records be reviewed?

PCI DSS requires the documents to stay up to date, but the standard does not fix a single review interval for every document in this area, so set one in your own policy and follow it. Common triggers for an earlier review include a change of anti-malware product, a new cloud platform, an organizational restructure, or a significant incident. Versioned wiki or documentation tools help here, because they record what changed, when and by whom, and let reviewers compare versions. Confirm the review cadence with your assessor before the assessment, since they will check that the cadence was followed.

Does the choice between a SAQ and a ROC change what 5.1 requires?

The requirement itself is the same. What changes is how the evidence is packaged. An organization completing a Self-Assessment Questionnaire records its answers on the SAQ template and signs the Attestation of Compliance, while an organization assessed through a Report on Compliance has a Qualified Security Assessor examine the documents and interview personnel, then document the findings in the ROC. Your policies and role records are examined in both cases. The applicable SAQ or ROC depends on your validation level and channel, so confirm that with your acquirer or the payment brand before preparing evidence.

What evidence should we prepare for an assessor to review 5.1?

Assessors typically examine the written anti-malware policy and procedures, then interview the people named in the roles record and compare their answers with the documents. Prepare the approved policy with version history, the procedures showing how updates and scans are run, the roles and responsibilities record, and proof that staff received the documents. Operational logs from anti-malware and inventory tools help show that the procedures are followed. Ask your assessor early which formats they accept, since the expected evidence is confirmed during scoping.

How DeployOpen prepares 5.1 evidence

DeployOpen helps organizations prepare the anti-malware policy, procedures and roles records that Requirement 5.1 expects, using self-hosted open-source platforms inside the client's own infrastructure. The organization owns its policies and assigns its own people, and an independent QSA or assessor decides whether the evidence meets the requirement.

How we scope

The written scope lists which documents, roles and systems covered by Requirement 5 are in scope for 5.1.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
Scope also names which teams the organization expects to own each policy and each responsibility.

How we build

We set up a self-hosted wiki or documentation platform with version history for the 5.1 policy and procedures.
We configure role-based permissions so policy owners can edit documents while other staff can only read them.
We draft a roles and responsibilities record, such as a RACI matrix, for the anti-malware and anti-phishing activities.

How we hand over

We deliver the documented policy, procedures and roles record in a form the organization can maintain itself.
We provide a change history and approval trail so an assessor can see when each document was updated and by whom.
We walk the responsible personnel through their documented duties so they can explain them during interviews.

How we support

Ongoing support, upgrades and reviews of the 5.1 documents are available as a retainer.
We help schedule periodic policy reviews so documents stay current with the organization's environment.
Assessment decisions and Report on Compliance or Attestation of Compliance issuance remain with the independent assessor.