A.8.7 Protection against malware: requirements and evidence

What A.8.7 protection against malware asks for in plain terms

A.8.7 asks you to protect systems against malware and to make that protection work through user awareness. In plain terms, you need technical defenses that stop, detect and remove malicious code, and you need people who know how to avoid bringing it in. An auditor will not accept antivirus software alone, and will not accept a training slide deck alone. The control is met when the two halves are implemented and can be shown to operate together. If an audit is approaching or a customer questionnaire asks about antivirus, start by checking whether you can produce evidence for both halves, not only a product name. The risk is malicious code reaching endpoints and servers and then spreading, stealing data or disrupting operations. The control text itself is not quoted here, so confirm the exact wording in your licensed copy of ISO/IEC 27001:2022. Its predecessor in the 2013 edition was A.12.2.1, Controls against malware, and the correspondence table in ISO/IEC 27002:2022 traces A.8.7 back to it. Teams migrating older certificates should map their existing malware evidence to this new identifier rather than rebuilding it from scratch. The work is hard because malicious code arrives through many paths at once: endpoints, servers, email attachments, web downloads and removable media. Protection therefore spans detection and repair software, allowlisting of approved executables, blocking of malicious websites (see the related control A.8.23 Web filtering), and a defined process for handling infections. People are part of the chain, so awareness is tied to A.6.3 Information security awareness, education and training. Decide early which owner runs each layer, and confirm with your assessor how they expect the layers to be evidenced.

Which endpoints, servers and people A.8.7 protection against malware covers

A.8.7 protection against malware is only as complete as its scope. The cards below cover the scoping decisions that most often change the work: which devices, workloads, access paths and people fall under malware protection and awareness. Confirm each one against your asset inventory before you agree a scope with an auditor.

User laptops and phones

Laptops and phones are the most common malware entry points, so they are usually in scope by default. Check which operating systems, browsers and mobile platforms are used, and whether detection runs on every device or only on managed ones. Confirm that every device that reads company email or files is enrolled, because unmanaged devices are the usual gap between the inventory and the actual fleet.

Servers running only containers

Whether a container host needs the same detection as a workstation depends on what it runs, how it is built and who can reach it. Ask whether images are scanned before deployment, whether hosts run a supported agent, and whether the container runtime itself is monitored. The answer changes the tooling and evidence, so record the decision and its reason in the Statement of Applicability workflow.

Cloud workloads and build pipelines

Virtual machines, serverless functions and CI runners can all execute untrusted code. Decide which of them are in scope, including short-lived build agents that exist only during a pipeline run. Confirm how transient workloads are inventoried, since an agent that is never registered in the asset list is hard to evidence.

Email and web access paths

Malware often arrives through email attachments, links and browser downloads rather than through a scanned file share. Decide whether mail gateways, web filtering and download controls are in scope as protection layers, and who owns each one. Web filtering is closely tied to A.8.23 Web filtering, so the two topics should share one owner and one set of records.

Contractors with company devices

Contractors who hold company laptops or accounts are usually in scope because the protection applies to the device, not the employment contract. Check how contractor devices are enrolled, who pushes updates to them, and how they are removed at the end of an engagement. Related people controls such as A.6.3 Information security awareness, education and training should cover the same group.

Teams who handle infections

Scope also covers the people who detect, contain and recover from infections: the service desk, security operations and the owners of affected systems. Confirm who can isolate a device, who approves restoring from backup, and where infection records are kept. Clear ownership of these steps is often the evidence an assessor asks for first.

How an assessor tests A.8.7 protection against malware

This table compares five areas an assessor reviews for A.8.7, showing the test approach, the evidence requested and the findings that commonly appear. Read each row as a checklist for your own pre-audit review, since the same questions usually come up across all five areas. The main takeaway is that assessors look for proof that protection runs on every relevant endpoint and that staff have been trained to act on it.

