ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 malware protection is the Annex A 8.7 control, and it is the control auditors most often find under-evidenced — not because organisations have no antivirus, but because the control asks for roughly thirteen separate things and a licence renewal only answers one of them. If your Statement of Applicability justification for A.8.7 reads “endpoint protection deployed to all managed devices,” you have described one guidance limb out of thirteen and left the other twelve without evidence.
This guide walks ISO 27001 malware protection as an auditor reads it: what ISO/IEC 27002:2022 actually asks for under 8.7, which parts carry no documentation requirement at all, the operational-technology exception that most templates ignore, and the specific records that close the control out in a stage 2 audit.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Annex A of ISO/IEC 27001:2022 (Edition 3, published October 2022, 19 pages, with the free Amendment 1:2024 climate-action change) lists 93 controls across four themes. A.8.7 sits in the technological theme and is stated in a single line: protection against malware shall be implemented and supported by appropriate user awareness.
That sentence is the whole requirement for ISO 27001 malware protection in the standard itself. The work sits in ISO/IEC 27002:2022, the guidance companion, whose purpose statement for 8.7 is to ensure information and other associated assets are protected against malware. Two words in the Annex A line carry disproportionate audit weight:
In the 27002 attribute scheme the control is preventive, detective and corrective. That triple classification is the clearest signal of what ISO 27001 malware protection is supposed to cover: stopping malware arriving, noticing it when it does, and getting back to a known-good state afterwards. Most implementations are strong on the first, patchy on the second and silent on the third.
A frequent misreading of the 2022 edition is that ISO 27001 malware protection was tightened or newly introduced. It was not. A.8.7 maps one-to-one from A.12.2.1 Controls against malware in ISO/IEC 27001:2013. The eleven genuinely new controls in the 2022 edition are A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23 and A.8.28 — A.8.7 is not among them.
What did change is the company it keeps. Web filtering (A.8.23) was carved out as its own line, so the “block malicious websites” limb of malware defence now has a separate control with its own justification and its own evidence trail. If you are writing both, read our guide to ISO 27001 web filtering under A.8.23 alongside this one so the two SoA entries do not simply repeat each other.
| Attribute | Position under ISO/IEC 27001:2022 |
|---|---|
| Control reference | A.8.7, technological theme (one of 34 technological controls) |
| 2013 predecessor | A.12.2.1 Controls against malware — direct one-to-one mapping |
| New in 2022? | No |
| Control types | Preventive, detective and corrective |
| Documented information required by the clause | None named |
| Review or scan frequency stated | None stated |
| Adjacent controls | A.8.8 vulnerability management, A.8.13 backup, A.8.19 software on operational systems, A.8.23 web filtering, A.8.32 change management, A.6.3 awareness |
ISO/IEC 27002 frames the control as requiring an end-to-end approach, and states plainly that anti-malware software on its own is an inadequate set of measures. Four limbs have to be present. Testing your ISO 27001 malware protection against these four limbs is a faster self-assessment than working down the guidance list item by item.
| Limb | What it covers | Where the evidence usually lives |
|---|---|---|
| Anti-malware tooling | Detection and repair software on endpoints, servers, gateways and messaging; definition and engine updates; scanning of downloaded and opened files | EDR or endpoint console coverage report, update status, exclusion list |
| Awareness | Users able to recognise and act on suspicious attachments, links, macros and installation prompts | Training records, phishing simulation results, reporting-rate metrics |
| Controlled access and software | Application allowlisting, restriction of unauthorised software, least privilege, controls on files obtained from external networks and media | Allowlist policy, admin-rights register, software inventory reconciliation |
| Change management | No unapproved change that bypasses protection; maintenance and emergency work that cannot silently introduce malware | Change records showing malware impact considered, emergency change reviews |
The third and fourth limbs are where most audits bite. An organisation with excellent endpoint tooling and no software inventory, or with a change process that never asks whether a change disables protection, has an incomplete control regardless of how good the agent is.
ISO/IEC 27002’s guidance for 8.7 runs to roughly thirteen implementation limbs. Grouped by the team that has to do them, they look like this.
| Group | Guidance limbs (paraphrased) | Owner |
|---|---|---|
| Prevent execution | Rules and controls that prevent or detect unauthorised software, such as application allowlisting; protective measures for files and software obtained from external networks or other media; reduction of vulnerabilities malware can exploit | IT operations with security |
| Prevent arrival | Prevent or detect access to known or suspected malicious websites; scan network traffic, email and messaging attachments and web content at the points risk indicates | Network and messaging |
| Detect | Install and regularly update detection and repair software; place tooling defence-in-depth at gateways, servers and endpoints, allowing for evasion techniques such as encryption; run regular automated validation scans of systems supporting critical processes and investigate unapproved files or unauthorised changes | Security operations |
| Contain and recover | Isolate environments where a successful attack would be catastrophic; maintain online and offline backups and tested recovery measures; define incident handling procedures, responsibilities and recovery protocols | Security operations with business continuity |
| Govern | Protect against introduction of malware during maintenance and emergency procedures that bypass normal controls; operate an authorisation process for temporarily disabling protection with documented justification | Change and service management |
| Inform | Train all users to identify and act on malware-bearing content; collect current information on new malware; verify that malware information is accurate and comes from qualified, reputable sources | Security awareness and threat intelligence |
Two of those limbs reward a second look. “Isolate environments where a successful attack would be catastrophic” is a blast-radius requirement, not a tooling one — it is the clause that asks whether your backup estate, your identity provider and your production environment can all be reached from one compromised laptop. And “verify that malware information is accurate and comes from qualified sources” is a guard against hoax and scam advisories, which sit naturally alongside your ISO 27001 threat intelligence arrangements under A.5.7.
ISO/IEC 27002’s additional notes for 8.7 acknowledge something that generic templates do not: some systems cannot accommodate malware protection software at all. Industrial control systems are the named example, and in practice the list is longer — medical imaging equipment, building management controllers, legacy embedded devices, laboratory instruments and anything under a vendor support agreement that voids on third-party agent installation.
This matters because the standard default justification — “anti-malware is deployed to all endpoints” — is factually untrue in any estate containing operational technology, and an auditor who walks the plant floor will establish that in about four minutes. The conforming position is not to pretend coverage is universal; it is to identify the systems that cannot carry an agent and show compensating measures: network segmentation, removable-media control, unidirectional gateways, allowlisting at the host where the platform supports it, and monitoring of the segment the devices sit on.
The same notes make a recovery point worth quoting back to the board. Where an infection reaches the operating system kernel or device firmware, re-imaging the operating system — and sometimes the firmware itself — may be the only route back to a secure state. That is a restore exercise, not a clean-up, and it belongs in your tested recovery plans under ICT readiness for business continuity.
One ISO 27001 malware protection guidance limb produces more audit findings than its length suggests: the requirement for a process allowing malware protection to be temporarily or permanently disabled where that is operationally necessary, with approval and documented justification.
Every organisation does this. An installer fails, a build agent times out, a developer’s toolchain trips a heuristic, so somebody adds an exclusion or stops the service. Almost no organisation records it. The result is an exclusion list that has grown for years with no owner, no expiry and no record of who approved what — and exclusion lists are a well-known attacker objective precisely because they are unreviewed.
A conforming implementation needs four things, none of which require new tooling: a named approver, a written justification per exclusion or disablement, an expiry or review date, and a periodic reconciliation of the live exclusion list against the approved register. That reconciliation is the single highest-value piece of evidence you can produce for ISO 27001 malware protection, because it proves the governance limb rather than the product.
Stage 2 auditors sample, and for this control the samples are predictable, and the gap is almost always between console coverage and estate inventory.
| Auditor question | Evidence that closes it | Common failure |
|---|---|---|
| Is protection deployed everywhere it should be? | Endpoint console export reconciled line-by-line against the asset inventory, with named exceptions | Console shows 412 agents, inventory shows 487 assets, nobody can explain the 75 |
| Are definitions and engines current? | Update-status report showing devices out of date beyond a defined tolerance, with follow-up | A tolerance exists in nobody’s head and in no document |
| Who approved these exclusions? | Exclusion register with justification, approver and review date; reconciliation against the live list | No register at all |
| Does detection actually work? | A dated detection test — the EICAR anti-malware test file is the standard harmless way to do it — recorded per platform | Protection assumed to work because it is installed |
| What happens when something is found? | Closed incident tickets showing quarantine, investigation and root cause, linked to your incident process | Alerts auto-resolved with no human record |
| How do users know what to do? | Training content covering attachments, macros and installation prompts, plus the reporting route and its usage | Generic awareness deck with no malware-specific module |
| Can one compromise reach everything? | Segmentation diagram and offline or immutable backup evidence | Backup server joined to the same domain as the workstations |
The detection test is worth building into the routine. It is cheap, it is repeatable, and it converts “we have antivirus” into a dated record that the control operated — which is exactly the distinction between implementation and effectiveness that your awareness and training programme has to make as well.
If you are running more than one framework, A.8.7 crosswalks cleanly and the crosswalk is useful in its own right: the US control catalogues are more prescriptive, so they are a practical checklist for an ISO control that deliberately is not.
| Framework | Reference | What it adds beyond A.8.7 |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SI-3 Malicious Code Protection | Requires signature-based and/or non-signature-based mechanisms at system entry and exit points, automatic updates under configuration management, periodic plus real-time scanning, a defined response (block, quarantine, alert), and explicit handling of false positives and their availability impact |
| NIST SP 800-53 Rev. 5 | SI-3(6) Testing and Verification | Periodic testing of the mechanism using benign code — the formal basis for the EICAR-style detection test above |
| NIST SP 800-53 Rev. 5 | SI-3(10) Malicious Code Analysis | Analysis tooling to characterise detected code and feed the findings into incident response |
| CIS Controls v8.1 | Control 10 Malware Defenses, safeguards 10.1–10.7 | 10.1 deploy and maintain anti-malware software, 10.2 automatic signature updates and 10.3 disable autorun and autoplay for removable media are all IG1; 10.4 automatic scanning of removable media, 10.5 anti-exploitation features, 10.6 central management and 10.7 behaviour-based anti-malware are IG2 and IG3 |
| NIST SP 800-83 Rev. 1 | Guide to Malware Incident Prevention and Handling for Desktops and Laptops | Incident-handling depth; note that Revision 1 is dated July 2013, so treat the tooling discussion as dated and the process guidance as sound |
The CIS mapping is the most useful for a small team. Three of the seven safeguards sit in Implementation Group 1 — the tier CIS defines as essential hygiene for every organisation — and disabling autorun and autoplay on removable media is a five-minute group policy change that closes a real limb of A.8.7. The full control catalogue is set out in our pillar guide to the 93 ISO 27001:2022 Annex A controls, and the detail on SI-3 is in the NIST SP 800-53 Revision 5 catalogue.
Three things people invent about ISO 27001 malware protection and then get marked down for.
There is no mandatory anti-malware policy. A.8.7 names no documented information, and no clause of ISO/IEC 27001 requires a standalone malware protection procedure. It does not appear on the list of mandatory ISO 27001 documents. A short policy is still the easiest way to show intent and to carry the exclusion-approval rules, but write it because it is useful, not because you think the standard demands it.
There is no stated scan frequency. Not in A.8.7, not in 27002’s guidance. The guidance asks for regular automated validation scans and regular updates; “regular” is yours to define against risk and then to meet. Pick a figure, write it down, and measure against it — an auditor marks the gap between your stated tolerance and your actual state, not the figure itself.
Annual is a convention, not a requirement. The same applies to the awareness limb: ISO/IEC 27001:2022 states no training frequency anywhere, and 27002 says only “periodically”. Annual training is industry habit. Cite it as your decision, never as the standard’s.
A fourth, subtler point: the reduction of exploitable vulnerabilities is a named limb of A.8.7, which means your patching evidence does double duty. If you are building both controls, the overlap is deliberate — see ISO 27001 vulnerability management under A.8.8 for how to avoid writing the same procedure twice.
No. ISO 27001 malware protection is stated as protection against malware supported by user awareness. It never names a product category, a vendor or a technology. Endpoint detection and response, application allowlisting or a hardened immutable platform can all satisfy the tooling limb, provided your risk assessment supports the choice and you can evidence that it detects.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
No. A.8.7 names no documented information and the control is absent from the mandatory document list, which runs to seven documents and six record categories. Most organisations write one anyway because the exclusion-approval process, the scanning tolerances and the OT exceptions need somewhere to live.
The standard sets no frequency. You define it from your risk assessment and your environment — continuous real-time scanning on endpoints with a scheduled full scan on servers is a common pattern — then show you meet the figure you set.
They are in scope. The guidance places detection at gateways, servers and endpoints, and the absence of a user removes the awareness limb, not the technical one. For container and serverless workloads the equivalent is image scanning in the pipeline, registry scanning and runtime detection — record the reasoning in your SoA justification so the auditor is not left guessing.
A.8.23 was introduced in 2022 to cover the outbound side — preventing access to malicious or unauthorised websites. A.8.7 covers detection and remediation of malicious code wherever it arrives, including email, removable media and software supply chain. They overlap at the “block malicious websites” limb and should cross-reference rather than duplicate each other in your SoA.
Auditors do not run malware on your systems. They sample records: coverage reconciliation, update status, exclusion approvals, detection-test results and closed incidents. A dated test record is how you demonstrate effectiveness without anyone touching a live system.
Build ISO 27001 malware protection around the four limbs rather than around the product. Reconcile your endpoint console against your asset inventory this week, build the exclusion register next, run a dated detection test per platform, and write the OT exception into your SoA justification before an auditor finds it for you. Those four pieces of evidence close more of A.8.7 than any licence upgrade will.
If you want the documentation layer already built, our ISO 27001 Toolkit ships 165 editable templates covering the full ISMS — Statement of Applicability, risk register, Annex A control procedures and the audit records that go with them — for $149, so the writing is done and the work left is the implementing.
October 18, 2026
October 18, 2026
October 15, 2026
October 15, 2026
October 14, 2026