Annex A 8.7: Protection Against Malware

Annex a 8.7: protection against malware requirement means you must implement and operate controls that prevent, detect, and respond to malware across your environment, and you must be able to prove those controls run consistently. Operationalize it by standardizing endpoint and server protections, controlling software execution, scanning key ingress points, and retaining repeatable evidence for audit. ¹

Key takeaways:

• Define a malware control standard (coverage, configs, logging, response) and apply it to endpoints, servers, cloud workloads, and email. ²
• Audits fail more often on missing operational evidence than on tool choice; set up recurring evidence capture from your EDR/AV and email security. ³
• Treat third parties as part of malware exposure: require malware controls for managed endpoints, support tools, and software deliveries. ²

Annex A 8.7 is straightforward on paper: protect systems and users from malware. In practice, teams stumble because “we have EDR” is not a control. Auditors will test whether protection is consistently deployed, appropriately configured, monitored, and tied to incident response and change management. They will also test whether you can show evidence across your full asset inventory, including remote endpoints, cloud workloads, and high-risk ingress paths such as email and downloaded files. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to convert 8.7 into a small set of enforceable requirements that IT and Security can implement: (1) standard malware protections by asset class, (2) controlled execution and safe handling of untrusted code, (3) monitoring and alert response, and (4) recurring evidence capture mapped to the control. Your goal is to make malware protection measurable and auditable, not aspirational. ²

This page gives requirement-level implementation guidance you can hand to operators, plus the artifacts you should expect back to pass an ISO 27001 assessment. ¹

Regulatory text

Control reference: ISO/IEC 27001:2022 Annex A 8.7 (Protection Against Malware). ¹

Provided excerpt (summary-level): “ISO/IEC 27001:2022 Annex A control 8.7 implementation expectation (Protection Against Malware).” ¹

What the operator must do: implement technical and procedural controls that reduce the likelihood of malware entering your environment, limit execution and spread when it does, and detect and respond with defined actions. You must also operate the control continuously and retain evidence that protections are deployed and monitored. ¹

Plain-English interpretation (what 8.7 really requires)

You need an end-to-end “malware defense” capability that is:

1. Deployed everywhere that matters (coverage),
2. Configured to a standard (policy),
3. Monitored with action taken (operations), and
4. Proven with evidence (assurance). ²

A single endpoint tool does not satisfy this by itself. Malware reaches you through email, web, removable media, software downloads, developer dependencies, and third-party remote access. Annex A 8.7 expects you to manage those paths with layered defenses and documented operating routines. ¹

Who it applies to (entity and operational context)

Applies to: service organizations seeking ISO/IEC 27001 certification or alignment, including SaaS providers, managed service providers, and internal shared-services teams that operate information systems. ²

Operational scope: any system that stores, processes, or transmits organizational information, plus supporting systems that can become a malware entry point (end-user devices, admin workstations, servers, VMs, containers, email, and collaboration tooling). Include BYOD if it can access corporate data. Include third-party managed endpoints if they connect to your network or handle your data. ²

What you actually need to do (step-by-step)

Use this as a build sheet for your control owner (typically SecOps) and your evidence owner (often GRC with IT/Security support). ²

1) Define your malware protection standard (write it down)

Create a concise standard that answers:

• Coverage requirement: which asset classes must have malware controls (workstations, servers, cloud workloads, email). ²
• Approved toolset: allowed EDR/AV agents, email filtering, sandboxing, web protection. Keep this short to reduce exceptions. ²
• Minimum configurations: real-time scanning, tamper protection, auto-update, scan schedules for high-risk folders, blocking policy for known-bad. ²
• Alerting and response: which detections are ticketed, triaged, escalated; how containment works (isolate host, kill process, quarantine file). ²
• Exception process: who can approve exclusions (for performance or false positives), time-boxed approvals, and compensating controls. ²

Deliverable: “Protection Against Malware Standard” mapped to Annex A 8.7 and your ISMS control matrix. ³

2) Prove deployment coverage against your asset inventory

Operational requirement: every in-scope asset is either protected or formally excepted. ²

Actions:

• Reconcile asset inventory vs. EDR/AV console inventory.
• Identify gaps: unmanaged endpoints, stale agents, offline hosts, shadow IT VMs.
• Fix with device enrollment, agent deployment automation, or network controls that block access until compliant. ²

Minimum evidence expectation: a recurring coverage report that ties back to the current asset list. ³

3) Control common ingress paths (email, web, downloads, removable media)

Make the requirement explicit for operators:

• Email: filtering for malicious attachments/links; blocking risky file types; sandboxing or detonation where available; policy for macros and external senders. ²
• Web and downloads: DNS/web filtering; browser hardening; blocking known malware categories; scanning downloaded files.
• Removable media: disable by default where feasible; scan on insertion; strict exception approvals. ²

Tie these to user policy: safe handling, reporting, and phishing/malware escalation paths. ²

4) Reduce execution and blast radius (hardening that helps 8.7)

Even though Annex A 8.7 is “malware,” auditors will accept layered controls that prevent execution/spread:

• Application allowlisting or controlled execution for high-risk admin workstations.
• Least privilege and removal of local admin rights where feasible.
• Segmentation between user and server networks; restrict lateral movement.
• Patch management integration for exploited software. ²

You do not need every technique, but you need a reasoned set that matches your risk assessment and environment. ²

5) Monitoring, triage, and incident linkage

Define an operational loop:

• Detections create tickets with severity and required response steps.
• Analysts document triage notes, containment actions, eradication actions, and recovery validation.
• Confirm lessons learned feed back into exclusions, hardening, and user controls. ²