Area	Test approach	Evidence requested	Common findings
Technical protection	Sample endpoints across user, server and remote populations, then compare configuration against the documented malware protection standard	Protection policy, agent deployment reports, signature or engine update records, scan and alert logs	Endpoints missing the agent, outdated definitions, exclusions with no documented approval
Allowlisting and execution control	Check whether the organization limits which programs can run, and test a sample of blocked and permitted executions	Allowlist rules, approval records for new entries, block event logs, exception register	Allowlists never reviewed, broad exceptions for user folders, no owner for approvals
Web and email blocking	Review filtering policy for known malicious sites and attachments, then confirm rules apply to off-network devices	Filtering configuration, category settings, blocked-request logs, mail gateway rules	Filtering disabled for remote users, no review of blocked events, policy not covering all browsers
Awareness program	Compare the training content with the threats the organization faces, then sample staff records against the training schedule	Training materials, completion records, phishing exercise results, attendance for new joiners	Training not refreshed, gaps for contractors, no link between results and follow-up actions
Infection handling	Walk through a recent or simulated incident from detection to recovery, and check that steps in the procedure were followed	Incident tickets, isolation and clean-up records, root cause notes, lessons learned	Procedure not tested, no record of who isolated the host, reinfection not tracked

Evidence that satisfies A.8.7 protection against malware

A.8.7 is tested by what the organization can show over time, not by what it says it runs. The cards below cover the artifacts an assessor usually samples, and each one is paired with a routine that keeps it current between audits so the evidence reflects the period under review.

Deployment coverage reports

A coverage report lists every endpoint and server that should run protection against malware, with the agent version, last check-in and protection state for each. It proves the control reaches the whole in-scope estate rather than a sample of machines. Check the report against your asset inventory, since a device missing from the inventory will also be missing from the coverage report. Export it on a fixed schedule and keep the dated copies, so an assessor can see coverage across the audit period, including gaps and how long they stayed open.

Policy and configuration exports

Exports of the detection settings show what the protection is actually configured to do: real-time scanning, behavior monitoring, scan schedules, exclusions and update channels. They prove the settings match the approved standard and that exclusions are limited and justified. Review exclusions carefully, because a broad path exclusion can quietly remove a whole class of files from scanning. Store exports with the change record that approved any difference, and compare each export to the baseline in your configuration management records.

Detection and alert records

Detection logs show what the protection found, what it did (quarantined, blocked, cleaned or flagged) and when. They prove the control works in operation, not only that it is installed. Forward these events to a central log store so they survive endpoint rebuilds and can be correlated with other sources. Confirm that alerts reach someone who acts on them, and keep the record of who triaged each high-severity detection and what they concluded.

Infection tickets with root cause

Each confirmed infection should have a ticket that records the affected system, how the malware got in, the containment and repair steps, and the follow-up that prevents a repeat. An assessor reads these to judge whether the control responds to real events. A ticket that says only "cleaned" is weak evidence. Link each ticket to the relevant detection record and to any change made afterward, such as a blocked domain, a new rule or a patched application.

Awareness training and phishing results

Completion records for malware and phishing awareness, together with the results of simulated phishing exercises, support the user awareness part of A.8.7. The control expects protection to be supported by awareness, so an assessor looks for both the training record and evidence that people apply it. Track who completed training, when, and which users clicked or reported in each exercise. Repeat exercises on a set cycle and record how the results changed, and tie remedial training to the people who failed.

Records of periodic review

Periodic review records show that the malware controls are checked against their objectives and kept up to date. They include the review agenda, the coverage and detection figures examined, the decisions taken and a dated sign-off by the accountable owner. Assessors use these to confirm the control is maintained, not set once and forgotten. Schedule the review in advance, keep the minutes, and record each action with an owner and a due date so that open items can be traced to closure.

Implementing A.8.7 protection against malware step by step

The sequence moves from knowing which systems and users need protection to a tested response process, and each step leaves a document or record an assessor can read.

