Marcus Webb had been IT Director at Ferrow Industrial Supply for six years, and he could tell you the exact moment his Tuesday morning went sideways: 6:47 a.m., a Slack message from the overnight warehouse shift lead reading "why are all the label printers spitting out ransom notes." By 7:15, the finance team's shared drive was encrypted. By 8:00, the ERP system that ran order fulfillment for 140 distribution accounts was dark. By noon, Marcus was on a call with a incident response firm, outside counsel, and a ransomware negotiator he hadn't known existed twelve hours earlier, watching a countdown timer the attackers had helpfully embedded in the ransom note.
Ferrow Industrial Supply was a 380-employee industrial parts distributor — the kind of unglamorous, profitable mid-market company that rarely thinks of itself as a target. It had antivirus software on every machine. It had a firewall. It had, in Marcus's words during the post-incident review, "checked the malware box a long time ago and never looked at it again." What it did not have was endpoint detection and response, email attachment sandboxing, network segmentation between the warehouse network and the finance network, or a tested backup restoration process. The initial infection came from a malicious macro in an invoice attachment, opened by an accounts payable clerk who had received security awareness training exactly once, during onboarding, three years earlier.
The final bill: $2.3 million. That figure included the ransom itself (which the board, over Marcus's objection, ultimately authorized paying), six weeks of degraded operations, forensic investigation fees, breach notification costs for exposed customer records, and a customer contract that was not renewed the following quarter, explicitly citing "concerns about your security posture." Ferrow's cyber insurance covered a fraction of it, and the renewal premium the following year tripled — with a new sublimit specifically for ransomware.
Marcus's postmortem conclusion, delivered to a board that had never previously asked him a single question about malware controls, was blunt: "We had antivirus. We did not have a malware protection program." That distinction — between a single tool and a designed, layered, tested control — is exactly what ISO/IEC 27001:2022 Control 8.7, Protection Against Malware, is built to force organizations to confront before a Tuesday morning like Marcus's ever happens.
Who This Is For (and What You'll Walk Away With)
This guide is for ISMS owners, IT and security managers, and vCISOs who need to design, document, and defend a malware protection control that will satisfy both a real-world ransomware threat and an ISO 27001 auditor. You'll walk away with a concrete layered control stack — endpoint protection and EDR, email and web filtering, application allowlisting, patch hygiene, backups for recovery, and user awareness — mapped to what Control 8.7 and its related ISO 27002:2022 guidance actually require. You'll also get the evidence auditors expect to see, the metrics that prove the control is working rather than just installed, and the common failure patterns that turn "we have antivirus" into a seven-figure incident. If you're building or refreshing your Statement of Applicability, this is the control that most often gets rubber-stamped as "trivial" and most often turns out to be the one that determines whether your organization survives its worst month.
What Control 8.7 Actually Requires
Control 8.7 sits in the Technological Controls theme of Annex A (8.1–8.34), alongside the broader ISO 27001 Technological Controls Overview that frames how the 34 technical controls fit together. Its stated requirement is deceptively short: protection against malware shall be implemented and supported by appropriate user awareness. That's the entire text of the control. Everything else — the specifics of endpoint tools, filtering layers, allowlisting, patch cadence, backup design — comes from ISO 27002:2022's implementation guidance, which describes malware protection as a combination of several categories of measure working together, not a single product.
The guidance is explicit that organizations should not rely on a single detection or prevention measure. It calls out controlling the installation and use of unauthorized software (which links directly to Technical Vulnerability Management and the separate control on installation of software on operational systems, Control 8.19), detecting and removing malware through appropriate protective software, keeping that software and its detection signatures current, managing technical vulnerabilities that malware could exploit, applying controls over networks and web access, and maintaining business continuity plans for malware-related incidents — including recovery from backups. The guidance also specifically flags awareness training on malware risks and reporting as a required complement, not an optional add-on.
Control 8.7 at a Glance
Attribute | Detail |
|---|---|
Control number | 8.7 Protection against malware |
Annex A theme | Technological Controls (8.1–8.34) |
Control type | Preventive, Detective, Corrective |
Information security properties | Confidentiality, Integrity, Availability |
Cybersecurity concepts (ISO 27002) | Protect, Detect, Respond, Recover |
Core requirement | Implement malware protection supported by user awareness |
New in ISO 27001:2022? | No — carried forward, but guidance updated to reflect modern threats and related new controls (8.19, 8.23) |
Closely related controls | 8.8 Vulnerability management, 8.13 Backup, 8.19 Software installation, 8.23 Web filtering, 6.3 Awareness, 5.24–5.28 Incident management |
That table is the single most important thing to internalize about this control: it touches every cybersecurity concept in the ISO 27002 attribute taxonomy — Protect, Detect, Respond, and Recover — simultaneously. Most organizations implement it as a pure "Protect" control (buy antivirus, done) and leave Detect, Respond, and Recover unaddressed. An auditor who understands the standard will ask about all four.
A Practitioner's Quick Reference to Malware Categories
Part of designing a layered control is understanding that "malware" is not one thing, and no single tool catches every category equally well.
Malware type | Typical delivery | Primary risk | Control layer most effective |
|---|---|---|---|
Ransomware | Phishing, exploited RDP/VPN, supply chain | Availability — encryption/extortion | Backup (8.13), EDR, network segmentation |
Trojans / RATs | Malicious attachments, drive-by downloads | Confidentiality — credential theft, persistence | Email filtering, EDR, allowlisting |
Worms | Network propagation, unpatched services | Availability — rapid lateral spread | Patch management (8.8), network segmentation |
Spyware / infostealers | Cracked software, malicious browser extensions | Confidentiality — data exfiltration | Web filtering (8.23), allowlisting |
Fileless malware / living-off-the-land | Malicious scripts, memory-resident payloads | Detection evasion | EDR/XDR behavioral analytics |
Wipers | Targeted attacks, hacktivism | Availability — irreversible destruction | Backup (8.13), segmentation, offline copies |
Cryptojacking | Web exploits, unpatched servers | Resource abuse | Patch management, monitoring (8.16) |
Why "Install Antivirus" Is Not a Compliance Strategy
The most common finding I raise as a lead auditor and consultant on Control 8.7 isn't a missing tool — it's a missing design rationale. An organization will point to a signature-based antivirus product deployed years ago and consider the control satisfied. But ISO 27002's guidance is unambiguous that reliance on a single measure is inadequate, and the threat landscape has made that guidance almost self-evidently correct: modern ransomware operators use fileless techniques, living-off-the-land binaries, and encrypted payloads specifically engineered to slip past signature-based detection. An antivirus tool that hasn't been paired with behavioral detection, email and web controls, patch discipline, and tested backups isn't a malware control — it's a single point of failure with a compliance sticker on it.
"I've stopped accepting 'we have antivirus' as an answer to the 8.7 audit question. My follow-up is always the same: show me the last time it caught something, show me your email filtering logs, and show me when you last restored from backup. Half the time, none of those things have ever happened." — Priya Chandrasekaran, Lead Security Architect, Solvent Bay Financial
This is why the layered model matters so much for certification purposes as well as for genuine resilience. An auditor sampling evidence for 8.7 is going to look for a documented anti-malware standard that names each layer, assigns ownership, and shows operating evidence — not a single line item on an asset register saying "AV: Yes."
The Defense-in-Depth Malware Control Stack
Think of Control 8.7 as requiring you to answer seven questions, each corresponding to a layer of defense: What stops malware from executing on an endpoint? What stops malicious email from reaching a user? What stops a user from reaching a malicious site? What stops unauthorized software from running at all? What closes the vulnerabilities malware exploits? What lets you recover if everything else fails? And what makes your people the control that catches what the tools miss?
Layer | Control objective | Representative tooling/practice | Primary ISO 27001 tie-in |
|---|---|---|---|
1. Endpoint protection / EDR-XDR | Detect and block malicious execution on devices | EDR/XDR agents, next-gen AV, behavioral analytics | 8.7, 8.1 (endpoint devices) |
2. Email security | Block malicious attachments, links, and impersonation | Secure email gateway, attachment sandboxing, DMARC/SPF/DKIM | 8.7, 5.14 (information transfer) |
3. Web filtering | Block access to malicious/compromised domains | DNS filtering, secure web gateway, category-based blocking | 8.23 Web filtering |
4. Application allowlisting | Prevent unauthorized software from executing | Allowlisting, application control policies | 8.19 Installation of software, 8.7 |
5. Patch and vulnerability management | Close exploitable weaknesses before malware uses them | Patch cadence, vulnerability scanning, CVE triage | 8.8 Vulnerability management |
6. Network segmentation & monitoring | Contain spread, detect anomalous lateral movement | VLAN segmentation, network monitoring, IDS/IPS | 8.20–8.22 Network security, 8.16 Monitoring |
7. Backup and recovery | Restore operations without paying or losing data | Immutable/offline backups, tested restoration | 8.13 Information backup |
8. User awareness | Reduce successful initial access, improve reporting | Phishing simulations, onboarding + annual training | 6.3 Awareness, education, training |
Every one of these layers has an owner, a cadence, and a piece of evidence behind it in a mature ISMS. If you can't name who owns network segmentation for malware containment purposes, that's a gap worth fixing before your next audit — not after it.
Layer 1: Endpoint Protection and EDR/XDR
Signature-based antivirus still has a place — it's cheap, fast, and catches the enormous volume of known, commodity malware that still accounts for a large share of real-world infections. But the center of gravity in endpoint protection has moved to Endpoint Detection and Response (EDR) and, increasingly, Extended Detection and Response (XDR), which correlates endpoint telemetry with network, email, and identity signals. EDR doesn't just ask "does this file match a known bad signature" — it asks "is this process behaving like ransomware," watching for behaviors like mass file encryption, shadow copy deletion, or unusual credential access, and it can often kill a process and isolate a host automatically before encryption completes.
Capability | Traditional AV | EDR | XDR |
|---|---|---|---|
Detection method | Signature-based | Behavioral + signature | Cross-domain behavioral correlation |
Fileless malware detection | Weak | Strong | Strong |
Automated response (isolate host, kill process) | Limited | Yes | Yes, across domains |
Visibility scope | Single endpoint | Endpoint fleet | Endpoint + network + email + identity |
Typical use case | Baseline hygiene, low-cost coverage | Mid-to-large environments, active threat hunting | Mature SOC, correlated detection across the estate |
ISO 27001 relevance | Minimum viable prevention layer | Core of a defensible 8.7 program | Strengthens 8.7 + 8.16 monitoring evidence |
For a Statement of Applicability entry, I recommend describing your endpoint layer in terms of capability (prevention + behavioral detection + automated containment) rather than naming a specific vendor product, since tools change but the control objective shouldn't.
Layer 2: Email Security and Anti-Phishing Controls
Email remains the single most common malware delivery channel, and it's the layer where prevention and awareness meet most directly. A defensible 8.7 program includes a secure email gateway that scans attachments and links, ideally with attachment sandboxing (detonating a suspicious file in an isolated environment before it reaches the user), plus domain-level anti-spoofing controls — SPF, DKIM, and DMARC — that reduce successful impersonation of trusted senders. This layer connects to Control 5.14 on information transfer, since email is one of the primary transfer channels an organization has to secure.
"Ninety percent of the ransomware cases I've responded to started with an email that a decent secure email gateway would have quarantined, or a user who had never once been shown what a real phishing attempt looks like. The tooling gap and the awareness gap are almost always both present at the same time." — Ben Castellano, Incident Response Lead, Castellano & Vance Forensics
Layer 3: Web Filtering (Control 8.23)
Malware doesn't only arrive by email — drive-by downloads, malvertising, and command-and-control callbacks to attacker-controlled infrastructure all depend on outbound and inbound web access. ISO 27001:2022 introduced web filtering as Control 8.23, and it directly supports 8.7's malware protection objective by blocking access to known-malicious or newly registered domains, restricting categories of risky content, and preventing compromised endpoints from communicating with their command-and-control servers. Organizations that haven't yet documented their web filtering approach as a discrete control (Web Filtering: Control 8.23) should treat it as a near-term gap — DNS-layer filtering is inexpensive relative to the risk it addresses and is one of the highest-ROI additions to a malware control stack.
Layer 4: Application Allowlisting and Controlling Unauthorized Software
ISO 27002's guidance on 8.7 explicitly calls out controlling the installation and use of unauthorized software as a malware-prevention measure, which ties directly to Control 8.19, Installation of Software on Operational Systems. Application allowlisting — permitting only approved executables to run rather than trying to block a constantly-updating list of bad ones — is one of the most effective technical controls against both commodity malware and targeted ransomware, because most malware simply cannot execute in an allowlisted environment regardless of how novel or well-obfuscated it is. It's also one of the most operationally demanding controls to run well, since it requires a disciplined change process for adding new approved software (which is itself evidence for Installation of Software on Operational Systems: Control 8.19). Many organizations start with allowlisting on the highest-risk assets — servers, finance workstations, engineering build systems — before expanding fleet-wide.
Layer 5: Patch and Vulnerability Management
Malware frequently doesn't need a user to click anything — it needs an unpatched, exploitable service. WannaCry and NotPetya both spread primarily through an unpatched SMB vulnerability, not phishing. This is why 8.7 and Technical Vulnerability Management, Control 8.8 are inseparable in practice: a malware protection program that doesn't include a disciplined patch cadence, vulnerability scanning, and prioritized remediation of internet-facing and high-severity exposures is leaving the exact door open that worm-style malware is built to walk through. Auditors increasingly ask to see the two controls' evidence side by side.
Layer 6: Network Segmentation and Sandboxing
Even with strong prevention, assume something will get through. Network segmentation limits how far it can spread — separating user networks from production/OT networks, isolating backup infrastructure from the general network (so ransomware can't encrypt your backups along with everything else), and using sandboxing to detonate suspicious files and links in an isolated environment before they reach a live endpoint. Ferrow Industrial Supply's postmortem specifically flagged the absence of segmentation between its warehouse network and its finance network as the reason a single infected workstation was able to reach and encrypt the ERP system.
Layer 7: Backup and Recovery
If prevention and detection both fail, recovery is what determines whether a malware incident is a bad afternoon or a $2.3 million catastrophe. ISO 27002's guidance for 8.7 explicitly ties malware protection to business continuity planning and recovery from backups, which is why Information Backup, Control 8.13, functions almost as a co-control for ransomware resilience specifically. The details matter enormously here: backups that are reachable from the production network, using the same credentials as production systems, are routinely encrypted or deleted by ransomware operators as a first step, precisely to remove the recovery option and force payment. A defensible backup strategy for malware resilience needs at least one copy that is offline, immutable, or otherwise isolated from the credentials and network path an attacker who has compromised your domain would have.
Layer 8: User Awareness
Every technical layer above has a human failure mode, and ISO 27002's guidance for Control 8.7 explicitly names user awareness as a required complement to technical controls — not a nice-to-have. This is covered in depth under Security Awareness, Education, and Training, Control 6.3, but for 8.7 purposes the specific content matters: users need to recognize phishing and social engineering attempts, understand why they shouldn't disable endpoint protection or install unauthorized software, and — critically — know how and where to report a suspected infection immediately, since early reporting is often the difference between an isolated incident and a network-wide encryption event.
Prevention vs. Detection vs. Recovery: Mapping the Malware Lifecycle
Auditors and mature security teams both find it useful to map each control in the stack against where it intervenes in the malware lifecycle, because a program that is entirely prevention-weighted (heavy on blocking, light on detection and recovery) has a very different risk profile than one that's balanced across all three.
Lifecycle stage | Objective | Representative controls | What "good" evidence looks like |
|---|---|---|---|
Prevention | Stop malware before it executes or reaches a user | Email filtering, web filtering (8.23), allowlisting, patching (8.8), awareness (6.3) | Filtering logs, patch compliance %, allowlist policy, training completion records |
Detection | Identify malware that evades prevention | EDR/XDR, network monitoring (8.16), log review | Alert volume/triage times, EDR detection reports, monitoring dashboards |
Response | Contain and eradicate an active infection | Incident management process, host isolation, forensics | Incident tickets, isolation logs, IR runbook execution records |
Recovery | Restore normal operations without data loss or ransom payment | Backup and restoration (8.13), business continuity (5.29–5.30) | Restoration test logs, RTO/RPO achievement, BC exercise reports |
Notice that Response draws directly on the organization's broader Incident Management process under Controls 5.24–5.28 — malware detection should trigger the same assessment, escalation, and evidence-collection process as any other security event, and Recovery draws on Business Continuity and ICT Readiness, Controls 5.29–5.30, since a serious malware outbreak is very often the disruptive event those plans are meant to address.
Visualizing the Malware Defense Stack
The diagram below is the shape I sketch on a whiteboard in almost every 8.7 workshop I run — prevention layers on the left, detection and containment in the middle, and recovery on the right, with awareness running underneath all of it as the layer that makes every other layer more effective.
flowchart LR
subgraph Prevent["PREVENT"]
A1[Email filtering<br/>+ anti-spoofing]
A2[Web filtering<br/>Control 8.23]
A3[Application<br/>allowlisting]
A4[Patch & vuln mgmt<br/>Control 8.8]
end
subgraph Detect["DETECT"]
B1[EDR / XDR<br/>behavioral analytics]
B2[Network monitoring<br/>Control 8.16]
B3[User-reported<br/>suspicious activity]
end
subgraph Respond["RESPOND"]
C1[Isolate host /<br/>segment network]
C2[Incident mgmt process<br/>Controls 5.24-5.28]
C3[Forensic evidence<br/>collection]
end
subgraph Recover["RECOVER"]
D1[Restore from<br/>isolated backups<br/>Control 8.13]
D2[Business continuity<br/>Controls 5.29-5.30]
D3[Post-incident<br/>review & lessons]
end
Prevent --> Detect --> Respond --> Recover
Awareness([User awareness — Control 6.3<br/>runs underneath every layer]) -.-> Prevent
Awareness -.-> Detect
Awareness -.-> RespondRansomware Resilience: The Control 8.7 Stress Test
Ransomware deserves its own section because it's the scenario ISO 27002's guidance most clearly has in mind when it talks about recovery and business continuity in the context of malware, and because it's the scenario that most exposes a shallow, single-layer implementation of Control 8.7. Ransomware operators today rarely rely purely on opportunistic phishing; many campaigns begin with a purchased set of stolen credentials or an exploited internet-facing vulnerability, followed by days or weeks of quiet lateral movement and privilege escalation before encryption and extortion. That dwell time is exactly where detection and network segmentation earn their keep — a well-configured EDR platform and reasonable network segmentation can catch the reconnaissance and lateral movement stage long before encryption starts.
The Ransomware Kill Chain and Where 8.7 Controls Intervene
Stage | Attacker activity | Control 8.7 intervention point |
|---|---|---|
Initial access | Phishing, exploited VPN/RDP, stolen credentials | Email filtering, patch management (8.8), awareness (6.3) |
Execution & persistence | Dropper runs, establishes foothold | Endpoint protection, allowlisting (8.19) |
Privilege escalation | Attacker gains admin/domain rights | Privileged access controls (8.2), EDR alerting |
Lateral movement | Attacker maps and spreads across network | Network segmentation, monitoring (8.16) |
Data exfiltration ("double extortion") | Sensitive data copied out before encryption | Web filtering (8.23), DLP controls, monitoring |
Encryption / extortion | Files encrypted, ransom note delivered | EDR automated isolation, incident management (5.24–5.28) |
Recovery decision | Pay, restore, or rebuild | Backup and recovery (8.13), business continuity (5.29–5.30) |
To Pay or Not to Pay
ISO 27001 doesn't take a position on ransom payment — that's a business and legal decision, often shaped by sanctions law, insurance terms, and the realistic viability of recovery without paying. What Control 8.7, properly implemented, does is remove payment as the only viable option. Ferrow Industrial Supply's board authorized a ransom payment because the alternative — rebuilding from backups that had never been tested and that turned out to be partially corrupted — looked slower and riskier than paying. That is precisely the scenario a mature 8.7 program is designed to prevent: an organization should never be making its recovery decision under the pressure of untested backups.
"The single question I ask every client before I ask about their firewall or their EDR license is: when did you last actually restore a full system from backup, not just check that the backup job said 'success'? Half the time the honest answer is 'never,' and that is the whole ballgame in a ransomware negotiation." — Dan Okafor, vCISO, Okafor Security Partners
User Awareness: The Human Firewall
Because Control 8.7 explicitly requires that malware protection be "supported by appropriate user awareness," this isn't a control you can satisfy with technology alone — an auditor will specifically look for evidence that awareness training addresses malware, not just generic security hygiene. Effective content for this control covers recognizing phishing and social engineering attempts, understanding why employees shouldn't disable or bypass endpoint protection (a shockingly common finding — users disabling antivirus because it "slows down my computer"), avoiding the download and installation of unauthorized software, and, most importantly, knowing the exact channel to report a suspected infection immediately. That reporting habit connects directly to Control 6.8, information security event reporting, and to the broader awareness program under Security Awareness, Education, and Training, Control 6.3.
"We ran quarterly phishing simulations for two years before our click rate dropped below five percent. The thing that actually moved the needle wasn't punishing people who clicked — it was making the report button faster and more visible than the delete button." — Grace Lindqvist, Head of IT, Meridian Public Schools District
The most effective programs I've seen treat malware-specific awareness as an ongoing cadence rather than an annual slide deck: short simulated phishing campaigns quarterly, a two-minute "how to spot it, how to report it" refresher tied to real (anonymized) incidents from within the organization or its sector, and role-specific training for high-risk groups like finance and executive assistants, who are disproportionately targeted by business email compromise and invoice-fraud malware campaigns.
Cloud, SaaS, and Mobile Considerations
Malware protection can't stop at the traditional corporate network edge. Most organizations today run a substantial share of their operations in SaaS applications and cloud infrastructure, and a growing share of work happens on mobile and personally-owned devices — both of which require Control 8.7 thinking that looks different from classic endpoint antivirus.
Malware Protection in Cloud/SaaS Environments
Consideration | Risk | Control approach |
|---|---|---|
Malicious file uploads to SaaS storage (e.g., shared drives, collaboration tools) | Malware spreads via shared links/synced folders | Cloud-native malware scanning, DLP integration |
Compromised cloud workloads (IaaS/PaaS) | Cryptojacking, lateral movement in cloud-native environments | Cloud workload protection platforms (CWPP), patch/config management (8.8, 8.9) |
Shared responsibility gaps | Assuming the cloud provider handles malware scanning | Contractually clarify responsibilities per supplier agreements (5.20–5.23) |
Email/SaaS integration abuse | OAuth token abuse, malicious third-party app integrations | App allowlisting for SaaS integrations, periodic access review |
Serverless/container images | Malicious code baked into container images | Image scanning in the CI/CD pipeline, secure development practices (8.25–8.31) |
Mobile Device and BYOD Malware Considerations
Consideration | Risk | Control approach |
|---|---|---|
Sideloaded or unofficial apps | Malware disguised as legitimate apps | MDM policy restricting app sources, allowlisting for corporate profiles |
Personally-owned (BYOD) devices | Limited visibility/control over device hygiene | Containerized corporate profiles, conditional access, minimum OS/patch baselines |
Mobile phishing (smishing) | SMS/messaging-based malware delivery | Mobile threat defense (MTD) tooling, awareness training specific to mobile |
Public Wi-Fi and unmanaged networks | Interception, malicious captive portals | VPN enforcement, mobile web filtering |
Lost or stolen devices | Local malware installation by a third party | Remote wipe capability, device encryption tied to User Endpoint Devices, Controls 8.1–8.5 |
Both tables point to the same underlying principle in ISO 27002's guidance: malware protection needs to follow the data and the user, not just the network perimeter, which is precisely why 8.7 has to be read alongside cloud services security (5.23), endpoint devices (8.1–8.5), and web filtering (8.23) rather than in isolation.
Measuring Effectiveness: KPIs and Metrics
A malware control that can't produce a metric is a control an auditor — and, more importantly, a board — has no way to evaluate. The KPIs below are illustrative figures I use with clients to frame what "good" looks like; your own baselines should come from your actual tooling and incident history, not these numbers.
Metric | What it tells you | Illustrative healthy target |
|---|---|---|
EDR/AV detection-to-containment time | How fast an active infection is isolated | Under 15 minutes for automated containment |
Phishing simulation click rate | Effectiveness of awareness training | Under 5% after a mature program is in place |
Phishing simulation report rate | Whether users report suspicious email proactively | Above 40% and trending up |
Patch compliance (critical/high CVEs) | Exposure window for exploit-driven malware | 95%+ within defined SLA (e.g., 14 days) |
Backup restoration test success rate | Real recoverability, not just backup job "success" | 100% of critical systems tested at least quarterly |
Web/email filtering block rate (malicious category) | Volume of threats stopped before reaching users | Trending metric, reviewed monthly |
Mean time to detect (MTTD) malware events | Overall detection maturity | Hours, not days |
Percentage of endpoints with active EDR coverage | Fleet-wide prevention coverage | 100% of in-scope endpoints |
I recommend reviewing these metrics at least quarterly with whoever owns risk oversight in your ISMS, and explicitly recording the review — that record becomes some of the strongest evidence you can show an auditor that Control 8.7 is a living, monitored control rather than a policy document nobody has opened since it was written.
Evidence Auditors Expect for Control 8.7
When I'm sitting across from a client preparing for a Stage 2 audit, this is the evidence packet I tell them to assemble specifically for 8.7. Missing even two or three of these is a near-certain finding.
Evidence type | What it demonstrates |
|---|---|
Documented anti-malware standard/policy naming each control layer | The control is designed, not ad hoc |
Endpoint protection/EDR deployment and coverage report | Prevention and detection layer is actually in place fleet-wide |
Email and web filtering configuration and block-rate logs | Prevention controls are active and generating evidence |
Application allowlisting policy and change log (tie to 8.19) | Unauthorized software is controlled |
Patch compliance reports (tie to 8.8) | Vulnerability exposure is managed |
Backup schedule, isolation architecture, and restoration test logs (tie to 8.13) | Recovery capability is real and tested |
Awareness training records and phishing simulation results (tie to 6.3) | The "supported by user awareness" requirement is met |
Malware-related incident records and post-incident reviews (tie to 5.24–5.28) | Detection and response are functioning, and lessons are captured |
Risk assessment entries covering malware/ransomware scenarios | Risk treatment decisions are traceable |
Statement of Applicability entry for 8.7 with justification | The control's inclusion and scope are formally documented |
One evidence gap I flag constantly: organizations that can produce every artifact above except the restoration test log. A backup schedule proves you're generating backups; it proves nothing about whether they can actually bring a system back. Auditors who've seen enough ransomware post-mortems know the difference, and increasingly ask for it directly.
Common Mistakes Organizations Make
Mistake | Why it happens | Consequence |
|---|---|---|
Treating antivirus as the entire control | Legacy thinking, "we've always had AV" | Single point of failure; fileless/behavioral threats bypass it entirely |
Never testing backup restoration | Backup jobs report "success," so no one checks further | Ransomware negotiation happens with no real fallback option |
Backups reachable from the production network with shared credentials | Convenience, cost, lack of architecture review | Backups encrypted/deleted alongside production during an attack |
No network segmentation between business units | Flat networks are easier to manage day-to-day | A single infected host can reach finance, ERP, or OT systems |
Awareness training that never mentions malware specifically | Generic "security awareness" slide decks reused yearly | Users can't recognize the specific behaviors that precede an infection |
Allowlisting policy exists on paper but isn't enforced technically | Enforcement is operationally harder than writing the policy | Unauthorized/malicious software still executes freely |
No metrics reviewed by leadership | Malware control seen as "IT's problem," not a governance topic | Board is blindsided by cost and scope when an incident occurs |
Patch cadence not prioritized by exploitability | Patch everything on the same slow schedule | Known-exploited vulnerabilities remain open far longer than they should |
Web filtering absent or unmanaged (no 8.23 control) | Treated as a "nice to have" rather than a documented control | Malvertising, drive-by downloads, and C2 callbacks go unblocked |
SoA entry for 8.7 says only "Antivirus deployed" | Rubber-stamping a control seen as low-effort | Auditor finding; doesn't reflect ISO 27002's multi-measure guidance |
Case Study 1: Ferrow Industrial Supply — The Cost of a Single-Layer Control
Returning to Marcus Webb's story in full: Ferrow's post-incident remediation, driven by its cyber insurer as a condition of renewal, took four months and included EDR deployment across all 380 endpoints, a secure email gateway with attachment sandboxing, network segmentation separating warehouse, finance, and ERP environments, an isolated and tested backup architecture with quarterly restoration drills, and a complete rebuild of its security awareness program with quarterly phishing simulations. Marcus also formally documented Control 8.7 in the ISMS for the first time, mapping each of those elements against ISO 27002's guidance rather than leaving it as a single line item. Eighteen months later, Ferrow's EDR platform caught and automatically isolated a compromised laptop within four minutes of a suspicious PowerShell execution — the same category of attack technique the original 2023 ransomware operator had used, this time stopped before it could reach a single shared drive. The insurer's renewal premium, which had tripled after the incident, came back down by 40% at the next renewal specifically citing the new control maturity.
Case Study 2: Briarcliff Health Network — Layered Defense Working as Designed
Briarcliff Health Network, a regional healthcare provider with roughly 1,200 staff across four facilities, had already implemented a layered 8.7 control stack ahead of its first ISO 27001 certification, driven largely by HIPAA-adjacent pressure to demonstrate strong technical safeguards. A phishing email impersonating a medical device vendor reached an inbox despite the secure email gateway (the sender domain was newly registered and hadn't yet been flagged), and a staff member opened the attached document. The malicious macro attempted to download a second-stage payload, but the organization's web filtering control blocked the outbound connection to the payload's hosting domain, and EDR flagged and quarantined the initial dropper process within two minutes. CISO Elena Vasquez's team logged the event through their incident management process, confirmed no lateral movement had occurred, and used the incident as the basis for a targeted awareness refresh for the department involved.
"That incident is the best advertisement I have for defense in depth. Any single layer we had could have failed there — the email filter did, technically — and it still didn't become an incident because the other layers picked up the slack. That's the whole point of not relying on one measure." — Elena Vasquez, CISO, Briarcliff Health Network
Case Study 3: Meridian Public Schools District — Recovery Without Ransom
Meridian Public Schools District, a K-12 district serving roughly 9,000 students across twelve schools, was hit by a ransomware variant that encrypted file servers at three school sites over a holiday weekend — a common timing pattern, since attackers know IT staffing is thinnest then. Unlike Ferrow, Meridian had implemented isolated, immutable backups roughly a year earlier as part of its own ISO 27001 readiness project, and — critically — had run a full restoration drill just two months prior. Head of IT Grace Lindqvist's team made the decision within six hours not to engage with the ransom demand at all. Full restoration of affected systems from the isolated backup environment took 30 hours, classes resumed on schedule the following Monday, and the total incident cost — mostly IT overtime and a forensic review to confirm no data had been exfiltrated — came to roughly $85,000, a fraction of the ransom demand and a small fraction of what Ferrow ultimately paid.
Case Study Outcomes at a Glance
Organization | Malware event | Control maturity at time of event | Approx. cost | Ransom paid? |
|---|---|---|---|---|
Ferrow Industrial Supply | Ransomware via phishing macro | Single-layer (AV only) | $2.3 million | Yes |
Briarcliff Health Network | Phishing-delivered dropper + C2 attempt | Layered (post-8.7 implementation) | Negligible — no material impact | N/A — contained pre-encryption |
Meridian Public Schools District | Ransomware, file server encryption | Layered with tested immutable backups | ~$85,000 | No |
Building Your Control 8.7 Implementation Roadmap
Organizations rarely build all eight layers simultaneously, and a phased approach is both realistic and defensible to an auditor, provided it's documented as a plan rather than an indefinite gap.
Phase | Timeframe (illustrative) | Focus |
|---|---|---|
Phase 1 | Weeks 1–4 | Deploy/validate EDR fleet-wide; confirm email filtering and anti-spoofing (SPF/DKIM/DMARC) configuration |
Phase 2 | Weeks 5–8 | Implement or validate web filtering (8.23); document patch cadence and SLAs tied to 8.8 |
Phase 3 | Weeks 9–14 | Design and test isolated/immutable backup architecture (8.13); run first restoration drill |
Phase 4 | Weeks 15–18 | Roll out application allowlisting on highest-risk assets (servers, finance, engineering) |
Phase 5 | Weeks 19–22 | Refresh awareness program with malware-specific content and quarterly phishing simulations (6.3) |
Phase 6 | Weeks 23–26 | Formalize metrics reporting, SoA documentation, and tabletop exercise simulating a ransomware scenario |
This roadmap deliberately sequences backup validation before allowlisting expansion, because recovery capability is the single highest-leverage gap to close first — it's the layer that determines whether every other layer's failure is survivable.
The Strategic Case: Malware Protection as Competitive Advantage
It's tempting to treat Control 8.7 as a compliance chore — a box to check on the way to a certificate. That framing misses what's actually at stake. Ransomware and malware incidents are, disproportionately, the events that put mid-market organizations out of business entirely, not the sophisticated nation-state intrusions that dominate headlines. The layered program this control requires — EDR, filtering, allowlisting, patching, tested backups, and genuine awareness — is not bureaucratic overhead; it is close to the single highest-leverage investment most organizations can make in their own survival.
There's also a commercial dimension that Marcus Webb learned the hard way: customers, insurers, and partners increasingly ask direct questions about malware resilience specifically, not just security posture in the abstract, and an ISO 27001 certificate backed by a genuinely layered Control 8.7 implementation is one of the clearest, most portable answers an organization can give. It converts a defensive necessity into a sales asset — evidence you can hand to a procurement team, an insurer, or a board, rather than a promise you hope never gets tested.
If you're scoping this work as part of a broader ISMS build-out, a few PentesterWorld resources make the process faster. The Annex A — All 93 Controls at a Glance cheat sheet is useful for seeing exactly how Control 8.7 sits alongside its related controls at a glance. If you're still assembling your core documentation, the Complete ISO 27001 Implementation Guide eBook walks through sequencing a control build-out like the one described above. For the risk side of this control, the ISO 27001 Risk Register Template gives you a starting structure for documenting malware and ransomware scenarios with realistic likelihood and impact ratings. Before your next internal or certification audit, run your evidence set against the ISO 27001 Mandatory Documents Checklist to confirm your anti-malware standard and supporting records are where they need to be, and if you haven't yet formally assessed where the gaps sit, the ISO 27001 Gap Analysis Tool is the fastest way to turn this article into a prioritized action list rather than a reading exercise.
Marcus Webb, eighteen months after his worst Tuesday, put it simply in his own words during a follow-up conversation: "I used to think of the malware control as the easiest line item in the whole audit. Now I think of it as the one I'd stake the company on — because I nearly had to."