---
title: "ISO 27001 Annex A 8.7: how to implement protection against malware"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-7-protection-against-malware
published: 2023-06-19
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.8.7 Protection against malware"
journeyStage: implementation
---

# ISO 27001 Annex A 8.7: how to implement protection against malware

## Key takeaways

ISO 27001 Annex A 8.7 treats malware defence as a system of layers across prevention, detection and recovery, not an antivirus install. Managed EDR, filtered delivery routes, privilege restriction and a tested restore work together. Most of the evidence can be generated automatically from EDR and MDM data.

- **Control type** — Annex A 8.7 is preventive, detective and corrective, protecting confidentiality, integrity and availability by combining filtering, monitoring and recovery rather than relying on one antivirus product.
- **Technical core** — Deploy centrally managed EDR on every Windows, macOS and Linux endpoint, server and cloud VM, then filter email, web and DNS traffic to cut off the routes malware uses.
- **Policy question** — No standalone policy is needed at 25–250 people. A malware section in your operational security procedures covers deployment, responders and deactivation approval, and it audits fine.
- **Audit focus** — Auditors reconcile EDR coverage against the device inventory, trace a recent detection, test the deactivation log and ask for the latest restore test, sampling roughly 90 days of records.

The enterprise security questionnaire asks how you would contain a ransomware-infected laptop. Your honest answer is "we run antivirus", and the deal waits. This guide shows IT managers and compliance leads at 25–250-person firms how to implement ISO 27001 Annex A 8.7 as a system of layers. Built that way, it satisfies both the Stage 2 auditor and the buyer.

It covers the technical stack, the policy question, exceptions, ransomware recovery, what auditors test and how to generate the evidence automatically.

## What does ISO 27001:2022 Annex A 8.7 protection against malware require?

ISO 27001:2022 Annex A 8.7 requires protection against malware that is implemented as a system, not a product: detection software supported by restricted installation, filtered delivery routes, patched vulnerabilities, trained users and a rehearsed recovery. The control is preventive, detective and corrective, and protects confidentiality, integrity and availability.

Malware here means ransomware, trojans, worms and spyware alike. The control follows each one from the inbound email to the restore. It also covers the dull corners: keeping protection on during maintenance, and deciding when it may be switched off.

The three classifications map to layers you can point at:

- **Preventive:** filtering, allowlisting and least privilege that stop infection.
- **Detective:** behavioural monitoring that spots what slipped past.
- **Corrective:** isolation, clean-up and restore that put the business back.

Malware steals data, tampers with it and locks it up with equal enthusiasm, so all three security properties are in play.