Inventory endpoints, servers and malware exposure points
The asset owner, with IT operations, lists every system where malware could run or enter: user endpoints, servers, mobile devices, email gateways, web browsers and any shared file stores. Each entry records the operating system, the owner, the business function and whether the system is internet-facing. The output is an asset register extract that the malware controls reference directly. The step is complete when someone can point to a system that is not on the list and explain why that is acceptable.
Approve a risk-based malware protection policy
The information security lead drafts the malware protection policy from the risk assessment, setting which protection types apply to which system classes, who owns exceptions and how exceptions expire. Management approves it, and it is linked to the Statement of Applicability entry for A.8.7. The output is an approved policy with a named owner and a review date. Confirm with your certification body how it expects the policy to connect to your risk treatment decisions.
Deploy detection and repair across the inventory
Platform engineering installs anti-malware and endpoint detection software on the systems in scope, using the approved configuration baseline and central management. Signature or behavioral update settings, scan schedules and real-time protection are configured to the policy. Open-source options such as osquery can add visibility into running processes, kernel modules and file hashes, and Wazuh can collect alerts for review. The output is a coverage report showing each in-scope system, its agent version and its last update, with gaps listed as exceptions.
Set execution and allowlisting controls
Engineers decide where execution should be restricted, such as servers that run fixed workloads, privileged workstations or systems that handle sensitive data. They define allowlists or application control rules, test them in a monitor-only mode and then enforce them where the business impact is understood. Exceptions require documented approval. The output is an execution control standard and a record of which systems enforce it, which run in monitor mode and why.
Configure web and content blocking
The network and security team sets web filtering and email content rules that block known malicious and unauthorized sites, and it defines how users are warned or directed when a block occurs. This control overlaps with A.8.23 Web filtering, so the rules and their owner should be documented once and referenced in both places. The output is a filtering rule set, a list of approved exceptions and a log showing that blocks are recorded. Test a block with a harmless sample domain to confirm the rule works end to end.
Build the user awareness program
HR and the security lead deliver awareness material on phishing, unsafe downloads, macro use, removable media and how to report a suspected infection. Training is scheduled for new joiners and repeated for existing staff, and it links to the broader A.6.3 awareness program. The protection depends on this step because detection tools miss some lures. The output is a training plan, course content and attendance records, and the reporting channel is tested so that staff know exactly who to contact.
Write and rehearse the infection handling procedure
The incident response lead writes the procedure for isolating an infected system, preserving evidence, removing the malware, restoring from known good backups and deciding when to escalate to a formal incident. Forensic collection tools such as Velociraptor can be named as the evidence collection method where they are in use. The runbook is rehearsed on a test system. The output is a tested runbook with roles, decision points and a record of the rehearsal, which an assessor can compare with real incident records.
Establish recurring reviews and metrics
The control owner schedules reviews of coverage reports, blocked events, allowlist exceptions, awareness results and infection records, and presents them to management. Findings feed the vulnerability management process and the policy is updated when the threat picture or systems change. The output is a review log with dated minutes and corrective actions. Confirm with your auditor how many review cycles it will sample for the current certification period.

Which open-source tools produce malware protection evidence

A.8.7 asks for malware protection that is supported by user awareness, so an assessor will want records that show protection is deployed, monitored and acted on. The tools below cover endpoint querying, fleet-wide collection and log-based alerting, which together can produce that evidence. None of them is described in the researched facts as replacing signature or behavioral anti-malware or allowlisting, so those capabilities must be confirmed separately.

osquery endpoint queries

osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. For A.8.7, these tables can show whether unexpected processes, kernel modules or browser extensions are present on endpoints. The osqueryd daemon schedules these queries across a fleet of hosts, so the output can be kept as dated records. Evidence produced: scheduled query results, file hash inventories and process snapshots. License: Apache-2.0 OR GPL-2.0-only. Check which query packs your team will maintain and who reviews the results.

Velociraptor artifact collection

Velociraptor collects forensic artifacts defined in VQL from endpoints. Hunts collect one or more artifacts across a group of systems, and machines that are offline are scheduled to collect when they reconnect. This supports incident handling for infections, since responders can gather the same artifacts from every affected host and analyze them in a notebook per hunt. Evidence produced: hunt definitions, collection records and analysis notebooks. License: AGPL-3.0-only. Confirm how your organization will meet the AGPL-3.0 obligations before deployment.