If your IR process is separate, explicitly link malware detections to incident categories and escalation criteria. ²

6) Make evidence capture recurring and assessor-friendly

This is the most common gap: teams can’t show consistent operation. Build a lightweight evidence pack:

• Monthly (or other regular cadence you define) exports from EDR/AV: coverage, update health, top detections, response actions.
• Email security dashboards: blocked malware, quarantines, and disposition outcomes.
• Exception register: active exclusions with approvals and review dates. ³

Daydream tip (practical, not theoretical): set a recurring control “evidence task” that pulls the same reports each cycle and stores them with a short control attestation. That turns 8.7 into a repeatable control instead of a scramble before audit. ³

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Design artifacts

• Malware Protection Policy/Standard mapped to Annex A 8.7. ²
• Tooling architecture diagram or control description: endpoints, servers, email, web controls. ²
• Exception process and approval workflow. ²

Operational evidence

• Asset inventory and EDR/AV coverage reconciliation report.
• EDR/AV management console screenshots/exports showing:
  • agent deployment status,
  • signature/engine update status,
  • recent detections and actions taken. ³
• Email security logs/reports for malware quarantines and blocked attachments/URLs.
• Sample incident/ticket records for malware events, including containment and closure notes.
• Training or user guidance for reporting suspicious files/behavior (if part of your control design). ²

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Show me coverage.” Which endpoints/servers are protected, and how do you know you didn’t miss any? Bring the inventory reconciliation. ³
2. “Show me configuration.” Are protections enforced centrally, or can users disable them? Demonstrate tamper protection and policy enforcement. ²
3. “Show me operations.” What happens when malware is detected? Provide tickets and analyst notes. ²
4. “Show me exceptions.” Why is this exclusion allowed, who approved it, and when is it reviewed? ²
5. “What about third parties?” If a third party connects remotely or provides managed endpoints, how do you ensure malware controls meet your standard? ²

Frequent implementation mistakes (and how to avoid them)

• Mistake: relying on “we bought EDR” without proving deployment. Fix: evidence pack must include coverage deltas vs. asset inventory. ³
• Mistake: unmanaged cloud workloads. Fix: require server/workload agents or equivalent cloud-native protections, and track them in inventory. ²
• Mistake: exclusions that never expire. Fix: time-box exclusions, require compensating controls, and review them on a defined cadence. ²
• Mistake: no operational linkage to incident response. Fix: define triage-to-IR thresholds and show at least a few closed examples. ²
• Mistake: evidence created “right before audit.” Fix: recurring evidence capture with consistent filenames, dates, and owners; Daydream can schedule and track this as a control operation task. ³

Risk implications (why assessors care)

Malware is a common root cause of availability loss, data compromise, and credential theft. From an ISO perspective, failure on 8.7 usually signals broader control-operation weakness: incomplete inventories, weak endpoint management, poor monitoring, and untested response. That drives nonconformities because the ISMS cannot demonstrate effective operation. ²

Practical 30/60/90-day execution plan

Numbers below are planning buckets, not a promise of elapsed time; scale based on your environment complexity and resourcing.

First 30 days (stabilize and define)

• Assign control owner (SecOps) and evidence owner (GRC).
• Publish the Malware Protection Standard and exception workflow mapped to Annex A 8.7. ³
• Pull current asset inventory and EDR/AV inventory; produce first gap list.
• Identify top ingress paths in your environment (email, endpoints, remote access) and document current controls. ²

By 60 days (close coverage gaps and operationalize)

• Remediate highest-risk coverage gaps (admin workstations, domain controllers, externally exposed systems).
• Centralize policy enforcement (prevent user disablement; enforce updates).
• Implement ticketing integration for detections and define response runbooks.
• Start recurring evidence capture cycle (reports, screenshots, tickets, exception register). ³

By 90 days (prove repeatability and audit readiness)

• Run a tabletop or operational review of malware response workflow using real recent detections or a controlled test file, then document outcomes. ²
• Review exceptions and remove stale exclusions.
• Produce an assessor-ready evidence folder: standard, coverage reports over multiple cycles, sample incidents, and change records for configuration updates. ³
• If you use Daydream, map tasks to control 8.7 and automate reminders plus evidence collection prompts so the control runs without heroics. ³

Frequently Asked Questions

Does Annex A 8.7 require a specific anti-malware tool or EDR product?

No tool is mandated by ISO 27001. Assessors focus on whether your controls prevent/detect/respond to malware and whether you can prove consistent operation. ²

Are servers and cloud workloads in scope, or just employee laptops?

Anything in scope for your ISMS can be in scope for malware protection, including servers and cloud workloads. Define asset classes explicitly in your malware standard and show coverage evidence per class. ²

How do we handle developer machines where AV exclusions are common?

Allow exclusions only through an approval workflow, document the business reason, add compensating controls where needed, and review exclusions on a defined cadence. Keep an exception register as audit evidence. ²

What evidence is “enough” for an ISO auditor?

Provide a written standard, proof of deployment coverage, proof of updates/config enforcement, and a sample set of detections or tickets showing triage and response. Recurring evidence beats one-time screenshots. ³

What about third-party support tools (remote access, RMM agents) that can deliver malware?

Treat them as part of your malware threat model. Require security controls in contracts and access controls in your environment, then verify operationally (approved tooling, monitored sessions, limited privileges). ²

We rarely see malware detections. Will that fail the control?

Low detections are not a failure by themselves. Auditors still expect proof that protections are deployed, updated, and monitored, plus evidence that alerts would route into triage and incident response if they occurred. ²

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index