The scope is wide because the threat is. [NIST SP 800-83 Rev. 1 Guide to Malware Incident Prevention and Handling](https://csrc.nist.gov/pubs/sp/800/83/r1/final) identifies malware as the most common external threat to hosts, and it asks organisations to improve prevention and incident handling together. Ransomware is the incident most likely to end a 25–250-person firm: days of outage, client data staged for leverage, and a recovery bill that dwarfs years of prevention spend.

Insurers and auditors now look for exactly this. Cyber insurers check your EDR coverage and backup isolation before quoting. An auditor reads the control as a test of how seriously you run operations.

Treating the control as "we bought antivirus" leaves one layer carrying a load it was never designed for. Filtering, least privilege, training and a recovery plan exist to share that load.

## How do you implement ISO 27001 Annex A protection against malware technically?

Deploy a centrally managed EDR product on every endpoint and server, including Windows, macOS, Linux and cloud VMs, with automatic updates and one console showing health. Then cut off delivery routes with email filtering, attachment sandboxing and web or DNS filtering. For a 50-person firm, this is one to two weeks of effort.

Work through the technical core in this order:

1. **Start from the asset list.** The asset inventory under A.5.9 is the list EDR must match, so every laptop, server and VM goes on it first.
2. **Deploy managed EDR.** Cover Windows, macOS, Linux servers and cloud VMs from one console, with automatic engine and definition updates and agent health visible in one place.
3. **Filter email.** Add spam filtering, attachment sandboxing and SPF and DKIM checks, since most infections arrive by mail or browser.
4. **Filter web and DNS.** Block known-bad destinations and command-and-control callbacks.
5. **Pre-authorise isolation.** Agree in writing who may trigger EDR's host-isolation action, so containment is one click rather than a debate.

EDR is the real upgrade over signature antivirus. It spots behaviour, not just known signatures, and it can isolate a host remotely. Business-tier licensing is within reach at this scale.

The [NCSC device security guidance on antivirus and security software](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/antivirus-and-other-security-software) frames security software as one part of a set. It works alongside network defences and device configuration, and it needs prompt, automated updates. Filtering at the mail and web edge is cheaper than detection later, because every blocked lure is an incident you never triage.

Platform immunity is not an argument an auditor accepts. Macs, Linux servers and cloud virtual machines need the same protection as Windows laptops, unless a documented risk assessment justifies compensating controls for a specific system. "Malware is a Windows problem" is a belief attackers stopped sharing years ago.

Consumer-grade or unmanaged protection fails differently. With no central console there is no coverage report, no alerting and no evidence, so the auditor has nothing to reconcile against the inventory.

Do this first. It is one of the biggest risk reducers in the programme, and the console starts building audit evidence the day the agents check in.

## Do you need an ISO 27001 protection against malware policy?

No standalone policy is required at 25–250 people. A malware-protection section within your operational security procedures is the norm and audits fine, provided it records what is deployed where, who responds to a detection, and how disabling protection is authorised. A separate policy document is a large-enterprise pattern, not a requirement.

Write the section so each statement is something the tooling can prove. It should record:

- **Deployment:** which protection runs on which platforms, covering EDR scope plus mail, web and DNS filtering.
- **Response:** who triages a detection, who can isolate a host, and who deputises when they are away.
- **Deactivation:** the route for switching protection off, detailed in the exceptions section below.
- **Exceptions:** systems that cannot run an agent, with the compensating controls for each.

Auditors read the section against the console. Name responders by role as well as by person, so the alert route survives leave and leavers.

If a customer questionnaire asks for an antivirus policy or an email security policy by name, point it at this section. A second document drifts out of date, and a drifting document is a finding waiting for a sample.

## What does layered malware defence look like in practice?

Layered defence stacks endpoint detection with least privilege, application allowlisting, patching under A.8.8 and user awareness under A.6.3, so no single failure is fatal. The NCSC states there is no way to completely protect an organisation against malware infection, which is why it advises defence in depth with several mitigations at each layer.

Read the [NCSC guidance on mitigating malware and ransomware attacks](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks) as a design brief: layers, several mitigations in each, and regular offline backups behind them. The stack around the endpoint agent looks like this:

- **Least privilege.** Take local admin off standard users and restrict what can be installed. Malware that cannot gain a foothold or persist is malware you did not have to detect.
- **Application allowlisting.** On high-risk or fixed-function machines, only named software runs. This is the stronger form of installation control.
- **Patching.** Exploited vulnerabilities are malware's other front door, so your A.8.8 process does half this control's work.
- **Awareness.** Under A.6.3, train people on suspicious attachments, credential lures and rogue installers. The control treats user awareness as part of itself, not an optional extra.
- **Segmentation.** Arrange the network so one infected machine cannot reach everything.
- **Threat intelligence.** Name a defined, reputable source and a person who reads it.

Local admin is where the layers collapse. A user who can disable the agent or install the trojan undoes every other layer. Remove that right before tuning anything else.

The table shows what each layer stops and what it leaves behind for the auditor.

| Layer | What it stops | Cadence | Evidence left |
| --- | --- | --- | --- |
| Managed EDR | Execution, persistence and spread of malware | Continuous; agent health checked daily | Coverage report against the device inventory |
| Email and web/DNS filtering | Malicious attachments, known-bad destinations, callbacks | Continuous; quarterly rule review | Filter configuration, sandboxing and block rules |
| Least privilege | Unapproved installs and agent tampering | Enforced by baseline; drift checked monthly | Configuration baselines showing admin-rights removal |
| Application allowlisting | Unapproved executables on high-risk machines | Updated with each approved software change | Allowlist and change tickets |
| Patching (A.8.8) | Exploitable vulnerabilities | Per your patch timelines | Patch compliance reports |
| Awareness (A.6.3) | Credential lures and rogue attachments | Annual training plus occasional simulations | Completion records and simulation results |
| Backups (A.8.13) | Unrecoverable encryption | Scheduled; restore tested periodically | Immutability settings and restore-test record |

## What if protection has to be switched off, or a system can't run an agent?

Disabling protection is allowed only through a documented exception: a named approver, written justification, compensating care and a review date to switch it back on. Systems that cannot run an agent, such as legacy machines and appliances, need a documented risk assessment and compensating controls like isolation and tight change control.

Legitimate reasons exist. A developer's build breaks under the agent, or a maintenance window needs a service stopped. The control does not forbid either, but it does expect the act to leave a trail. Each deactivation record should hold:

- **A named approver** with the authority to accept the risk.
- **Written justification,** such as the specific deployment the agent breaks.
- **Compensating care** while protection is off, for example restricting the machine's network access or watching it more closely.
- **A review date** or re-enable timer that switches protection back on.

The undocumented version of the same act is one of this control's most common audit findings.

Agentless systems are the second exception. Give each legacy machine, IoT device or appliance its own network segment and a named owner who accepts the residual risk. Revisit the assessment when the system is upgraded or replaced, because the exception should end when its reason does. Documented and compensated is acceptable; ignored is a finding.

Protection switched off 'temporarily', with no re-enable timer, is a permanent gap that nobody has yet noticed.

## How do you prepare for ransomware recovery under Annex A 8.7?

Prepare the failure day: keep backups that malware cannot encrypt, using offline or immutability-protected copies under A.8.13, prove a restore works, and hold a short isolate-triage-clean-restore playbook. Firmware-level infections mean reimaging, not cleaning, which is why the tested backup matters more than the disinfectant.

Offline or immutable copies cannot be encrypted or deleted by whoever holds a stolen admin session. Auditors want to see that setting, plus a record of the latest restore test. Insurers ask for the same two things before they quote.

Keep the playbook short enough to use under pressure:

1. **Isolate.** Trigger the host-isolation action pre-authorised in the technical section.
2. **Triage.** Use the EDR timeline to establish what executed, what spread and which data was touched.
3. **Clean.** Remove the malware where the evidence supports it, and reimage where persistence or firmware compromise is possible.
4. **Restore.** Bring systems back from a verified copy, then lift isolation once checks pass.

Rehearse it once with a real system. Restore the file share or database the business would miss first, and time it. The strongest exhibit is a dated restore-test record showing real data coming back, because it proves the recovery half instead of describing it.

A backup reachable with the credentials malware steals is a second target, not a recovery plan.

## How do auditors test ISO 27001 Annex A 8.7?

Auditors check EDR agent coverage against the asset inventory, trace a recent detection from alert to close-out, test the deactivation log against a real maintenance window, and ask for the latest restore test. They typically sample a 90-day window of detection records and training completions for named staff.

Expect questions like these in the room:

- "Show me your EDR console next to your device inventory. What is the coverage gap, and why?"
- "Walk me through your last malware detection, from alert to close-out."
- "Who can switch endpoint protection off, and what is the approval trail?"
- "What about the Macs, the Linux servers and the build agents?"
- "If ransomware fired at 9am tomorrow, how would you contain it, and when did you last prove a restore works?"

In certification-body practice, grading follows scale. The total-breakdown cases grade major:

- whole platforms left unprotected;
- no detection on servers holding client data;
- backups that a ransomware event would also encrypt.

One machine missing an agent, a lapsed training completion or an undocumented one-off deactivation grades minor. Minors add up to a major when they form a pattern.

A claimed "no detections in 90 days" invites the follow-up question of whether the tooling is quiet or just unwatched. The usual cause of unwatched is the alert route, so trace one test alert to a named person before the audit does.

Alerts sent to a mailbox nobody owns mean detection exists and response doesn't.

## How do you automate Annex A 8.7 evidence with GRC engineering?

Malware defence produces continuous telemetry, so its evidence can be automated. A scheduled job compares the EDR agent list with the MDM register and opens a ticket per unprotected device. Deactivation runs as a ticketed workflow with a re-enable timer, and detections flow into ticketing, so the 90-day sample becomes an export filter.

Two further checks complete the picture:

- **Health and currency monitoring.** Agent heartbeats, definition ages and disabled-state alerts feed a dashboard, so a silent or stale agent becomes a same-day ticket instead of an audit-time discovery.
- **Backup-integrity checks.** Scheduled restore verifications and immutability-policy checks keep the recovery half of the control continuously proven.

These builds run on EDR and MDM APIs, and they are the kind of work our GRC engineering service delivers. The judgement calls stay human: exception authority, risk acceptance for agentless systems and ownership of the incident playbook. A fractional CISO engagement is one route for those.

At this point the control proves itself daily. The insurer and buyer questions from the opening section get answered with a dashboard and an export, not a scramble.

## Frequently asked questions

### Does A.8.7 require EDR rather than traditional antivirus?

Our guidance is EDR, because the forensic timeline turns "something happened" into "here is what happened", and that is what an incident ticket needs. At current business-tier pricing it is the sensible default even at 30 people. If you keep signature antivirus, expect the auditor to ask what covers behavioural detection and where remote isolation comes from.

### Do Linux build agents and CI/CD runners fall under A.8.7?

Yes, if they are in scope of your ISMS, and auditors ask about them by name. Ephemeral runners are the awkward case. Bake the agent into the base image so every instance registers with the console on boot, then include the runner pool in your daily coverage reconciliation.

### Are phishing simulations required to evidence the user-awareness layer of A.8.7?

User awareness is the requirement, and simulations are one way of evidencing it. Our guidance is to run them occasionally and keep the last year's results next to training completions. Follow repeat clickers with targeted training rather than a report naming individuals.

### What counts as an acceptable threat-intelligence source for A.8.7?

A defined, reputable source is enough. The NCSC's alerts and your EDR vendor's advisories qualify, and neither needs a platform purchase. Record in your procedures who reads the feed and how often, and raise a ticket whenever an advisory affects software you run.