Wazuh rule-based alerting

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. Matching events are written to alerts.log and alerts.json, mapped to MITRE ATT&CK and forwarded to the Wazuh indexer for review in the dashboard. Alerts for known malware indicators can serve as evidence that detection is running and reviewed. Evidence produced: alert files, ATT&CK-mapped alert records and review history. License: GPL-2.0-only. Check whether your rules cover the malware sources you rely on.

OpenSearch Security Analytics findings

OpenSearch Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with rule, log type and severity, alerts go to channels such as Slack or email, and a correlation engine links findings across log types. This helps show that malware-related events are matched, tracked and escalated. Evidence produced: findings with rule and severity, alert delivery records and correlation graphs. License: Apache-2.0. Confirm that the Sigma rules you deploy are tested against your own log sources.

What meeting A.8.7 protection against malware costs in money and effort

This table compares the main cost components of A.8.7, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations are given because none are published in the researched facts, so use the questions in the last column when requesting quotes. Read it as a checklist for scoping a written quote, not as a budget.

Cost component	One-time or recurring	What drives it	How to keep it down
Commercial endpoint protection licenses	Recurring, usually per device or per user	Number of endpoints, server and cloud workloads, and whether vendor management or extended detection features are included	Confirm which device types the license covers, ask for multi-year pricing terms in writing, and remove unused seats at each renewal
Self-hosted open-source tooling and its license terms	Software cost usually none, with one-time setup and recurring hosting	Licenses differ (for example, osquery is Apache-2.0 OR GPL-2.0-only, Wazuh is GPL-2.0-only, Velociraptor is AGPL-3.0-only), so review obligations with counsel if you modify or distribute code	Confirm license terms with counsel before rollout, and keep hosting size proportional to the number of monitored hosts
Engineering time to deploy and tune	One-time, with ongoing tuning as the fleet changes	Heterogeneity of operating systems, number of query packs or detection rules, and how much custom allowlisting is needed	Start with a limited pilot group, reuse standard configurations, and ask any implementation partner for a fixed-scope written plan with named deliverables
Awareness training and phishing exercises	Recurring, typically scheduled per year	Headcount, staff turnover, and how many simulations and refresher modules are run	Use existing learning platforms where possible, target exercises by role, and track completion as evidence for the awareness requirement
Evidence upkeep	Recurring	Frequency of allowlist reviews, detection log exports, incident records and the number of systems in scope	Automate exports from the tooling, keep a fixed review calendar, and store evidence in one location
Infection handling staffing	Recurring in staff time, one-time for playbook creation	Alert volume, number of incidents per year, and whether handling is in-house or outsourced to a retainer	Write a playbook for common malware types, define severity thresholds, and confirm response hours and escalation paths in any retainer
External testing or review	Recurring or per engagement	Scope of testing, number of applications and networks reviewed, and whether a second opinion on malware controls is needed	Limit scope to the systems that hold sensitive data and agree the deliverables in writing before work starts
Auditor sampling effort	Recurring, tied to each audit cycle	Number of endpoints and incidents the auditor samples, and how easily evidence can be retrieved	Prepare sample-ready evidence packs in advance and ask the certification body to confirm its sampling approach before the audit

Who does what for malware protection: your team, a partner and the auditor

Your organization owns control A.8.7 and every decision that makes it work. Someone accountable must define which malware protections apply, who approves exceptions, how infections are handled and whether users receive awareness training that matches the risks they face. An outside partner can build the tooling, but it cannot accept risk or decide what the policy requires on your behalf.

Policy and scope: Set the malware protection standard, the systems it covers and the owner of each platform, including endpoints, servers and any self-hosted detection services.
Operating the controls: Review detections, triage alerts and approve allowlist changes on a defined schedule rather than only after an incident.
Awareness content: Decide what users are taught about phishing, risky downloads and reporting suspicious files, and confirm that completion is recorded under the awareness control.
Incident handling: Own the response steps for an infected host, including isolation, recovery and lessons learned.
Evidence ownership: Keep dated records of reviews, approvals and exceptions that an assessor can sample.

