ISO 27001 A.8.7: Make malware protection work in practice
Malware protection is an operating arrangement, not simply the purchase of security software. ISO 27001 Annex A.8.7 combines protection against malicious software with appropriate user awareness. A useful implementation addresses how harmful content could enter, which assets need protection, who receives warnings and how affected operations can recover.
What A.8.7 requires in practice
A.8.7 requires protection against malware, meaning software designed to cause harm, such as viruses, ransomware, spyware and malicious scripts. The control joins two things: protective measures that are actually implemented, and user awareness that supports them. Neither is enough alone.
In practice an organisation considers how harmful content could arrive, whether through email, web browsing, removable media, downloads, supplier updates or connected devices. It then decides which assets need protection, what form that protection takes and who receives and acts on warnings. People need to know what suspicious content looks like and what to do when they meet it.
Outputs include working protective measures across the relevant assets, a way of handling alerts, an approach to exceptions and awareness activity for users. The control does not name a product or demand the same tool on every system. Specialised equipment that cannot run standard software needs another suitable arrangement, and one way Sterling's teams record that is an exception note with the compensating measure.
Understand the routes and the coverage
Start with the ways information and software reach systems. Email attachments, web downloads, removable media, maintenance activities and third-party transfers may involve different protections. Identify which systems can support the proposed measures and which need another treatment. A device absent from the management console should prompt investigation, rather than quietly fall outside the coverage calculation.
Protection can include restricting unauthorised software, checking incoming content, maintaining suitable detection capabilities and limiting access that would allow a problem to spread. Combine this with technical vulnerability management and controlled software installation. These measures address related causes but do not replace malware detection or response.
Make warnings lead to a decision
Define who reviews a suspected detection, the information needed to assess it and how the organisation decides whether containment is necessary. A warning that nobody owns is not made effective by its severity label. The responsible person needs a route to technical investigation and business coordination.
Give users a practical reporting instruction. They should understand where to report suspicious files or unexpected behaviour and how to avoid making matters worse while awaiting help. Awareness should relate to their work: a project coordinator handling supplier drawings faces different routine choices from an administrator maintaining a production server.
Why malware protection matters to the business
Malicious software can halt operations, encrypt records and expose customer information within hours. Ransomware in particular has turned ordinary infections into business-threatening events that involve recovery cost, client notification and lost trust. Protection that exists only on paper, or that covers some machines and not others, gives leaders false comfort. Clients often ask suppliers how they protect against malware before sharing data, and insurers increasingly ask the same. Well-run protection also reduces interruption: fewer infections mean fewer disruptive clean-ups. The awareness element matters commercially because staff are usually the first to see a suspicious message, and a team that knows what to do limits the damage before technical tools react.
How to implement A.8.7
Combine technical coverage with clear human responsibilities, and look accurately at where coverage is thin. Expect the awkward cases, such as specialised equipment and visiting suppliers, to need as much thought as the ordinary office laptop. Those are where gaps usually sit.
- List how malicious content could enter, including email, web, removable media, remote access and supplier-delivered files.
- Map the assets that need protection and note which ones cannot run standard tools, such as production equipment or temporary laptops.
- Select protective measures to match each asset group, keep them updated and decide how a device that has not reported in for some time will be found and followed up.
- Decide who receives warnings, how quickly they are assessed and what authority they have to isolate a device.
- Record exceptions with the compensating measure and an owner, and revisit them when the equipment or its use changes.
- Prepare users with plain examples drawn from your own business and a simple route for reporting something suspicious, so reporting is never awkward or blamed.
- Check coverage against the asset list and rehearse recovery from an infection.
Illustrative manufacturing example: a constrained production workstation
A fictional manufacturer uses a production workstation whose supplier restricts the installation of additional software. The organisation cannot treat this restriction as proof that malware protection is unnecessary. It evaluates the workstation's actual connections, file-transfer routes and maintenance activities with the operational owner.
The selected arrangement uses controlled transfer methods, restricted installation rights and an approved maintenance process, with appropriate monitoring and recovery preparation. The team records the reason for the limitation, the compensating measures and when the arrangement will be reconsidered. This illustrates a risk decision for constrained equipment, not a universal instruction to install an incompatible agent or to accept an unsupported system indefinitely.
Illustrative construction example: a temporary survey laptop
A hypothetical construction project receives survey information through a temporary laptop used by several approved staff. Its protection status is not visible to the central team, and files move from it into the shared project environment. The project manager had assumed that the device supplier managed everything.
The organisation establishes responsibility for the laptop, checks its approved configuration and introduces a controlled route for incoming files. A safe, authorised exercise checks whether a permitted test event reaches the assigned responder. The team also rehearses how project work would continue if the device needed to be taken out of service, avoiding improvised transfers through personal devices.
Control exceptions and prepare for recovery
Protection settings can disrupt legitimate work, but disabling them without control creates another risk. Where an exception is justified, record the affected asset, reason, authorised decision, alternative protection and review point. A temporary troubleshooting exception should not silently become the permanent state after the original problem has been fixed.
Recovery needs more than confidence that a tool has removed a suspicious file. Technical staff should evaluate whether the system can be trusted for its intended use and follow an appropriate recovery process. Connect this decision with information backup. A recoverable copy and a verified restoration process can support recovery, but neither proves that the restored environment is free from the original weakness.
Evidence that reveals gaps
Useful evidence may include a reconciled coverage record, current protection status, approved exceptions, incident handling records and controlled test results. These are practical ways to demonstrate operation, not prescribed document titles. Explain the measure's scope: a percentage based only on enrolled devices can hide assets that were never enrolled.
Use safe test methods approved for the environment. Do not introduce live malicious software to demonstrate readiness. Check both technical detection and the human response, including out-of-hours arrangements where relevant. If a test signal is detected but the responsible team does not receive it, record and address the failed handoff.
Common failures include treating installed software as maintained protection, leaving exclusions unexplained and asking users to diagnose threats themselves. Review meaningful findings through ISMS monitoring and evaluation, so the organisation improves coverage and response instead of merely reporting the number of alerts generated.
Frequently asked questions
Is antivirus installation enough for A.8.7?
It is usually only part of the arrangement. Appropriate coverage, maintenance, access restrictions, user awareness and response are needed to address the organisation's selected risks.
What if a system cannot run the usual protection software?
Assess its exposure and feasible alternatives with the system owner. Document justified measures and limitations, and reconsider the decision when the system or risk changes.
How can we test protection without using real malware?
Use an approved harmless test method suitable for the chosen technology and environment. Verify the detection and response path within authorised limits, without creating an uncontrolled threat.
Turn malware protection into an accountable process
Ask Sterling about scoped malware-control and ISMS support, including documentation, employee learning and agreed Effivity ISO & GRC automation software. The wider ISO 27001 engagement can include authorised vulnerability scanning and findings review; continuing preparation support does not replace an independent certification decision. Review and enrol in ISO/IEC 27002 Information Security Controls to connect technical protection with people and response. Explore the technological controls directory for related decisions.