Before engaging anyone, confirm that a named internal owner can explain how each malware control operates and where its evidence is stored.

Where malware protection usually fails an audit and how to close each gap

Most malware protection findings under A.8.7 come from the gap between what is deployed and what can be shown. The cards below cover the failure points assessors test most often, with the fix and the evidence that closes each one. Each gap is a check the organization can run before an auditor arrives.

Awareness as a one-off onboarding video

A.8.7 asks for protection that is supported by appropriate user awareness, and awareness that happens once at onboarding rarely meets that test. Assessors look for training that covers phishing, malicious attachments, fake software downloads and reporting steps, repeated over time and updated after real incidents. Check whether training records show who completed what and when, and whether the content changed after the organization saw an infection or a targeted lure. Related expectations sit under A.6.3 Information security awareness, education and training.

Detection deployed without a coverage baseline

Installing endpoint detection software on some machines does not show that malware protection covers the estate. An assessor will ask which hosts report, which are missing agents, and how the organization knows. Build a baseline that lists every endpoint and server, then use a recurring inventory comparison against the detection console to find gaps. Osquery can schedule queries across a fleet to report running processes and agent status, which gives a second view of coverage that does not depend on the detection vendor's own console.

Servers and unmanaged devices left out of scope

Malware protection is often documented for laptops and forgotten for servers, build agents, kiosks and devices that IT does not manage. These are the systems attackers reach through lateral movement, so an audit scope that omits them is a visible gap. Define the scope in the protection policy by asset class, then confirm each class has either an agent, an equivalent control or a documented risk acceptance. Ask the team to name who owns each unmanaged device and what compensating control applies, such as network isolation or allowlisting.

No record of infection handling

Assessors frequently ask what happened the last time malware was detected, and many organizations cannot show a sequence of events. A usable record captures detection time, affected host, the decision to isolate, how the host was cleaned or rebuilt, which accounts were reset, and whether other hosts were checked for the same indicator. Keep these entries in the incident or ticketing system, linked to the alert that started them. Alerts from Wazuh, which map to MITRE ATT&CK, can supply the starting timeline for the record.

Vendor reports accepted without local checks

A vendor's compliance dashboard or certificate describes the product, not the configuration running in the organization's environment. Assessors expect evidence from the organization's own systems, such as real-time protection status, signature update times, tamper protection settings and exclusions. Pull these settings from the endpoints or management console on a schedule and compare them to the policy. Ask the vendor to confirm which settings are configurable and which are fixed, since the answer determines what evidence you can produce.

Questions buyers ask about A.8.7 protection against malware

What does A.8.7 protection against malware actually require?

A.8.7 asks the organization to protect systems against malware and to back that protection with appropriate user awareness. In practice the control has two halves: technical measures that prevent, detect and repair malicious software, and people who know what to do when something looks wrong. The control does not name a product or a specific technique, so the assessor will look for a documented approach that fits your environment and evidence that it runs. Your Statement of Applicability should state whether the control applies, how it is implemented and where the evidence lives. Confirm the exact wording and any attributes with the current edition of ISO/IEC 27002:2022, which gives the guidance on this control.

How much effort does the malware control take to run?

The effort depends on how many endpoints, servers and user groups you run and how much of the stack is already managed. Most of the work is one-time design: choosing detection and response tools, deciding where allowlisting applies, setting web filtering rules and writing the handling procedure for infections. The recurring work is operational: reviewing alerts, keeping signatures or rules current, testing the response process and collecting evidence for each audit cycle. No supplied source gives a reliable hour or headcount figure for this control, so ask your implementer or auditor to break the estimate into one-time and recurring tasks for your own environment.

Can a small team run A.8.7 in-house?

A small team can usually run this control in-house if it has a clear owner, a manageable number of endpoints and tools that report centrally. The main risk for small teams is alert fatigue and untested response steps, not the absence of a large security department. A workable split is to let one administrator own endpoint protection and the response runbook, while a second person reviews alerts on a fixed schedule and signs off the evidence. Where the team lacks time or detection skills, buy outside help for the design and for periodic testing rather than for daily operations. The organization still owns the control and its decisions.

Which tasks can an implementation partner take on, and which must stay with us?

An implementation partner can plan the architecture, deploy and configure self-hosted tools, write runbooks, set up alert routing and prepare evidence packs. DeployOpen works this way: it prepares systems, controls and evidence inside your own infrastructure, but it does not issue audit reports or certificates. Decisions that must stay with you include the risk appetite for malware events, approval of allowlist exceptions, the choice of which users receive awareness training, and the authority to isolate a machine during an incident. Independent auditors or certification bodies assess the result. Ask any partner to put these responsibilities in the written scope before work starts.

What drives the cost of meeting A.8.7, and what should we request in a quote?

The main cost drivers are the number and type of endpoints and servers, the number of sites and cloud accounts, whether you need allowlisting or only detection, how much log data you retain, and how many people receive awareness training. Costs fall into licences or hosting for tools, implementation labor, internal staff time, and periodic testing and audit support. Some costs are one-time, such as design and initial deployment, while others recur, such as licences, rule updates and reviews. A useful quote lists the scope in writing, the deliverables, the systems covered, the responsibilities split between you and the partner, the assumptions about your environment and any retainer for ongoing work. DeployOpen does not publish a price list; a quote follows from the written scope.

How long does it take to put malware protection in place?

Duration depends on the size of the estate, the state of current tooling and how quickly approvals move through your change process. A pilot on a single user group is usually faster than a fleet rollout, and allowlisting generally takes longer than detection because it needs application inventories and exception handling. No researched figure in this context gives a standard duration, so ask any partner for a phased plan with milestones tied to deliverables. Also ask the auditor how much operating history they expect before they test the control, since evidence has to show the process running over time, not only that it was configured.

Are open-source tools enough to evidence A.8.7?

Open-source tools can produce much of the evidence for the technical half of the control if you configure them, run them continuously and keep records. For example, osquery can run scheduled queries across a fleet to inspect running processes, loaded kernel modules, open network connections and file hashes, and Wazuh can compare collected events against a large ruleset and write alerts to files and a dashboard. Velociraptor can collect forensic artifacts from endpoints during an investigation, and OpenSearch Security Analytics can match logs against Sigma rules and record findings. These tools do not decide your policy or replace user awareness, so you still need a documented procedure and training records. Confirm each tool's current capabilities and licence terms against its own documentation before you rely on it in an audit.

Which evidence will an auditor ask to see for A.8.7?

Auditors usually ask for a current policy or standard for malware protection, a list of covered assets, configuration records for detection and web filtering, samples of alerts and how they were closed, records of incident handling and the awareness training material and completion records. They may also sample a specific infection case and follow it from detection to recovery. Keep exports with timestamps, rule versions and change records so that the evidence shows the control operating throughout the audit period. Confirm the exact sampling approach and evidence formats with your certification body before the audit, because requirements vary between bodies and between accreditation schemes.

How DeployOpen scopes and prepares A.8.7 malware evidence

DeployOpen plans, implements and documents the self-hosted open-source tooling that supports malware protection, awareness and infection handling inside your own infrastructure. We prepare systems and evidence for your assessment, while your organization owns the control and an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which endpoints, servers and networks fall under the malware protection scope and which are excluded.
Confirm which detection, allowlisting and web filtering components will run and where their logs and reports are stored.
Define the awareness and training elements that accompany the technical controls and who owns each one.

How we build

Deploy and configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
Set up osquery queries for running processes, kernel modules, network connections and file hashes across the fleet.
Connect Wazuh alerting and OpenSearch Security Analytics rules so malware-related events reach the people who handle them.

How we hand over

Document configurations, query definitions, rule sets and alert routing so your team can reproduce and explain them.
Provide a mapping of each technical component to the evidence an assessor would ask to see for the control.
Train your operators on reviewing findings, running Velociraptor hunts for infection triage and recording outcomes.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of the malware controls are available as a retainer.
Confirm with your auditor which evidence formats and sampling periods they will accept before handover is finalized.